Summary: | WebKit's behavior for text-align inherit differs from other browsers | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Jeremy Moskovich <playmobil> | ||||||||||
Component: | CSS | Assignee: | Ryosuke Niwa <rniwa> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Minor | CC: | abarth, aharon, ap, eric, hyatt, mitz, rniwa, simon.fraser, webkit.review.bot, xji | ||||||||||
Priority: | P3 | Keywords: | HasReduction | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | All | ||||||||||||
OS: | All | ||||||||||||
URL: | http://dev.w3.org/csswg/css3-text/#text-align | ||||||||||||
Bug Depends on: | 57213 | ||||||||||||
Bug Blocks: | |||||||||||||
Attachments: |
|
Description
Jeremy Moskovich
2011-03-15 08:32:52 PDT
Created attachment 85809 [details]
Testcase
WebKit resolves text-align:start/end to left/right in CSSStyleSelector::applyProperty and then discards the original values. Then when a child element comes along with text-align:inherit left/right is inherited from the parent rather than start/end. According to my reading of the spec, WebKit's current behavior is actually what's expected of text-align:match-parent and is wrong for inherit. """ match-parent This value behaves the same as ‘inherit’ except that an inherited ‘start’ or ‘end’ keyword is calculated against its parent's ‘direction’ value and results in a computed value of either ‘left’ or ‘right’. """ The attached test case renders differently in WebKit than FF which itself differs from IE8/Opera. (In reply to comment #2) > WebKit resolves text-align:start/end to left/right in CSSStyleSelector::applyProperty and then discards the original values. Then when a child element comes along with text-align:inherit left/right is inherited from the parent rather than start/end. > > According to my reading of the spec, WebKit's current behavior is actually what's expected of text-align:match-parent and is wrong for inherit. > > """ > match-parent > This value behaves the same as ‘inherit’ except that an inherited ‘start’ or ‘end’ keyword is calculated against its parent's ‘direction’ value and results in a computed value of either ‘left’ or ‘right’. > """ > > The attached test case renders differently in WebKit than FF which itself differs from IE8/Opera. I concur. FF has the correct behavior for text-align:start and end. Created attachment 86529 [details]
work in progress; just need a test
Created attachment 87084 [details]
fixes the bug
Attachment 87084 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/fast..." exit_code: 1
Source/WebCore/rendering/style/RenderStyle.h:190: _text_align is incorrectly named. Don't use underscores in your identifier names. [readability/naming] [4]
Total errors found: 1 in 12 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 87084 [details] fixes the bug View in context: https://bugs.webkit.org/attachment.cgi?id=87084&action=review > Source/WebCore/rendering/RenderBlockLineLayout.cpp:500 > + case TASTART: It may be simpler to resolve to start and end to left or right in RenderBlock::textAlignmentForLine() rather than make this larger change to this file. Comment on attachment 87084 [details] fixes the bug View in context: https://bugs.webkit.org/attachment.cgi?id=87084&action=review >> Source/WebCore/rendering/RenderBlockLineLayout.cpp:500 >> + case TASTART: > > It may be simpler to resolve to start and end to left or right in RenderBlock::textAlignmentForLine() rather than make this larger change to this file. Yeah, I considered that as well but then I have to add default & assert_not_reached at the end. Do you think that's cleaner? I can isolate the refactoring part of the patch if you'd like. (In reply to comment #8) > (From update of attachment 87084 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=87084&action=review > > >> Source/WebCore/rendering/RenderBlockLineLayout.cpp:500 > >> + case TASTART: > > > > It may be simpler to resolve to start and end to left or right in RenderBlock::textAlignmentForLine() rather than make this larger change to this file. > > Yeah, I considered that as well but then I have to add default & assert_not_reached at the end. Rather than adding a default case, I would add the two unexpected values explicitly, and assert that they should not occur. (In reply to comment #9) > Rather than adding a default case, I would add the two unexpected values explicitly, and assert that they should not occur. Mn... it seems like RenderRubyBase and RenderRubyText override textAlignmentForLine so I'm not sure if modiying all 3 functions will be as clean. Given that I like my approach better since computeInlineDirectionPositionsForLine is already a long function that can be refactored into smaller pieces although having two mutable reference arguments isn't that pretty. Created attachment 87123 [details]
Updated per mitz & eseidel's comments
Attachment 87123 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/fast..." exit_code: 1
Source/WebCore/rendering/style/RenderStyle.h:190: _text_align is incorrectly named. Don't use underscores in your identifier names. [readability/naming] [4]
Total errors found: 1 in 12 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 87123 [details]
Updated per mitz & eseidel's comments
Looks great!
Committed r82105: <http://trac.webkit.org/changeset/82105> http://trac.webkit.org/changeset/82105 might have broken Qt Linux Release |