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 <[EMAIL PROTECTED]> 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/>
