Bug 201296 – getComputedStyle for line-height: normal should return the keyword instead of a length

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Simon Pieters (:zcorpan)]

From https://github.com/w3c/csswg-drafts/issues/3749#issuecomment-477241555 

> The CSS Working Group just discussed A question for the procedure to compute the resolved value of "line-height", and agreed to the following:
>
> RESOLVED: return 'normal' for line-height

This change was implemented in Gecko in https://bugzilla.mozilla.org/show_bug.cgi?id=1536871

Blink already does this.

(The CSSOM spec hasn't yet been edited to reflect this change.)

Tests: http://web-platform-tests.live/html/rendering/non-replaced-elements/form-controls/resets.html (these were intended to test something else, but fail in WebKit due to this bug.)

Current test results https://wpt.fyi/results/html/rendering/non-replaced-elements/form-controls/resets.html?sha=3ac7cc537e

[Joonghun Park]

The issue https://github.com/w3c/csswg-drafts/issues/3749
had reached its conclusion as Simon commented.

> RESOLVED: return 'normal' for line-height

Per https://github.com/w3c/csswg-drafts/issues/4249 Emillio's comment,
"Firefox has this behavior behind a pref on Nightly / Beta only. I plan to turn it on-by-default on the next release cycle if no regressions are found. This was done in https://bugzilla.mozilla.org/show_bug.cgi?id=1536871 as a result of the discussion in #3749",

I think we can proceed with this issue to make WebKit to return "normal" in gCS for line-height.

[Eric Willigers]

WPT: https://wpt.fyi/results/css/css-inline/parsing/line-height-computed.html

[Joonghun Park]

(In reply to Eric Willigers from comment #2)
> WPT: https://wpt.fyi/results/css/css-inline/parsing/line-height-computed.html

Thank you for the reference, Eric:)

More related wpt:
css/cssom/getComputedStyle-line-height.html
html/rendering/replaced-elements/the-select-element/select-1-line-height.html

[Joonghun Park]

Created attachment 378203 [details]
Patch

[Joonghun Park]

Created attachment 378206 [details]
Update commit message

[EWS Watchlist]

Comment on attachment 378206 [details]
Update commit message

Attachment 378206 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/13006498

New failing tests:
fast/css/font-shorthand-from-longhands.html
fast/css/getComputedStyle/computed-style-font.html
fast/ruby/ruby-line-height.html
css3/calc/line-height.html
fast/css/font-calculated-value.html

[EWS Watchlist]

Created attachment 378215 [details]
Archive of layout-test-results from ews212 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews212  Port: win-future  Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit

[Joonghun Park]

Created attachment 378321 [details]
Update Layout Test Results

[Joonghun Park]

Created attachment 378322 [details]
Update ios Layout test result of line-height-boosting.html

[Joonghun Park]

Could you please review this patch? I think mac-debug-wk1's webgl/1.0.2/conformance/context/context-release-upon-reload.html failure is not related with this patch.

[Joonghun Park]

Thank you for your review, rniwa:)

[WebKit Commit Bot]

Comment on attachment 378322 [details]
Update ios Layout test result of line-height-boosting.html

Clearing flags on attachment: 378322

Committed r249686: <https://trac.webkit.org/changeset/249686>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/55207849>

[Radar WebKit Bug Importer]

<rdar://problem/55207850>