Re: Order and initial value of paint-order property

On Feb 13, 2014, at 2:34 PM, Erik Dahlström <ed@opera.com> wrote:

> On Thu, 13 Feb 2014 13:09:21 +0100, Dirk Schulze <dschulze@adobe.com> wrote:
> 
>> Hi,
>> 
>> I was looking into implementing the paint-order property in WebKit today and have some questions and change requests[1]:
>> 
>> 
>> 1) Why normal keyword?
>> 
>> Why is there a normal keyword? Why not make the initial value: fill stroke marker?
> 
> Which would be better for future changes (new keywords, or possibly use outside of svg)? Would the initial value have to be changed, and what effects would that have on content?
> 
> To me 'normal' sounds a bit more future proof.
> 
>> I know that there are no markers for some elements. It shouldn’t be a problem to specify that in this case no markers are drawn.
> 
> The spec already states that the marker properties only apply to 'markable elements'. I don't see how 'paint-order' would affect that. In other words, I think it is clearly defined. I could add a note about this, but it would be repetition.
> 
>> I could see that this is problematic if we add another layer later. I am not sure if ‘auto' might make more sense as replacement for ’normal’.
> 
> "auto" and "normal" both sound about the same to me, and both keywords are used in other CSS properties. I prefer "normal" in this particular case.

I have a slightly preference for ‘auto’ and against ’normal’ since ‘auto’ seems to be used more… especially in new properties. I agree that a either ’normal’ or ’auto’ are more future proof though.

>> 2) Should we change the painting order by given keywords?
>> 
>> The behavior for ‘normal’ on a path element is like: fill stroke marker,
>> 
>> This is counter productive in a way that the order is the opposite to how ‘background', ‘fill' and ‘stroke’ operate on layers. Following these properties would be marker stroke fill. The last specified value gets drawn first.
> 
> Personally I find 'background' a bit backwards, "first specified is last drawn". But I don't feel strongly about this, either way is fine with me, I'll go with whatever the majority thinks is best (most readable).
> 
> I do prefer the way it's specified now, "first specified is first drawn" (using the painter's algorithm).

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.

> 
>> 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.
> 
> 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.

Greetings,
Dirk

> 
> 
> -- 
> Erik Dahlstrom, Web Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group

Received on Thursday, 13 February 2014 14:13:38 UTC