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

Re: Order and initial value of paint-order property

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 13 Feb 2014 09:33:19 -0800
Message-ID: <CAAWBYDDCiqijP9M0POdBvpwW2Z1sc7iqFkbdS+kTc-+YFgxrGA@mail.gmail.com>
To: Erik Dahlström <ed@opera.com>
Cc: Dirk Schulze <dschulze@adobe.com>, www-svg <www-svg@w3.org>
On Thu, Feb 13, 2014 at 7:26 AM, 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:
>>>> 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.

Yup.  We're not totally consistent about it, but we usually do try to
reserve "auto" for "do something magic automatically".  I prefer
either "normal" or just "fill stroke markers" as the initial value.

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

Agreed. While I don't have a strong opinion on this, the current order
was the most intuitive to me initially.

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

Yes, I don't think we need extra behavior here.  Having two ways to do
something complicates debugging, for example.

Received on Thursday, 13 February 2014 17:34:06 UTC

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