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

On Mon, Oct 29, 2012 at 12:36 PM, Robert O'Callahan
<robert@ocallahan.org> wrote:
> On Mon, Oct 29, 2012 at 11:42 PM, Dirk Schulze <dschulze@adobe.com> 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
>> > http://preciousforever.github.com/SVG-Stacker/examples/wikipedia/commons/stack/stack-demo-css-hack.html
>> > 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
interfere.

>> 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.

~TJ

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