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

On Oct 29, 2012, at 5:07 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

> On Mon, Oct 29, 2012 at 4:07 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> Now to CSS Images on 'fill' and 'stroke'. If you really want to reference an image, or interpret an SVG as image (and not as resource). And if you want this image as paint server (we don't allow it currently; would be new), then you need the image() function.
>> 
>>         fill: image(url(image.svg#id))
> 
> Actually I think you could just use image(image.svg#id)?
>  
>> For masking, I opened a different thread "[css-masking] 'mask' with resource and image references". I think we have two possibilities (that are not hacky):
>> 1) 'mask-image' does not get a short hand
>> 2) The short hand for 'mask-image' gets renamed and  splitter from 'mask'. 'mask' will continue to just use <mask> references.
>> 
> I don't see that thread yet. One problem with those ideas (and any similar ideas) is that it means you can't just unprefix -webkit-mask by taking off the prefix, you have to change the property name too. That might be hard for authors to deal with. But it might be OK. I'd like to hear a specific proposal for mask though.

Sad but often true: people who use -webkit-mask don't care about an unprefixed mask property. If they would do, they would try to use the alternative for FF that already exists. In WebKit it self, it would not be a problem to just use a different property name for the unprefixed version.

> 
> Anyway, if I understand correctly, your proposal is to not allow url() from CSS Image Values to be used for properties that already take an external resource reference, i.e. don't fully unify CSS Image Values with SVG paint servers. That's definitely a reasonable option. Tab would be disappointed though :-).

I kind of like the proposal to add a new media fragment. But first, I don't think that it will be as easy as the current way to do SVG stacks (the current version just works because of selector pseudo elements, which would need to be simulated) and after all, even WebKit supports SVG stacks. You can not use it with CSS Image values so, but you can use it in combination with the <object> tag. One specification already makes use of that, Filter Effects [1].

And there already exists an quite popular tool to create SVG stacks: https://github.com/preciousforever/SVG-Stacker
The tool can be changed. But content that was created with it so far, just stops working. And if that happens, we might disappoint people and they won't use it anymore. It would also take some time for browsers to ramp up. In the meantime we have specs that are incompatible with browsers (like CSS masking and so on).

Greetings,
Dirk

[1] http://www.w3.org/TR/filter-effects/#shader-processing-model

> 
> PS: After discussing all these issues, does it mean that we can't extend element() to reference external documents?
> 
> I think that's unaffected. element() references would never load as images.
> 
> Rob
> -- 
> “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others?" [Matthew 5:43-47]
>

Received on Monday, 29 October 2012 04:46:05 UTC