- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 21 Mar 2016 11:34:02 -0700
- To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Cc: Andrew Fedoniouk <news@terrainformatica.com>, www-style list <www-style@w3.org>
On Sun, Mar 20, 2016 at 10:22 PM, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com> wrote: > 1) Create a shorthand-notation for defining an SVG-style image consisting of > a single shape within CSS. > > This is certainly feasible. There are pre-processor tools that are already > doing this (without the limitation to a single shape), compiling to a data > URI with SVG markup. It is logically consistent to the CSS gradient > functions creating an image data type. Agree that this is possible and consistent, but I question its value. Simple shapes aren't all that useful, particularly as one-offs. > 2) Have SVG-related CSS properties declared on the same element apply to the > generated image > > This is not feasible, at least not in the way you proposed. For many > properties, it would be ambiguous whether you were trying to style the > background SVG or the element itself. This would be especially true if > proposed fill + stroke for CSS-styled text is adopted. And what if you > wanted to layer together multiple background shapes? Or declare a shape for > a list-image custom bullet instead of a background-image? Strongly agree. No way this would work, ever. > The pre-processor approaches address this by either including all SVG > styling rules within the mix-in function notation, or by using a custom > @-rule to declare the SVG content and styles as a structured object, which > can then be used in individual elements (similar to how font-face declares > all the data for a named font that can then be assigned in font-family > declarations). > > With SVG code generated by a pre-processor, you cannot create live styling > changes or animations. However, with a function notation this should be > possible, similar to the proposal (already implemented in some browsers) for > animating gradients. I have the start of a draft to be able to write SVG directly in your CSS stylesheet and then ref it as an image - it's what the PostCSS @svg rule was directly based on. (I haven't actually written it up, it looks like, but the idea is trivial - just convert elements into @-rules and attributes into properties. There are some questions to deal with about IDs and such, which def need to be answered, but the gist is easy to understand.) > 3) Develop a new syntax to define SVG paths with certain points that stretch > relative to 100% width or height > > This is not feasible in the way you proposed, but should be feasible in > general. However, it should be defined for SVG in general, not just a > special CSS syntax. It's certainly something that's been requested on the > SVG side previously. Negative numbers already have a valid meaning in SVG > paths, so that won't work, but other syntaxes could. > > I've just posted a proposal to the SVG working group's issue tracker to > encourage us to think seriously about it: > https://github.com/w3c/svgwg/issues/72 Yes, this would be useful, but it also needs to take place as part of an overall overhaul of path syntax. Current path syntax is *terrible*: it tries to satisfy both "hand authorability" and "minimal byte size" and only succeeds in being pretty bad at both; it's not extensible in many ways (letters always start new path commands, so it's very hard to add anything like units); some commands are inscrutable and very difficult to hand-author, like the curve commands. > As others have noted, CSS shapes is already adopting SVG path notation for > things such as clip-path and motion path. A new image-generation function > would want to be compatible with these syntaxes. Yup. ~TJ
Received on Monday, 21 March 2016 18:34:49 UTC