W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [css3-images] Image fallback feature's dependency on media fragments

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 21 Feb 2012 16:18:36 +0100
Message-ID: <4F43B5CC.4050300@inkedblade.net>
To: www-style@w3.org
On 02/16/2012 01:27 AM, Tab Atkins Jr. wrote:
> On Wed, Feb 8, 2012 at 9:15 AM, Kang-Hao (Kenny) Lu
> <kennyluck@csail.mit.edu>  wrote:
>> 3.2. Image Fallbacks and Annotations: the ‘image()’ notation
>>   # So that authors can take advantage of CSS's forwards-compatible parsing
>>   # rules to provide a fallback for image slices, implementations that
>>   # support the ‘image()’ notation must support the xywh=#,#,#,# form of
>>   # media fragment identifiers for images. [MEDIA-FRAGS]
>> Is this what implementers are planning to do? It it is, there's nothing
>> I would complain. If it is not, as the feature of media fragments seems
>> to be heavier than than feature of image fallback, it seems enough here
>> if we only require "implementations that support the 'image()' notation
>> but not xywh=#,#,#,# must treat such URL as a 404 image" so Example 4:
>>   # background-image: url('swirl.png'); /* old UAs */
>>   # background-image: image('sprites.png#xywh=10,30,60,20'); /* new UAs */
>> can be written as
>>   | background-image: url('swirl.png'); /* old UAs */
>>   | background-image: image('sprites.png#xywh=10,30,60,20', 'swirl.png');
>>   | /* new UAs that support fallback image. Might or might not support
>> media fragment */
>> What are implementers' plans here?
> I don't know about impl plans, but if they aren't planning to support
> media fragments in the very near future (in the next 3-4 months, I'd
> say), then I like your suggestion to at least force browsers to
> *recognize* media fragment URLs and explicitly fail to understand
> them.  That's the whole reason for the requirement, after all.

I think I'd rather gate image() on media fragments than make authors
write their fallback URL twice in order to get good fallback behavior.
image() doesn't have anything that impressive to offer, afaict, other
than media-frags, which gets authors non-hacky spriting.

Note, Mozilla has implemented MF functionality with a different syntax:
IIRC this was at least partly because MF was in early draft stages when
that was implemented and also because they wanted to take advantage of
CSS fallback parsing.

That said, I wouldn't mind specifying that if the UA can't intepret a
fragment identifier specified in image(), it should treat that as an
unknown image. It would allow us to use image() for fragment-identifier
fallbacks in the future. :)

Received on Tuesday, 21 February 2012 15:19:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:28:39 UTC