W3C home > Mailing lists > Public > www-style@w3.org > May 2011

Re: [css3-images] Features Overview

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 9 May 2011 14:41:02 -0700
Message-ID: <BANLkTim+w2xT_Tj3-4dqqRzfg4OkvRJJUA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style@w3.org
On Fri, May 6, 2011 at 11:32 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/6/11 2:09 PM, fantasai wrote:
>>> And things get really interesting if the image is an SVG, where a ref
>>> already means something entirely different.
>> Presumably such refs match the identifier syntax
> Why would we presume that?
> Try loading this in your browser:
>  <svg xmlns="http://www.w3.org/2000/svg">
>  <defs>
>    <pattern id="xywh=10,30,60,20" width="1" height="1">
>      <rect width="100" height="100" fill="green"/>
>    </pattern>
>  </defs>
>  <rect width="500" height="500" fill="url(#xywh=10,30,60,20)"/>
>  </svg>
> Works for me in Gecko, WebKit, Presto, IE9.
> Basically, I think the media fragments draft is not backwards-compatible
> with current behavior and thus I think that using it should require explicit
> opt-in.

The behavior of fragments is defined per-mediatype.  SVG already
defines fragments in the standard XML fashion, so the Media Fragments
spec doesn't apply to it.

This may not be ideal, of course.  But all that section of the spec
really says is "CSS isn't doing anything about this", and then points
to another spec as an expected avenue where it'll be addressed.  If it
turns out we do need to address this ourselves, we can do it in Image
Values 4.

Received on Monday, 9 May 2011 21:41:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC