Bug 56377

Summary: WebKit's behavior for text-align inherit differs from other browsers
Product: WebKit Reporter: Jeremy Moskovich <playmobil>
Component: CSSAssignee: 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 Flags
Testcase
none
work in progress; just need a test
none
fixes the bug
none
Updated per mitz & eseidel's comments eric: review+

Description Jeremy Moskovich 2011-03-15 08:32:52 PDT
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.
Comment 1 Jeremy Moskovich 2011-03-15 08:33:13 PDT
Created attachment 85809 [details]
Testcase
Comment 2 Jeremy Moskovich 2011-03-15 08:51:21 PDT
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.
Comment 3 Aharon (Vladimir) Lanin 2011-03-17 00:33:19 PDT
(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.
Comment 4 Ryosuke Niwa 2011-03-22 15:47:08 PDT
Created attachment 86529 [details]
work in progress; just need a test
Comment 5 Ryosuke Niwa 2011-03-27 13:04:23 PDT
Created attachment 87084 [details]
fixes the bug
Comment 6 WebKit Review Bot 2011-03-27 13:07:01 PDT
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 7 mitz 2011-03-27 13:24:51 PDT
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 8 Ryosuke Niwa 2011-03-27 13:29:28 PDT
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.
Comment 9 mitz 2011-03-27 13:44:44 PDT
(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.
Comment 10 Ryosuke Niwa 2011-03-27 13:54:46 PDT
(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.
Comment 11 Ryosuke Niwa 2011-03-28 04:47:09 PDT
Created attachment 87123 [details]
Updated per mitz & eseidel's comments
Comment 12 WebKit Review Bot 2011-03-28 04:50:57 PDT
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 13 Eric Seidel (no email) 2011-03-28 05:00:26 PDT
Comment on attachment 87123 [details]
Updated per mitz & eseidel's comments

Looks great!
Comment 14 Ryosuke Niwa 2011-03-28 05:05:12 PDT
Committed r82105: <http://trac.webkit.org/changeset/82105>
Comment 15 WebKit Review Bot 2011-03-28 06:07:10 PDT
http://trac.webkit.org/changeset/82105 might have broken Qt Linux Release