W3C home > Mailing lists > Public > www-svg@w3.org > February 2014

Re: Order and initial value of paint-order property

From: Dirk Schulze <dschulze@adobe.com>
Date: Thu, 13 Feb 2014 16:49:08 +0000
To: Stephen Chenney <schenney@chromium.org>
CC: Erik Dahlström <ed@opera.com>, www-svg <www-svg@w3.org>
Message-ID: <0E610CEE-9A98-43BF-B27F-DC38095AF696@adobe.com>

On Feb 13, 2014, at 4:00 PM, Stephen Chenney <schenney@chromium.org> wrote:

> The main problem is not necessarily ’background’ as property, but that we follow ‘background’ for the ‘fill’ and ’stroke’ properties (which makes sense IMO). It seems very odd that ‘paint-order’ uses the opposite reading order to drawing order from fill/stroke/background. I think this will be very confusing in the long term. We should consider that. There might be different opinions if it was the right choice for background in the first place, but that is nothing that we can or should change.
> 
> What 'background' spec are you referring to? All I can find is how to paint a list of images, and that's a somewhat different context to the one we have here.

CSS Background and Borders [1]. And yes, it is stacking your images. And fill and stroke stack their paint operations if you have multiple fill or stroke layers. I think these are comparable to paint-order because all of them stack paint operations.

> 
> >
> >> 3) Allow to not draw a layer
> >>
> >> The spec says that an omitted keyword is drawn last (and then in order as if ’normal’ was specified). This doesn’t allow to omit a layer on purpose. I would suggest that the layer that wasn’t specified doesn’t get drawn. This allows specifying stroke, fill and marker and control what gets drawn just with paint-order.
> >
> > I can see why you would think that way, "paint-order: fill stroke" sounds a bit like it wouldn't draw markers.
> >
> > However, if we allow disabling painting then 'paint-order' is no longer just about the order of painting operations. If you don't want fill/stroke/marker then you can just set them to "none" in css. I don't think we should let 'paint-order' disable painting.
> 
> The "one property controls one thing" argument is good in my mind. It makes for simpler logic, simpler debugging and a more orthogonal spec. As currently written, paint-order is about "order", not paint on/off.

That is correct. They do not control if a paint layer should be visible or not. I just think it is convenient if you can do this with such a property as well - in a very easy way. 

>  
> > If we add another keyword later on, which would make more sense? Rendering as usual taking into account the new keyword, or disabling all the new keywords?
> 
> Why add a new property if the the same can do both. To be honest, if I would just specify paint-order: stroke, I would not expect that the other layers are drawn under the stroke. Of course you could set stroke, fill or marker to none. It just seems convenient to do it with one property.
> 
> New property? I believe Erik was referring to a new paint order keyword, say a hypothetical "linecaps" paint step. You wouldn't want all existing content to stop drawing linecaps because it's not in the existing "paint-order”.

No, I don’t think that he suggested more keywords but rather to use the existing properties and reset fill, stroke and markers individually.

> 
> If you really want to have one property control both the inclusion/exclusion of paint stages, and the ordering, then it should be called "paint-stages" or "paint-steps" and not "paint-order". But I am not supporting that because of the future-proofing and orthogonality arguments.

The name is less important than the functionality. I am fine with renaming the property if that is the biggest problem. I personally think that the possibility to skip drawing of certain paint types is more convenient. I do not understand your last comment about future-proofing. Why would one or the other way be less future-proofing?

Greetings,
Dirk

[1] http://www.w3.org/TR/css3-background/
Received on Thursday, 13 February 2014 16:49:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:35 UTC