Re: handling fallback content for still images

On Jul 5, 2007, at 11:07 AM, Andrew Sidwell wrote:

>
> 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

So then the arguments are saying (which is all I wanted them to  
acknowledge) that were are going to forbid user agents (including  
aural user agents) from interpreting the contents of an <img> element  
as fallback. Secondly the arguments suggest we will forbid authors  
from placing fallback contents within an <img> element (even in the  
xml serialization). So:

1) UAs must not interpret the contents of an <img> element or any  
other canonically empty element as fallback and must not present this  
content to users.
2) Authors must never include fallback content within an <img>  
element even though it may be well-formed XML.

The irrationality isn't the arguments you listed. Its the merry-go- 
round of essentially saying that the spec should forbid these  
practices, followed by the no it shouldn't forbid it. In other words  
it should forbid it and it should not forbid it.

Take care,
Rob

Received on Thursday, 5 July 2007 16:54:48 UTC