On 1 Mar 2007, at 11:56, Anne van Kesteren wrote:
That's one of the reasons a dedicated element is better than reusing the <object> element. All the new video specific APIs would otherwise have to be defined for all possible things the <object> element can represent (images, nested browser context, video, audio, plugins, etc.). Given that the <object> element is already a nightmare for implementors...
Would I be right in thinking of <video> as inheriting from/a subclass of <object> then, to draw an OOP analogy. Or would they be more like siblings?
Secondly, I think of ‘video’ as a sequence of visual frames with no audio. I presume you mean something more akin to what I call a movie container, with a video track, multiple audio dubbing tracks in different languages, subtitles or graphical overlays, &c.
If so, do you think the name could be altered to reflect this? Thirdly, are you intending for there to be <audio> counterpart?
I assume you want the width and height attributes to be used only for specifying the original width and height the video was made at, and css should be used to set the width and height to a % or px etc.?Yeah, maybe. I was thinking about something along those lines, but I couldn't really figure out how it would work.
Video streams/files already contain their native pixel dimensions, and as Henri said, you never know what you're going to GET. A better attribute would be "scale" which takes a floating point value, defaulting to 1.0 (should probably have a corresponding CSS element too, which we could apply to other things that have native dimensions like still images). This would work well with max-/min-width. You may want to consider aspect ratio too: ratio="preserve" being default, ratio="1.333" could indicate 4:3 or get tricky and accept "16:9" for precision reasons.
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
