W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2016

Re: [csswg-drafts] [css-images][css-masking][paint] Ambiguities in handling url()

From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
Date: Wed, 10 Aug 2016 04:21:23 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-238762289-1470802881-sysbot+gh@w3.org>

I wrote up [detailed URL-handling rules for SVG 
2](https://svgwg.org/svg2-draft/linking.html#processingURL) as part of
 the overhaul of use-element handling.  I tried to be consistent with 
CSS/FX specs (particularly Masking) to the extent that they had any 
guidance, but if you're adding new guidance you may want to review 
that section and make sure we're still consistent.

Key parts that are relevant to CSS:

- If a property can only accept an image file reference, treat the URL
 as an image file. Any target fragment is used when rendering that 
image, but doesn't define a relevant target.

- If a property can accept either an image file or an element 
reference, and the referenced document can be parsed as a DOM, 
identify the targetted element to determine if it is a valid 
reference. If it is not, re-interpret the URL as an image file 

- If a property _can_ accept an element reference, and the URL does 
not have a target fragment, treat it as a reference to the root 
element when determining if it is a valid reference.  This was based 
on a long-standing SVG feature request for `<use>` element references 
(to be able to use a separate SVG without editing it to add an `id` on
 the root element).  If it is going to be a problem with CSS image 
properties, we may want to restrict that behavior.

- External resources specified in style properties are fetched with 
CORS anonymous mode, so there shouldn't be security restrictions on 
whether the file is parsed as an SVG asset document or an SVG image.

 I was only focusing on `url()` references, not on `image()` vs 
`element()`, and I was of course only focusing on SVG-defined 

I like the idea of using functions to clarify which way you want to 
interpret the reference.  I'm slightly concerned about confusion with 
the other use of `element()`, to the rendered image data from an 
element in the current DOM.  That's conceptually quite different from 
referencing an element that describes a graphical effect to apply.

I'm not too keen on having different rules for CSS-defined properties 
vs SVG-defined properties.  That just seems like grounds for 
confusion.  I realize there is a theoretical backwards-compatibility 
issue when allowing SVG paint servers as a CSS image type (a URL that 
would formerly be interpretted as an SVG image with :target styles now
 being interpretted as a paint server reference), but I think it is 
exceedingly rare in practice that :target styles are tied to a paint 
server element.  The bigger concern would be whether there are 
substantial performance impacts from parsing the document to identify 
the element before deciding to treat it as an image: i.e., can 
implementations switch from "effects" mode to "image" mode without 
repeating the basic parsing & DOM construction?

GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at 
using your GitHub account
Received on Wednesday, 10 August 2016 04:21:30 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:01 UTC