Bug 82368

Summary: CSS Exclusions polygon shape arguments should be comma separated
Product: WebKit Reporter: Bear Travis <betravis>
Component: CSSAssignee: Hans Muller <giles_joplin>
Status: RESOLVED FIXED    
Severity: Normal CC: giles_joplin, macpherson, menard, rniwa, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 82363    
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch none

Bear Travis
Reported 2012-03-27 12:08:33 PDT
The spec draft http://dev.w3.org/csswg/css3-exclusions/ says that the polygon shape's arguments should be comma separated. Currently points are space-separated as x,y value pairs.
Attachments
Patch (16.75 KB, patch)
2012-03-29 11:23 PDT, Hans Muller
no flags
Patch (17.49 KB, patch)
2012-03-30 16:37 PDT, Hans Muller
no flags
Patch (25.94 KB, patch)
2012-04-03 17:19 PDT, Hans Muller
no flags
Patch (24.50 KB, patch)
2012-04-05 16:12 PDT, Hans Muller
no flags
Hans Muller
Comment 1 2012-03-29 11:23:07 PDT
Ryosuke Niwa
Comment 2 2012-03-29 14:27:22 PDT
Comment on attachment 134623 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=134623&action=review > Source/WebCore/ChangeLog:11 > + This change is per the draft exclusions spec, http://dev.w3.org/csswg/css3-exclusions. This change is not mentioned any where in http://dev.w3.org/csswg/css3-exclusions/#supported-svg-shapes. Could you clarify why we're making this change. Maybe a link to a public mailing list discussion? > Source/WebCore/css/CSSParser.cpp:4285 > + // <length>, <length>, ... <length>, <length> -> each pair has 4 elements except the last one > + if (!size || (size % 4) - 3) Can it have an optional comma at the very end?
Hans Muller
Comment 3 2012-03-29 15:26:43 PDT
(In reply to comment #2) > > Source/WebCore/css/CSSParser.cpp:4285 > > + // <length>, <length>, ... <length>, <length> -> each pair has 4 elements except the last one > > + if (!size || (size % 4) - 3) > > Can it have an optional comma at the very end? My interpretation of http://www.w3.org/TR/css3-values/#functional-notation is that a trailing comma is not allowed.
Hans Muller
Comment 4 2012-03-29 15:37:45 PDT
(In reply to comment #2) > (From update of attachment 134623 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=134623&action=review > > > Source/WebCore/ChangeLog:11 > > + This change is per the draft exclusions spec, http://dev.w3.org/csswg/css3-exclusions. > > This change is not mentioned any where in http://dev.w3.org/csswg/css3-exclusions/#supported-svg-shapes. My understanding was that "<length>{2}#" implied that all arguments were to be comma separated (as in http://dev.w3.org/csswg/css3-values/#component-multipliers and http://www.w3.org/TR/css3-values/#functional-notation) and Vincent Hardy, one of the spec editors, confirmed as much. > Could you clarify why we're making this change. Maybe a link to a public mailing list discussion? Don't know if this point was discussed on a public forum, looking into that now...
Ryosuke Niwa
Comment 5 2012-03-29 15:39:14 PDT
(In reply to comment #4) > > Could you clarify why we're making this change. Maybe a link to a public mailing list discussion? > > Don't know if this point was discussed on a public forum, looking into that now... But this should certainly be mentioned in the spec, right? I'd rather wait until the spec is changed to explicitly state this.
Hans Muller
Comment 6 2012-03-30 16:37:40 PDT
Hans Muller
Comment 7 2012-03-30 16:48:12 PDT
(In reply to comment #5) > (In reply to comment #4) > > > Could you clarify why we're making this change. Maybe a link to a public mailing list discussion? > > > > Don't know if this point was discussed on a public forum, looking into that now... > > But this should certainly be mentioned in the spec, right? I'd rather wait until the spec is changed to explicitly state this. Thanks for pushing back on this point, my interpretation of the spec (http://dev.w3.org/csswg/css3-exclusions/#supported-svg-shapes) was incorrect. The spec says that the syntax for polygon is "polygon([<fill-rule>,]? <length>{2}#)", where the hash mark means that each space separated pair of lengths (except for the last one) is followed by a comma (http://dev.w3.org/csswg/css3-values/#component-multipliers). So an example of the correct polygon syntax is: polygon(evenodd, 0px 0px, 10px 100px, 300px 50px); I've updated the parser and tests to reflect this.
Ryosuke Niwa
Comment 8 2012-04-03 02:03:16 PDT
Comment on attachment 134913 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=134913&action=review > Source/WebCore/css/CSSParser.cpp:4305 > + else if (commaOrNull->unit != CSSParserValue::Operator || commaOrNull->iValue != ',') We should really extract an inline helper function for this.
Hans Muller
Comment 9 2012-04-03 17:19:12 PDT
WebKit Review Bot
Comment 10 2012-04-05 09:44:49 PDT
Comment on attachment 135462 [details] Patch Rejecting attachment 135462 [details] from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2 Last 500 characters of output: /webkit-commit-queue/Source/WebKit/chromium/tools/gyp --revision 1293 --non-interactive --force --accept theirs-conflict --ignore-externals' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' 43>At revision 1293. ________ running '/usr/bin/python tools/clang/scripts/update.py --mac-only' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' ________ running '/usr/bin/python gyp_webkit' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' Updating webkit projects from gyp files... Full output: http://queues.webkit.org/results/12340379
Hans Muller
Comment 11 2012-04-05 16:12:11 PDT
WebKit Review Bot
Comment 12 2012-04-05 18:18:28 PDT
Comment on attachment 135927 [details] Patch Clearing flags on attachment: 135927 Committed r113400: <http://trac.webkit.org/changeset/113400>
WebKit Review Bot
Comment 13 2012-04-05 18:18:33 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.