[whatwg] fillRule changes

[Ian Hickson]

Since browsers implemented a different fillRule API than what the spec 
had, I've updated the spec to better match implementations.

Because the browsers just went ahead and implemented this, I didn't end up 
responding to the feedback on this topic, since the reply to all that 
feedback is "the spec now says what the browsers implemented". :-)

Comments below on orthogonal comments in those same e-mails:

On Thu, 3 Jan 2013, Rik Cabanier wrote:
> > > > On Wed, 2 Jan 2013, Rik Cabanier wrote:
> > > > >
> > > > > this features is not a trivial as it seems. Adding this will 
> > > > > necessitate updates to the algorithms that deal with paths and 
> > > > > the outlining of strokes and text.
> > > >
> > > > Can you elaborate on what updates are needed? I couldn't see any 
> > > > that actually needed to be changed.
> > >
> > > One of the intents of the path object is so you can 'accumulate' the 
> > > regions that were drawn so you can set them up as hit regions.
> >
> > It is? I don't think that's one of the use cases I've seen before. 
> > It's an interesting use case, though, true.
> 
> A region can be a bunch of shapes so I assumed that the path object was 
> designed to accommodate this. For instance a stroked rectangle would be 
> a region and consist of a rect path and the stroked rect path.

Well you can certainly do that, sure, and we could provide an API that 
combines paths as a union rather than just adding the path segments 
(indeed at one point we had that in one of the earlier strawman 
proposals), but that's not one of the use cases that Path was originally 
designed for. The idea is that you'd just create separate regions for each 
of the paths, rather than combining them and having one region. The net 
result is the same.


> I think the spec needs to mention that
> - sections of the path where both edges are filled should be removed
> - winding needs to be done so eofill and fill give the same result

I've filed a bug for adding something like this:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=21835

I'm not sure exactly what the algorithm should be (as we discussed on IRC 
today), so if anyone has any input here, please don't hesitate to comment.


On Wed, 9 Jan 2013, James Ascroft-Leigh wrote:
> 
> How can the presence of the winding rule parameter of the fill() and 
> clip() operations be detected by client code?  Perhaps I missed 
> something in the discussion.

On Wed, 9 Jan 2013, Boris Zbarsky wrote:
> 
>   var ruleArgSupported = false;
>   try {
>    ctx.fill({ defaultValue: function() { ruleArgSupported = true; return false; } });
>   } catch (e) {
>     // Really shouldn't happen, but who knows
>   }

Since the browsers ended up implementing this as an enum, this will work:

  var ruleArgSupported = false;
  c.fill({ toString: function() { ruleArgSupported = true; return 'evenodd'; } });


On Tue, 15 Jan 2013, Simon Sarris wrote:
> 
> The current *fillRule *rules in the specification seem incomplete or at 
> least ill-defined with respect to consideration of hit regions.

I've added a fillRule argument to the HitRegionOptions dict.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'