- From: Robert Burns <rob@robburns.com>
- Date: Thu, 5 Jul 2007 07:51:06 -0500
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "Fabien Basmaison" <fabien.basmaison@arkhi.org>, public-html@w3.org
On Jul 5, 2007, at 7:17 AM, Anne van Kesteren wrote: Not sure if this was supposed to be on-list, but... > > On Thu, 05 Jul 2007 14:10:42 +0200, Fabien Basmaison > <fabien.basmaison@arkhi.org> wrote: >> But don't you agree that an alternate representation of the image >> can contain hyper links (or even <strong>, or <cite>, ...)? >> We're still dealing with HyperText, after all; no matter the place >> this hyper is placed in. > > Indeed. > > >> I agree the context may be very important to the background of an >> image, though getting redundant some informations available or not >> in the @alt most of the time, but why "forbidding" this possibility? > > I don't think we're forbidding anything, we're dealing with > constraints. The constraints being that <img> is widely popular and > well supported and therefore making it non conforming is not likely > to go down well. 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. WebKit does not, but that could get fixed. 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. This is something that we should deal with. However, we haven't even laid out conformance criteria for how visual UAs should handle fallback content, so how could we expect Opera and Mozilla to already implement what we haven't even specified. 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. They should display the contents of the <img> element just as the do when rendering text/html. 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. 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. > 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. 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. 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. Take care, Rob
Received on Thursday, 5 July 2007 12:51:31 UTC