Re: Follow-Up: Elliptical arc minimal syntax

Dirk,

That is my point and why I said "I don't believe this is good enough".
 Or at least it doesn't support what most browsers do today.

Opera, Firefox and IE9 all make the whitespace/comma after a flag
optional (either between the two flags or between the flag and the
coordinate-pair).

See WebKit Bug 37431: https://bugs.webkit.org/show_bug.cgi?id=37431
with patch :)

Jeff

On Mon, Apr 12, 2010 at 12:56 AM, Dirk Schulze <vbs85@gmx.de> wrote:
> 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:00:24 UTC