Re: Order and initial value of paint-order property

On Thu, Feb 13, 2014 at 9:12 AM, Dirk Schulze <> wrote:

> On Feb 13, 2014, at 2:34 PM, Erik Dahlström <> wrote:
> > On Thu, 13 Feb 2014 13:09:21 +0100, Dirk Schulze <>
> 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.

I also prefer auto.

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

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.

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

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

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.

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

Received on Thursday, 13 February 2014 15:00:48 UTC