- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 12 Jun 2008 09:56:19 +0000 (UTC)
On Thu, 12 Jun 2008, Philip J?genstedt wrote: > > > > This isn't currently defined (even without a poster, as far as I can > > tell), but my intention would be to not make the poster affect the > > intrinsic dimensions, and for the default, in the absence of video > > data, is 300x150. This is defined now by the way. > > The problem with scaling to the poster's size is that it would make > > the veo resize twice e (300x150 -> poster -> video) instead of just > > once (300x150 blank, then poster -> video). > > If poster is to <video> what src is to <img>, then surely the video > element should take the size of the poster image if no width/height is > given? This is certainly my preference, as width/height would otherwise > effectively be mandatory when poster is used, which would in turn > require the poster to be of the same size as the video unless one is to > be scaled. Why? The posted would be displayed in the default 300x150 box. > That the element may be resized twice is not a problem, at > least not implementation-wise. That it's resized at all is a terrible problem; that it woul resize twice would be a disaster, UI-wise. > As some container formats allow changing the video frame size mid-stream > (notably chained Ogg streams, so called sequential multiplexing) the UA > could possibly resize the video element an unlimited number of times, so > handling that is necessary anyway. That's not the common case, though; a poster is. > On that note, perhaps an event to notify JavaScript UIs of such changes > would be useful/necessary. Perhaps reusing "resize" event would be the > best, other names could be "videochange" or "sizechange". I've noted this for a v3 feature. > > > HTTP 4xx and 5xx errors (and equivalents in other protocols) must > > > (may?) cause the user agent to ignore the poster attribute. > > > > Well what else are they going to do? HTTP already requires this as far > > as I can tell. > > It appears that Safari shows a little X symbol instead, but perhaps > specifying this behavior is not necessary. We will likely ignore the > poster attribute entirely instead. Showing a red X seems contrary to the spec (which says that the <video> element represents the poster, the video, or nothing), but really rendering things are out of scope of the spec. In any case, in a few years we'll probably look at what implementations do and specify what the implementations have converged on. > > I'm not sure a fake button (which wouldn't actually work anyway) is a > > natural interpretation of "poster frame". :-) > > As long as it's mentioned somewhere there can be no misunderstanding. Ok, added a note. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 12 June 2008 02:56:19 UTC