1376061 - Space around floated first-letter differs from that in Chrome and IE11 (in "drop caps" effect)

Status: RESOLVED DUPLICATE of bug 290125

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Frank]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170608105825

Steps to reproduce:

<!DOCTYPE html>
<html>
<head>
<style>
    body {
        font: normal 13px/1 Arial;
    }
    p {
        width: 400px;
    }
    p::first-letter {
        float: left;
        font-size: 4em;
    }
</style>
</head>
<body>
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed condimentum venenatis egestas. Pellentesque lectus enim, pretium quis condimentum sit amet, dapibus quis erat. Proin a varius neque. Aenean erat diam, scelerisque vitae vehicula et, malesuada sit amet arcu. Fusce ut sapien congue odio commodo vulputate et sed nibh. Etiam elementum ligula porttitor mauris sodales aliquet. Sed fermentum magna quis tellus consequat et rhoncus nisl fringilla. Praesent eu neque ac dui faucibus molestie. Maecenas neque risus, sollicitudin quis gravida quis, sagittis nec lectus. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam dictum lacinia erat, vel tempus sem tempus ut. Morbi lacus est, condimentum id vehicula a, volutpat non mi.</p>
</body>
</html>


Actual results:

Space around first-letter is different from that in Chrome59 and IE11. 


Expected results:

Should be the same.

Comment 1

[Jonathan Kew [:jfkthame]]

This is longstanding Gecko behavior for a ::first-letter with the float property: it adjusts the size of the floated box to suit the ascent/descent of the letter, rather than using a fixed-height box that may include lots of blank space above or below the glyph (depending on its shape).

This behavior is explicitly allowed[1] by the CSS specs:

# To allow UAs to render a typographically correct drop cap or initial cap,
# the UA may choose a line-height, width and height based on the shape of the letter,
# unlike for normal elements.

However (as illustrated here) it is not interoperable among browsers.

Maybe we should consider changing this (it's come up before in other bugs, though I don't have references handy), but note that doing so would break current content that is designed to work well with the existing behavior.

The new initial-letter property[2,3] should provide a more robust solution, though I'm not sure of the current state of support across various UAs.

[1] https://www.w3.org/TR/css3-selectors/
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/initial-letter
[3] https://drafts.csswg.org/css-inline/#sizing-drop-initials

Comment 6

[tomhodgins]

Still seeing this issue today in Firefox 70.0b13, here's a link to a demo a web developer put together that demonstrates the issue when loaded in Firefox and other browsers: https://jsfiddle.net/J7Luke/e1jax0r5/2

While Firefox's behaviour might not be forbidden according to the spec, it's certainly breaking cross-browser styling and causing headaches for developers as it behaves differently in Firefox than how all other browsers appear to handle this.

It would be a big win for all developers if Firefox could align its behaviour with other browsers!

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: screenshot of bug on New York Times article

This affects a recent prominent New York Times article as well:
https://www.nytimes.com/interactive/2020/01/19/opinion/amy-klobuchar-elizabeth-warren-nytimes-endorsement.html

Comment 10

[Karl Dubost💡 :karlcow]

/* styles.min.0d2442960be8d84a4b9e60e5be29aa41790f9542.css | https://www.newyorker.com/verso/static/the-new-yorker/styles.min.0d2442960be8d84a4b9e60e5be29aa41790f9542.css */

.grid .body__container > p.has-dropcap.has-dropcap__lead-standard-heading::first-letter {
		/* padding: .1em .05em 0 0; */
		padding: .1em .05em 0.599px 0;
}

and just for the fun, a very simple 0.6px is enough to change dramatically the layout in this case.

Comment 11

[Sean Voisen (:svoisen)]

Adding to backlog as something to revisit.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: screenshot on inputmag.com article (Firefox left, Chrome right)

I ran into this issue (I think) with an article on another not-yet-mentioned-here website (with an article that was featured in my weekly Pocket Hits email):
https://www.inputmag.com/features/rise-and-ruin-of-couchsurfing

Comment 14

[Thomas Wisniewski [:twisniewski]]

This is also likely affecting The Verge's dropcaps right now, which are actually SVG background images that appear "cut off" (almost like a glyph with an incorrect baseline), because the dimensions of the box differ from Chrome (especially counting the precise negative margins they're giving them to look correct on WebKit/Blink).

Comment 15

[BugBot [:suhaib / :marco]]

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates and 5 See Also bugs.
:jfkthame, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 16

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 17

[Šime Vidas]

This bug could be marked as a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=415506

Comment 18

[Daniel Holbert [:dholbert]]

Yeah -- clicking through into a "see-also" bug over there, bug 1552731 seems quite similar, and it itself is a dupe of older bug 290125.

(And bug 290125 has some references to sites like The Verge having this sort of issue, e.g. https://github.com/webcompat/web-bugs/issues/7160 )

--> Duping to bug 290125.