The CSS in the URL is parsed as "border-top: solid #0077ff 9px;" despite the missing space after #0077ff. I think #0077ff9px should be treated as one token and rejected.
<rdar://problem/6707824>
This seems to be the case from the spec: http://www.w3.org/TR/CSS21/grammar.html The lexical scanner given there will take the "#0077ff9px" and give a single HASH token, because it eats the '#' and then matches a name, which is "0077ff9px". Flex has "longest match" semantics, so this seems to be the correct interpretation. I am sure you knew this, just filling it in for context. Are there any possibility compatibility issues with this change?
(In reply to comment #2) > This seems to be the case from the spec: I am not sure I understand. Are you saying that WebKit behaves correctly? > Are there any possibility compatibility issues with this change? Firefox and Opera don't behave like WebKit.
(In reply to comment #3) > I am not sure I understand. Are you saying that WebKit behaves correctly? No, I was just trying to point out how the spec agrees with you.
Created attachment 55966 [details] Fix for Bug 24742 - CSS tokenizer allows color in 6 hex digit notation to be followed by the next token without separation
Ping?
Comment on attachment 55966 [details] Fix for Bug 24742 - CSS tokenizer allows color in 6 hex digit notation to be followed by the next token without separation Rejecting patch 55966 from commit-queue. Failed to run "['WebKitTools/Scripts/run-webkit-tests', '--no-launch-safari', '--exit-after-n-failures=1', '--wait-for-httpd', '--ignore-tests', 'compositing,media', '--quiet']" exit_code: 1 Running build-dumprendertree Compiling Java tests make: Nothing to be done for `default'. Running tests from /Users/eseidel/Projects/CommitQueue/LayoutTests Testing 20909 test cases. svg/custom/invalid-fill-hex.svg -> failed Exiting early after 1 failures. 18102 tests run. 376.27s total testing time 18101 test cases (99%) succeeded 1 test case (<1%) had incorrect layout 26 test cases (<1%) had stderr output Full output: http://queues.webkit.org/results/3944067
Eric, Sorry, I forgot to mention here that this patch depends on a SVG fix. https://lists.webkit.org/pipermail/webkit-dev/2010-June/013358.html Having heard no updates from Nikolas or Dirk, I think we should just fix svg/custom/invalid-fill-hex.svg. That is, to remove 'stroke="#0"' from: LayoutTests/svg/custom/invalid-fill-hex.svg <rect width="100" height="100" fill="#ff" stroke="#0"/> What do you think?
Committed r67158: <http://trac.webkit.org/changeset/67158>