- From: Jeff Schiller <codedread@gmail.com>
- Date: Mon, 12 Apr 2010 00:59:51 -0500
- To: Dirk Schulze <vbs85@gmx.de>
- Cc: www-svg <www-svg@w3.org>
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