Re: Ambiguities in fill:url() / stroke:url() syntax

On Mon, Oct 29, 2012 at 12:36 PM, Robert O'Callahan
<> wrote:
> On Mon, Oct 29, 2012 at 11:42 PM, Dirk Schulze <> wrote:
>> Does it mean that we have two different behaviors on <img>, <object> and
>> <iframe> on the one side and CSS Images on the other? That sounds worst.
> No, because <img>, <object> and <iframe> don't use "url()" syntax. They're
> simply irrelevant to all of this. The problem is only for users of "url()".

Yup, <img>/etc *can not* reference a paint server (or if they do, it
just doesn't do anything useful).  They're always image loads, so
there's no ambiguity here.  Plus, it's not url(), as roc says.

>> > (Although
>> >
>> > does have some polyfill that uses background:url() in Firefox.) So maybe the
>> > compat issue isn't that bad.
>> I would like to see a proposal first before we can continue discussing on
>> it further.
> I've made a few proposals here. Here's my current proposal:
> When "url(...)" appears as a CSS value,
> a) if the URI has no fragment identifier, treat it as an image load.
> b) if the URI has a fragment identifier that contains the characters '=',
> '(' or ')', treat it as an image load.
> c) otherwise, treat it as an external resource reference.

I am in favor of this proposal, now that it's clear that SVG Stacks as
typically used (an HTML element pointing to it with a url) don't

>> And we have not done the research if ::target is the only pseudo element
>> or use case for SVG fragments with influence on the painted result.
> I'm not sure what you mean by this.

:target is the only CSS thing that cares about the fragment of the document.


Received on Monday, 29 October 2012 11:52:36 UTC