On Thu, Dec 2, 2010 at 6:34 PM, Simon Fraser <s...@me.com> wrote: > On Dec 1, 2010, at 5:37 PM, Robert O'Callahan wrote: > > On Thu, Dec 2, 2010 at 2:25 PM, Tab Atkins Jr. <jackalm...@gmail.com>wrote: > >> On Wed, Dec 1, 2010 at 5:20 PM, Robert O'Callahan <rob...@ocallahan.org> >> wrote: >> > In the absence of compelling use cases, I'd just leave it at <img>, >> <canvas> >> > and <video> and whitelist in more elements later if necessary. >> >> <input type=image>? <object>/<embed> seem to have roughly equivalent >> use-cases to <video> (though perhaps we just want to encourage >> <video>). >> > > <object> can contain fallback content which might get tricky. > > > So can <video>. >
Actually <video> can't, although I think it should. It's a shame to disallow HTML elements with known width and height, e.g. if > you want to render a small disconnected <div> subtree into a <canvas> or map > it onto a WebGL texture. You'd have to decide how to resolve style (maybe > assume it's a child of the body?). > That gets tricky fast, as Boris explained. I think we could spec the following cases: 1) <img> containing a fully loaded image; size is the intrinsic size of the image 2) <video> when it's displaying a video or fully loaded poster image; size is the intrinsic size of the video or poster image 3) <canvas>; size is the size of the canvas buffer We could add <object> and <embed> to the list, for the cases where they contain a plugin or a fully loaded image, except I don't know what size you'd use. Maybe resolve style, use the resolved width and height if they're both lengths, otherwise rendering nothing? I'm not terribly motivated to add new features for plugins though. I think after the behaviour of not-in-document IFRAMEs is properly specced out (e.g. defining the viewport size), we could add them here too. Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]
