- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 15 Feb 2012 16:27:01 -0800
- To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>
- Cc: WWW Style <www-style@w3.org>
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. ~TJ
Received on Thursday, 16 February 2012 00:27:48 UTC