RESOLVED FIXED 61449
Update RGBA color serialization to match HTML5
https://bugs.webkit.org/show_bug.cgi?id=61449
Summary Update RGBA color serialization to match HTML5
Andreas Kling
Reported 2011-05-25 10:19:59 PDT
As of this change: http://html5.org/tools/web-apps-tracker?from=5874&to=5875 HTML5 now specifies that zero alpha values should be serialized to "0". We currently yield "0.0" or "0." followed by 5 decimals to match Gecko, but Firefox nightlies are now returning "0" or "0." followed by the least number of decimals necessary.
Attachments
Proposed patch (40.64 KB, patch)
2011-05-25 10:31 PDT, Andreas Kling
no flags
Proposed patch v2 (1.33 KB, patch)
2011-05-25 11:22 PDT, Andreas Kling
no flags
Proposed patch v2 (40.57 KB, patch)
2011-05-25 11:24 PDT, Andreas Kling
benjamin: review+
webkit.review.bot: commit-queue-
Archive of layout-test-results from ec2-cr-linux-01 (1.21 MB, application/zip)
2011-05-25 22:47 PDT, WebKit Review Bot
no flags
Andreas Kling
Comment 1 2011-05-25 10:31:59 PDT
Created attachment 94807 [details] Proposed patch
Benjamin Poulain
Comment 2 2011-05-25 11:00:37 PDT
Comment on attachment 94807 [details] Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=94807&action=review > Source/WebCore/platform/graphics/Color.cpp:211 > + if (!hasAlpha()) > + result.append('1'); > + else if (!alpha()) I don't know how often this is called (or if the compiler does a good job here) so maybe that is not relevant. But this will call alpha() twice: for hasAlpha() and second check for hasAlpha() :) Also I am not a fan of "hasAlpha()" since it is not clear if that mean alpha == 0 or alpha == 1 :) "alpha() == 255" is clearer, at least for me.
Andreas Kling
Comment 3 2011-05-25 11:22:33 PDT
Created attachment 94810 [details] Proposed patch v2
Andreas Kling
Comment 4 2011-05-25 11:24:22 PDT
Created attachment 94811 [details] Proposed patch v2
WebKit Review Bot
Comment 5 2011-05-25 22:47:25 PDT
Comment on attachment 94811 [details] Proposed patch v2 Attachment 94811 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/8739035 New failing tests: editing/style/inline-style-container.html
WebKit Review Bot
Comment 6 2011-05-25 22:47:30 PDT
Created attachment 94918 [details] Archive of layout-test-results from ec2-cr-linux-01 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-01 Port: Chromium Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Andreas Kling
Comment 7 2011-05-26 11:08:12 PDT
(In reply to comment #5) > (From update of attachment 94811 [details]) > Attachment 94811 [details] did not pass chromium-ews (chromium-xvfb): > Output: http://queues.webkit.org/results/8739035 > > New failing tests: > editing/style/inline-style-container.html Need a minor expectation tweak in editing/style/inline-style-container.html, will fix when landing if r+ed.
Alexis Menard (darktears)
Comment 8 2011-05-27 05:25:14 PDT
Comment on attachment 94811 [details] Proposed patch v2 LGTM modulo the breakage :D
Benjamin Poulain
Comment 9 2011-05-27 06:44:10 PDT
Comment on attachment 94811 [details] Proposed patch v2 String::format("%.5f", alpha() / 255.0f)); -> DecimalNumber(alpha() / 255.0) will create different values regarding float/double and the rounding of float/dtoa. But as far as I can see, that is for the better, so r+ :)
Andreas Kling
Comment 10 2011-05-27 08:10:58 PDT
Note You need to log in before you can comment on or make changes to this bug.