- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 13 Feb 2014 09:33:19 -0800
- 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. ~TJ
Received on Thursday, 13 February 2014 17:34:06 UTC