Revert of Empty inline elements always get a line box. (https://codereview.chromium.org/300853007/)
Reason for revert: This changed the subpixel positioning of glyphs on lines with first-letter renderers on Mac builds. See https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Mac10_6/28423/layout-test-results/results.html as an example. I think the new results are benign - but would like to confirm with leviw and reland as NeedsRebaseline if we're both happy with them. Original issue's description: > Empty inline elements always get a line box. > > CSS 2.1 (http://www.w3.org/TR/CSS2/visudet.html#leading) says: "Empty inline > elements generate empty inline boxes, but these boxes still have margins, padding, > borders and a line height, and thus influence [line-height calculation] just > like elements with content." > > We weren't creating lineboxes for empty inline elements when they occurred > between a single trailing space and a single leading space - this is because > our linebox creation was based on the too-narrow premise that we were already > ignoring spaces. However, if an empty inline element comes after a trailing > space but before one or more leading spaces then it will be ignored as part > of the collapsed space between the trailing space and the next non-collapsible > space - so we should force the creation of a linebox in such cases. > > This allows us to pass Hixie's empty inline test: > http://www.hixie.ch/tests/evil/mixed/emptyinline.html > > BUG=328939 > > Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=175205 TBR=leviw@chromium.org NOTREECHECKS=true NOTRY=true BUG=328939 Review URL: https://codereview.chromium.org/302233002 git-svn-id: svn://svn.chromium.org/blink/trunk@175207 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Showing
Please register or sign in to comment