- 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
FYI: 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 reference. - 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 properties. 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 https://github.com/w3c/csswg-drafts/issues/383#issuecomment-238762289 using your GitHub account
Received on Wednesday, 10 August 2016 04:21:30 UTC