Bug 56377 – WebKit's behavior for text-align inherit differs from other browsers

• Component: CSS
• Status: RESOLVED FIXED

[Jeremy Moskovich]

From my reading of the CSS3 spec, it seems to say that start and end are considered as computed values, this is relevant in the context of text-align: inherit.

[Jeremy Moskovich]

Created attachment 85809 [details]
Testcase

[Jeremy Moskovich]

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.

[Aharon (Vladimir) Lanin]

(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.

[Ryosuke Niwa]

Created attachment 86529 [details]
work in progress; just need a test

[Ryosuke Niwa]

Created attachment 87084 [details]
fixes the bug

[WebKit Review Bot]

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.

[Ryosuke Niwa]

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.

[Ryosuke Niwa]

(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.

[Ryosuke Niwa]

Created attachment 87123 [details]
Updated per mitz & eseidel's comments

[WebKit Review Bot]

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.

[Eric Seidel (no email)]

Comment on attachment 87123 [details]
Updated per mitz & eseidel's comments

Looks great!

[Ryosuke Niwa]

Committed r82105: <http://trac.webkit.org/changeset/82105>

[WebKit Review Bot]

http://trac.webkit.org/changeset/82105 might have broken Qt Linux Release