Re: Follow-Up: Elliptical arc minimal syntax

Just a question to ed's suggestion:

number comma-wsp flag comma-wsp? flag comma-wsp coordinate-pair

If we use 'comma-wsp?' between the flags in arc, why don't we use it
after the two flags as well?

Dirk

> http://lists.w3.org/Archives/Public/www-svg/2010Apr/0031.html
> 
> === BEGIN SNIP ===
> 
> ed: We should allow for skipping of space and comma between
> largeArcFlag and the sweepFlag
> ... Instead of ', *wsp' it should be ',wsp?'
> 
> <ed> so change elliptical-arc-argument to become this:
> 
> <ed> nonnegative-number comma-wsp? nonnegative-number comma-wsp?
> 
> <ed> number comma-wsp flag comma-wsp? flag comma-wsp coordinate-pair
> 
> === END SNIP ===
> 
> Actually I don't believe this is good enough.  I have done some more
> thorough research on this discrepancy.  Here are my results:
> 
> 1) All browsers except for WebKit parse the elliptical-arc-argument
> production as:
> 
> elliptical-arc-argument:
>     nonnegative-number comma-wsp? nonnegative-number comma-wsp?
>         number comma-wsp flag comma-wsp? flag comma-wsp? coordinate-pair
> 
> i.e. a comma-wsp? between the two flags and between the sweep-flag and
> the coordinate-pair.
> 
> 2) WebKit also accepts values for 'flag' other than "0" or "1" (and
> interprets anything other than "1" as a "0").  I've looked at the
> code.
> 
> Here is my test case:
> 
> <?xml version="1.0"?>
> <svg xmlns="http://www.w3.org/2000/svg">
> 
>     <!-- This tests parsing rules of the flags in the arc path command.
>          No red should be visible, only green -->
> 
>     <!-- this tests that the two flags do not need whitespace between them -->
>  <path fill="red" d="M200,200 h-150 a150,150 0 0,0 150,-150 z"/>
>  <path fill="green" d="M200,200 h-150 a150,150 0 00 150,-150 z"/>
> 
>     <!-- this tests that the last flags does not need whitespace between it
>          and the x-coordinate -->
>  <path fill="red" d="M500,200 h-150 a150,150 0 0,1 150,-150 z"/>
>  <path fill="green" d="M500,200 h-150 a150,150 0 01 150,-150 z"/>
> 
>     <!-- this tests that only flags with a 0 or 1 are valid, otherwise
> the path is in error -->
>  <path fill="green" d="M800,200 h-150 a150,150 0 0,0 150,-150 z"/>
>  <path fill="red" d="M800,200 h-150 a150,150 0 0,8 150,-150 z"/>
> 
>     <!-- these two sub-tests test that the same rules apply when flags
> are 0 or 1 -->
>  <path fill="red" d="M200,500 h-150 a150,150 0 1,0 150,-150 z"/>
>  <path fill="green" d="M200,500 h-150 a150,150 0 10 150,-150 z"/>
> 
>  <path fill="red" d="M700,650 h-150 a150,150 0 1,1 150,-150 z"/>
>  <path fill="green" d="M700,650 h-150 a150,150 0 11 150,-150 z"/>
> 
> </svg>
> 
> In Firefox, Opera, IE9 all paths are green.  In WebKit all paths are
> red.  Batik reports an error when a flag value other than "0" or "1"
> is present and refuses to render the entire file (boo!).  If I remove
> the offending path, Batik renders the other four sub-tests as green.
> 
> Since Firefox, Opera, Batik and IE9 all support the above, I guess it
> would make sense for WebKit to align with this for interoperability.
> I will raise a bug against WebKit.  Is there a ruling on which spec
> will be updated for this?  Can we get an official word from the SVG WG
> so I can link to it?
> 
> Thanks,
> Jeff Schiller
> 
> P.S.  I know I owe Chris Lilley a response on the points syntax too.

Received on Monday, 12 April 2010 06:03:18 UTC