- From: Sander Tekelenburg <st@isoc.nl>
- Date: Thu, 30 Aug 2007 16:37:29 +0200
- To: public-html@w3.org
At 23:09 -0700 UTC, on 2007-08-29, Maciej Stachowiak wrote: > On Aug 29, 2007, at 8:35 PM, Sander Tekelenburg wrote: [... <http://santek.no-ip.org/~st/tests/object/>] > "image/*" is not a known MIME type, indeed I am not sure if it is even > a legal type. It seems pretty simple to omit the type instead of using > an illegal type, which likely makes us think we can't handle the > content. Yeah, maybe "image/*" is not a MIME type authors are likely to use. But just plain "image" is, and has the same effect on Safari 2.0.4. (Just added to the same test page.) > In the long run the right thing to do is to ignore the type attribute > and choose how to handle the content based on the server-reported > return type, which I guess is what Firefox is moving to. Yeah, that might be better (assuming the HTTP Content-Type can be trusted). As a bonus, that would do away with the unfortunate situation that currently @type is either normative or mereley advisary, depending on the element. Completely ignoring @type would seem to go too far though. It could still be useful as advisory information (in ways as mentioned in <http://esw.w3.org/topic/HTML/ABetterAlt> and <http://www.euronet.nl/~tekelenb/WWW/userfriendlierhyperlinks/> for instance). [... <video>/<audio>fallback] > <video type="video/mp4" src="lolcat.m4v"> > <object type="video/mp4" data="lolcat.m4v"> > ... text equivalent goes here, if needed ... > </object> > </video> > > However, a video file may have optional caption tracks and/or > descriptive audio, so a text equivalent may not be necessary for > accessibility. A text equivalent will always be necessary for universality. That aside, nesting of objects has the serious downside that it forces authors to force a specific fallback order upon the user. I suspect that your announced proposal means to solve that for <audio>/<video>. If so, it wouldn't be so bad if <object> would not provide that solution, *if* <object> would be for legacy UAs only. That might in fact be good, as it would show a clear benefit to authors to use <audio>/<video>, and for users to upgrade to HTML5 UAs. However, that would still leave us with images... So either <object> would need to be upgraded to the same solution (so authors can use it for images), or we're back at the suggestion to add <picture> to the <audio>/<video> family. Another problem with having <audio>/<video> rely on an embedded <object> to provide textual equivalents is that we will be stuck with thet construct forever that way. Even by the time 'every' UA supports <audio>/<video>, authors would still have to add <object> just to provide a textual equivalent. I don't think we should steer towards that future. [... announced proposal for <audio>/<video> accessibility] > Our current proposal is for <audio>/<video> based on the fact that > they can already list multiple <source> elements. Right, makes sense. I would expect textual equivalents to bepart of it too though. And let's not forget the use case where multiple equivalents need to be consumed side by side (such as a transcript of an audio file), not just as alternates. > [...] As such I don't think it would really apply to the other elements. > I suppose one could > image providing high-contrast versions of static images. Sorry, I can't follow. Are you talking about providing images through <audio>/<video>? [... <embed/> as <object> fallback] > I think we should define that when <embed> is nested in <object> and > neither can be presented, the <object> element's fallback applies. Yeah, that might work. If new elements like <audio>, <video>, etc. would allow for 'rich' equivalents authoring, then it might be OK to let <object> and <embed> remain the poorer legacy elements (that'll hopefully slowly be phased out by authors). -- Sander Tekelenburg The Web Repair Initiative: <http://webrepair.org/>
Received on Thursday, 30 August 2007 14:43:33 UTC