Re: handling fallback content for still images

On Jul 3, 2007, at 10:16, Robert Burns wrote:

> On Jul 3, 2007, at 2:02 AM, Henri Sivonen wrote:
>
>> FWIW, <picture> is significantly different because:
>>  1) Still images already work *natively* in browsers and  
>> WYSIWYGish editors using <img> since way back when.
>
> video, audio, and flash all work "natively" in browsers and  
> WYSIWYGish editors using <object> since way back when

Not for the generally accepted meaning of "natively" in browser  
support context.

>>  2) Still images don't require an elaborate scripting API.
>
> Not sure why that's relevant. They wouldn't require elaborate  
> scripting APIs using <picture> either.

It is relevant for the motivation of <video>, <audio> and <canvas> to  
which you were comparing <picture>.

>>  3) From an authoring perspective the marginal cost of switching  
>> from <img> to <picture> is incredibly bad considering the marginal  
>> utility. (To go from a string fallback to markup-enable fallback,  
>> you break the compatibility with over a decade of software for the  
>> non-fallback content. And normal authors care about non-fallback  
>> more.)
>
> I'm an ABD economist and I don't even know where to begin to  
> respond to this (maybe once I finish my dissertation I'll  
> understand what you're saying).

Please do point out if I've used the terms incorrectly. You want to  
make the slightest improvement to the way images are marked up. The  
cost of the slightest improvement is very high considering the benefit.

> The vision here is that in the distant future no one will even  
> touch <img> they will simply use <picture>.

But how do we get from here to there considering real-world  
incentives that influence the way browser vendors and authors work?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 3 July 2007 07:40:39 UTC