On Jul 5, 2007, at 8:06 AM, Anne van Kesteren wrote:
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.
I can't imagine how our WG can't be about interoperability. As for
<burger/> element, the closest thing we have to a <burger/> element
are the <video>, <audio>, and <canvas> elements.
Take care,
Rob
