Re: handling fallback content for still images

Robert Burns wrote:
> On Jul 5, 2007, at 10:17 AM, James Graham wrote:
>> Robert Burns wrote:
>>> No, it is not clear that these is skepticism about what I am
>>> proposing. There is quite a bit of support for what I am proposing
>>> (providing parallel rich fallback content for still images). There is
>>> also a few who are responding with quite a bit of irrational
>>> resistance to what I am proposing: particularly in this latest
>>> suggestion, where I'm not actually proposing we change anything
>>> fundamental, but instead provide interoperability and author guidance
>>> for something that is already happening (non-inter-operably) in UAs.
>>
>> Calling people who disagree with you "irrational" doesn't seem
>> constructive; to me it suggests that you are not taking the time to
>> understand what they are saying.
> 
> No, I understand what you're saying and its irrational.

In what sense "irrational"?  Reasons are being provided.  The three main
ones, AFAICS, are:

While it might be nice to have <img> contain rich fallback, it can never
be used in the HTML serialisation, making it of limited use to 99.9% of
the Web.

Additionally, at the moment, it seems that not rendering what is inside
<img> tags in XML modes is not a form of fallback, but rather complete
ignorance of the contained content, and so the current behaviour, while
somewhat interoperable, is not actually the desired behaviour.

Finally, if at any future time XHTML is more widely used: having the
sixth-most used element [1] on the web have different behaviour
depending on the MIME type of the document it's sent within seems
error-prone and likely to confuse people who copy-and-paste, not to
mention people who save XHTML files to disk with the "html" extension
only to find the page broken when opening it.

[1] http://code.google.com/webstats/2005-12/elements.html

-- 
Andrew Sidwell

Received on Thursday, 5 July 2007 16:07:22 UTC