- From: Robert Burns <rob@robburns.com>
- Date: Thu, 5 Jul 2007 05:54:30 -0500
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "HTML WG" <public-html@w3.org>
On Jul 5, 2007, at 5:32 AM, Anne van Kesteren wrote: > > On Thu, 05 Jul 2007 12:10:31 +0200, Robert Burns <rob@robburns.com> > wrote: >> Yes, I understand that's why I added the con. Should I add it a >> second time? I've said this again and again this will take a long- >> term solution approach. In that time-frame authors may not even >> know what a text/html compatible serialization is? They won't be >> confused because there might come a time when no one uses that >> serialization anymore. > > In that case it would make more sense to develop something like > XHTML 2.0 which is not what this Working Group is doing last time I > checked. I don't really understand this whole XHTML 2 inferiority complex that's going on around here. I'm not from the XHTML 2 working group, I wasn't sent as a spy. I don't even know why you would bring this up here. Its irrelevant. There are a lot of reasons that authors may move to xml one day and it wouldn't have to be through adopting XHTML 2. It could be through adopting XHTML5, XHTML 1.5, or HTML5/XML or whatever we end up calling it. Outside of HTML, XML has already become widespread (including namespaces and mixed namespaces, doctype declarations, schema, and all sorts of goodies that seem to be bad words around here). Authors are already going to have to familiarize themselves with the differences. With text/html serialization they won't be able to do lost of nice things with their documents that they will be able to do with the xml serialization. Adding fallback to an img element is only one more thing. I don't think it will be that confusing. >>>> Because <Img> has to be empty, authors cannot provide >>>> semantically rich or media rich fallback content for images in a >>>> simple and straight-forward manner (as they can for <object>, >>>> <video>, <audio>, <iframe>, <object>, and <canvas>). <img alt> >>>> cannot do that at all. It's really only listed there as a token >>>> solution. >>> >>> Is there any evidence that suggests that authors will start >>> providing more meaningfull fallback when they can have more than >>> just text? For instance, what do authors currently do for >>> <object> when they use it for Flash or video or some such? >> >> I'm not a palm reader. I don't know the future. Is there any >> evidence that the world wide web will exist next year? I know I >> couldn't prove it will. However, it should be a goal of ours to >> provide a language that services the needs of authors. Why are you >> so resistant to providing these facilities? > > Because > > 1) Changing fundamental parts of HTML in drastic ways is not > something > I think we should be doing. How is allowing fallback content inside <img> in the xml serialization (something that Opera and Mozilla are already doing gracefully) a drastic change to a fundamental part of HTML. Did God decree that <img> shall never have fallback content? > 2) While I agree that it would have been nice if <img alt> was > designed > better when invented I'm not convinced it's so bad now. All user > agents now support it so graceful fallback is no longer > relevant and > you typically don't need markup fallback. Why should <img>, which will probably be used much more often than other embedded media elements, not have at least thee equivalent fallback where the contents of the element can serve as fallback? Add to that the fact that other media my have better accessibility features than still images do and the need for <img> to have rich fallback is increased. Why would one not need markup fallback for a still image? Have you made the blind see? > 3) As mentioned above, I'm not convinced images need markup fallback. > The people who really do need markup fallback (I'd love to see > some > realistic examples) can use <object> once that's better supported. I'm the one who raised better support for <object> as a solution to this problem (I believe I got resistance on that one too). However, why shouldn't our discussion reflect several possible alternative solutions like <picture> fallback</picture and <img>fallback</img> and <img longdesc='fallback">. And again, @alt doesn't cut it. >> No. I wasn't trying to make it true. That its true I think is >> obvious. >> I was simply trying to reiterate so you wouldn't forget about it. > > Ok, I hope I explained well enough why I think this is not obvious > at all. No. That had nothing to do with <video> and <audio>. Look I have nothing against those additions to the language. But I can't even begin to come up with a use-case for <video> and <audio> that could come close in importance to the need to provide fallback for still images. And no one else has been able to describe any pressing need for those either. Take care, Rob
Received on Thursday, 5 July 2007 10:54:55 UTC