- From: Dirk Schulze <vbs85@gmx.de>
- Date: Mon, 12 Apr 2010 07:56:04 +0200
- To: Jeff Schiller <codedread@gmail.com>
- Cc: www-svg <www-svg@w3.org>
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