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

On Mon, Oct 29, 2012 at 12:50 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> On 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()".
>
> With the ideas on whatwg, we might get a common syntax anyway. Who knows? I would not treat them differently.

I don't think there's any proposal for that yet.  If there are in the
future, we'll just match the behavior of CSS.  That might make <img
src="url(foo)"> different than <img src="foo">, but whatever.


>> > (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.
>
> With this proposal, SVG stacks would not be possible, correct? That was what I asked for. And I would be opposed to it. Or we make SVG Stack possible with  '=', '(' or ')' and I would like to see how it looks like.

With this, SVG Stacks *using certain kinds of idents* aren't possible
to reference *inside of CSS*.  They're still totally okay in
<img>/etc., which is the primary use right now.

~TJ

Received on Monday, 29 October 2012 11:54:30 UTC