Re: Order and initial value of paint-order property

On Thu, Feb 13, 2014 at 9:12 AM, 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.
>

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
"paint-order".

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