Re: Order and initial value of paint-order property

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

> On Thu, 13 Feb 2014 15:12:37 +0100, Dirk Schulze <dschulze@adobe.com> wrote:
> 
>> 
>> 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.
> 
> Yes, 'auto' is used more, but it often seems to imply calculations of some sort, like with "width:auto" for example. With 'paint-order" it's really mostly a keyword for "the default", which seems to be how "normal" is typically used in other properties.
> 
> 
>>>> 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.
> 
> Sure, for 'background' what's done is done.
> 
> If we're looking for other properties with with effects being applied in the specified order, we find e.g 'filter', [[ If the value of the ‘filter’ property is ‘none’ then there is no filter effect applied. Otherwise, the list of functions are applied in the order provided. ]].
> 
> I'm open to swapping the order of the keywords in 'paint-order', but would like to hear what others think too.

You can not comport transform (another example for lists) and filters with something that changes the stacking order of your different painting operations. Comparing background, fill and stroke with the more general concept paint-order makes as lot of sense. Both control the stacking of your different paint operations. Mixing up the stacking order across properties is what I would call “considered harmful” :P.

> 
> 
>>>> 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.
> 
> My point is: we already have properties that allow you to toggle the drawing off or on individually, ie 'fill', 'stroke' and 'marker'. We don't need another property for doing that.
> 
> Allowing 'paint-order' to toggle the drawing for each of the keywords would also imply that we need to define how that works wrt the various boundingboxes, among other things. What you are proposing I see as added complexity for very little gain.

The complexity is minimal. You already ask CSS in which order you draw. So you can just switch off the current part that you want to draw. Actually, ordering the other keywords after the specified keywords is more complex, since you need more logic to make sure that you get the ordering correctly.

Also, paint-order is a visual property. Why would it influence the bounding boxes in any way?

Greetings,
Dirk

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

Received on Thursday, 13 February 2014 16:42:49 UTC