- From: Anne van Kesteren <annevk@opera.com>
- Date: Thu, 05 Jul 2007 15:07:58 +0200
- To: "Robert Burns" <rob@robburns.com>
- Cc: www-archive@w3.org
Taking it to www-archive as it doesn't feel worth it to discuss this on public-html. On Thu, 05 Jul 2007 14:51:06 +0200, Robert Burns <rob@robburns.com> wrote: > Anne, you're definitely talking about forbidding it. Of the three visual > browser engines that handle XHTML at all: Presto and Gecko both handle > the non-fallback state just as we would want with XHTML. Sure. That's how replaced elements work. > WebKit does not, but that could get fixed. It doesn't? Weird. > I haven't tested any Aural or Tactile UAs yet, but that's where we > really need this to work and it wouldn't surprise me if it already > works. It is a minor bug if Opera doesn't display the fallback content > when the image is not available. Minor... right. > [...] > > However, you're position seems to be that we should forbid this behavior > in UAs. We should go right now and file bugs to Opera and Mozilla to > tell them that they're handling xml parsing and rendering incorrectly. No, they're not handling it incorrectly. They're handling it perfectly fine. > They should display the contents of the <img> element just as the do > when rendering text/html. You seem to misunderstand HTML parsing. > We should forbid authors from taking advantage of this bug in Opera and > Firefox and put them on notice that we're going to make sure the > fallback content doesn't work that way in the future. I'm not sure what this means. > In contrast, I'm suggesting that we take advantage of this break in > parsing and add UA conformance criteria that specifies precisely how UAs > should handle this fallback. Whatever we determine for <video>, <audio>, > <canvas>, and <object> should also guide us in our conformance criteria > for <img>fallback</img>. Authors deploying XML will most likely take > advantage of this unless we forbid it. And why shouldn't UAs handl <img> > in the same manner it handles the other embedded content elements and > their fallback. Because that would be inconsistent with how they handle <img> in the HTML serialization. (There's also alt= to deal with of course, but that's minor.) The other thing is that the advantage is not really there as I don't think we'll get much XHTML adoption. >> Then there is the question of how common markup fallback would be. If >> it is very common it might be worth it to investigate something like >> <picture> / <graphic>. If it is not very common we should simply >> consider having authors use <object> which already solves this use >> case. (If they need it to work in current versions of Internet Explorer >> they can maybe use some type of scripted workaround or any of the >> alternatives proposed elsewhere in this thread.) > > You exhibited the same strong resistance to introducing a new still > image element such as <picture> that you're now exhibiting toward > <img>fallback</img>. Again, we have a clear use-case. The current > situation is not working. The current situation is working. Just stating that it doesn't work is not convincing. > Many creative approaches have been put forward that meet the criteria > laid out. In other words it shouldn't break existing content, it should > degrade gracefully, etc. But then you keep moving the goal posts. Now > we're supposed to just revert to @alt despite several superior > solutions. I don't even know what criteria is being applied now with the > newly moved goal posts. I don't believe I have ever set any goal posts. Maciej mentioned something about it might being worth a try if I remember correctly. I'm not really convinced there is really a use for it. (Other than a few edge cases <object> already caters for.) > The issue of <img> and elements like it are something we should provide > guidance on for the XML serialization. Will it confuse authors that > there are two serializations: yes. Will it frustrate authors when they > see how much easier it would be to deploy XML serialized content , but > they can't because their targeted browsers don't support it: yes. But > these are issues that I think are beyond the scope of this WG. The best > we can do is try to make sure that UAs are interoperable whether their > XML UAs or HTML5 UAs or both. So far I haven't seen much activity in the getting user agents more interopable area. Most of it is people requesting a <burger/> element to be included in the next version of HTML. And complaints about some explicit accessibility features from HTML 4 that are not included in the current draft because several use cases were not considered and not much research was done in the area. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Thursday, 5 July 2007 13:08:28 UTC