- From: Joe D Williams <joedwil@earthlink.net>
- Date: Mon, 15 Mar 2010 09:15:51 -0700
- To: <public-html@w3.org>, "Simon Pieters" <simonp@opera.com>
>>>> Joe >> This follows the model set by <object> and could result in >>>> use of the following construction: >>>> >>>> .<video autoplay controls> >>>> <source src="tgif.vid"> >>>> <source src="lgif.zvid"> >>>> <p><a href="tgif.vid">Download the video file.from this >>>> link.</a></p> >>>> </video> >>>> In this example if the UA recognizes <video ...> but does not >>>> recognize vid content then the the potential fallback video >>>> content .zvid will be tried. If still no go, then the html >>>> "fallback" content enclosed in <p> element would be shown according to the <video>, <p>, and <<a> styles. >>> Simon > No, it wouldn't. >> OK, I must be really off in my thinking of how it could work. SInce >> I haven't found an example in the spec that is giving me >> understanding (or changing my preconceptions), please tell me if >> the above is even a legitimate contruction, and how you are >> expecting <video> to work. I am guessing that the construction shown above would be legal html5. >> Please tell me what actually should happen in the case where none >> of the listed <videdo> resources are playable. > A blank video box would be rendered. If you later insert a <source> > element with script, the browser will try to play that one as well. So for the case where no @src is specified in the <video> element, or where none of the resources will play, there is no "fallback' behaviour that shows the html content. Just a blank player box. Like @src="". In this case, the tradidtional <object> behaviour of producing contained "fallback' html if the <object> does not run because either not recognized or no resource, does not prevail. Tne the user is left with a blank box that is available for script injection of a potentially playable resource. Is there any standard message that the UA would display, like "Better luck next time" or "Sorry, no video here yet"? > >> The following description of the example did not get a comment so I >> am supposing that thie following is a reasonable description of >> what should happen if <video> is not recognized by the (legacy) UA >> at all. : >> >>>> In this example if the UA did not recognize the <video> element >>>> then the html "fallback" content enclosed in <p> and <a> element >>>> would be shown. This operation is more than just a specification >>>> for <video>, <audio>, or <object> but just intrinsically how the >>>> web UA should work: Skip elements that are not in the >>>> vocabulary. So, here, an old UA would just naturally skip <video >>>> ... >, <source ... >, and <source ... > and end up showing the >>>> html link according to the <p> and <a> style, although the UA >>>> will probalbly also apply CSS specified for <video>.. >> >> This seemed reasonable to me for this example because I suppose in >> this case the UA follows the same sort of rules as <object>. > > Yes, if <video> is not supported then the contents are rendered. OK, so <video> and <audio> work such that * a non-html5 UA would produce the contained html fallback. * If <video> is recognized but no resources are specified or playable, the html5 UA would show blank box, ignoring the html legacy fallback user code, and waiting for a script to arrive with a resource. If so, I can now maybe understand how this was decided: Old UAs continue to work the way they always have), however, the idea of scriptless automated author defined 'fallback' in case of no resources is not solved. If old UAs didn't work the way they do and so are removed from consideration, and only html5 UAs were considered, then the contained html 'fallback' content could be dedicated to 'accessibiltiy' content. Thanks and Best Regards, Joe > -- > Simon Pieters > Opera Software >
Received on Monday, 15 March 2010 16:16:29 UTC