Re: [css-shapes] Purpose of fill-rule not specified

Thanks for tracking that down, Alan, that all seems perfectly reasonable. I
suspect that for 99.9% of Level 1 use cases the Webkit behaviour will make
no difference at all, and for the .1% that expose the "bug" they should be
able to work around it by changing the shape path to remove the degenerate
line segments. I still think you should keep the spec as-is, though,
because it could be important at later levels.

Regards,
Tom

On 24 July 2015 at 21:48, Alan Stearns <stearns@adobe.com> wrote:

> On 7/23/15, 11:54 AM, "Tom Potts" <karaken12@gmail.com> wrote:
>
> >
> >
> >On 23 July 2015 at 16:38, Alan Stearns <stearns@adobe.com> wrote:
> >>
> >> On 7/23/15, 8:17 AM, "Tom Potts" <karaken12@gmail.com> wrote:
> >>
> >> >Okay, that makes sense, although I think you need a note to be clear
> >>that
> >> >the shape used in shape-outside is calculated as if nonzero was
> >>specified,
> >> > otherwise it starts to look inconsistent when you consider the effect
> >>of
> >> >infinitely thin spurs. (See this demo
> >> ><http://codepen.io/karaken12/pen/bdmbwg?editors=110> to
> >> > see what I mean.)
> >>
> >> I agree the inconsistency is weird. We should probably have the same
> >> behavior for both cases, and I don’t have a strong preference for either
> >> behavior. Do you have an argument for one over the other?
> >
> >I don't have a strong preference either, as long as the expected
> >behaviour is clear. My (mild) preference is for the fill-rule setting to
> >be respected, because in future levels a central void might be useful
> >(I'm thinking about the examples in
> > earlier versions of the spec with text flowing "through" a float) and if
> >that ever happens we'd either need to change the spec at that point, or
> >admit inconsistent behaviour. I think the current behaviour in Chrome
> >with spurs (ignored for basically everything)
> > fits well with that.
> >
> >>
> >> >
> >> >Was there any particular reason for choosing this behaviour, by the
> >>way?
> >> >As I mentioned, it wasn't what I expected on reading the spec, but I
> >> >can't find any discussion as to why it works this way.
> >>
> >> I don’t see where this ever came up on the list, so it’s likely my fault
> >> for not forwarding on some implementation discussion.
> >
> >It'd be interesting to know why, if there's a quick answer, but I don't
> >think the details matter too much. If it's an implementation detail
> >that's fine, but if there's a good reason to prefer one or the other it'd
> >be good to have that reason recorded
> > somewhere.
>
> OK, I searched through my email archive and found that I was entirely
> incorrect. Float wrapping *should* respect fill-rule as you expected. I
> had internalized a temporary implementation limitation. The Chrome and
> WebKit behavior for your case 3 should be considered a bug.
>
> This came up when we separated out our shape-inside experiments from the
> shape-outside implementation. This allowed us to use a much simpler
> algorithm, but it had a drawback of breaking support for fill-rule (which
> up to that point had been working correctly). Hans Muller blogged about
> this 16 months ago (see the “Degenerate Polygons” section):
>
> http://hansmuller-webkit.blogspot.com/2014/03/a-simpler-algorithm-for-css-s
> hapes.html
>
> I didn’t mention this on www-style at the time because I considered it a
> temporary regression. And then I forgot about it. I’ll add an example to
> the spec that shows what should happen. Then we’ll see whether
> implementations will match that expectation.
>
> Thanks,
>
> Alan
>