- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 13 May 2015 15:59:10 -0700
- To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, www-svg <www-svg@w3.org>
On Tue, May 12, 2015 at 6:42 AM, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com> wrote: > - Particularly for strokes of different widths, it is preferable to allow > multiple solid color layers without needing hacks such as single color > gradients or extra markup to create a solidColor paint server element. This is accomplishable through the image() function; you can omit the urls and just supply a color, and you'll get a solid-color image. Easier and less hacky than using a linear-gradient and repeating the color. > - It would be very useful to create paint server elements that can be > customized by passing a color property at the time they are used. We have a number of mechanism to accomplish this already; currentColor, use-color (or whatever it's called), var(). I can't quite tell, from the proposal, what the "context" stuff is trying to do. Can you elaborate? > The idea of the *-index properties came from the need to control the > layering of three different stacks of paint content (fill, strokes, and > markers) rather than a single stack for background images. We already have 'paint-order' for controlling the relative ordering of fill/stroke/markers. Within strokes/fills/etc, ordering is controlled by the order in which they appear. It seems like the only new thing added by *-index is the ability to interleave stroke/fill/marker painting, but that's a rather new thing that hasn't had any use-cases presented for it, and its functionality directly overlaps with 'paint-order'. > If there is a strong desire to add back in the other background properties > (e.g., *-position, *-origin, *-clip, *-repeat, *-attachment, *-size), I'd be > happy to hear those arguments. However, I really think they confuse things > with unnecessary complexity more than they simplify things with similarity > to the background shorthand. They need to be in there. CSS paint servers are usable with SVG as well, and proper use of them requires those properties. Yes, they more or less overlap with <pattern> use, but having them in a property form is useful, and keeps them close to the CSS properties we're deriving these from. > I'm not sure why there would be a need for CSS WG review first, since these > would be SVG-specific properties. However, I would be happy to have > additional feedback if you want to suggest that group members take a look at > the proposal. I definitely want to discuss the *-box properties with those > active on the FX specs that use SVG graphical effects elements with > objectBoundingBox vs userSpaceOnUse units. There's no such thing as "SVG-specific properties". They're still CSS, even if they only have an effect on SVG elements, and review by the CSSWG prevents problems. We can help ensure that they don't make common mistakes, and that they are in line with modern design patterns for properties. This, in particular, is a big, involved proposal. I would strongly object to doing anything with it without extensive CSSWG review and feedback; there are several points I note from a quick read that should be changed. I'll need to spend some time reviewing this more thoroughly. ~TJ
Received on Wednesday, 13 May 2015 22:59:58 UTC