User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050412 Firefox/1.0+ (PowerBook) Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050412 Firefox/1.0+ (PowerBook) When floating left a :first-letter (to produce a dropcap), Gecko ignores any declared line-height and inherits the line-height of the parent box. This prevent authors from positioning the first letter by reducing the line-box through the use of a small line-height. Wether the leni-height on the :first-letter is 0.7em or 1.5em, the line box remains the same. (both Opera 7.5+ and Safari 1.0+ correctly handlle this) Reproducible: Always Actual Results: Line-height declaration ignored. Expected Results: Respecting the line-height rule.
Created attachment 180557 [details] test case Test case showing the problem. 3 groups of paragraphs; each groups has a first-letter with different line-height.
While applying a workaround for this bug on a live site, I noticed that the presence of numerical entities in the text does affect the height of the line-box for the :first-letter. The line-height for the :first-letter is smaller for paragraphs of text that contain numerical entities. Without the entities, the line-height of the :first-letter is inherited from the parent block, and then computed based on the font-size of the :first-letter. With the numerical entities, the line-height of the :first-letter is actually the computed value of the line-height (in pixels) of the parent paragraph. However, when those entities are wrapped in an inline tag (span, strong, cite, ...), the :first-letter is not affected. Two live example http://emps.l-c-n.com/articles/84/ the first-letter jumps upwards http://emps.l-c-n.com/articles/83/ works correctly, the entities are wrapped in a cite. I'll attach a simplified test-case
Created attachment 180658 [details] test case for comment 2 illustrating the problems with numerical entities
This isn't really a floats bug... It's also not clear how setting line-height interacts with the weasel-language in the CSS spec about taking glyph outlines into account. Ian, how's this supposed to work (and where in the spec is that actually explained)?
The testcase renders all three cases the same for me. This should render however is most appropriate, typographically. The CSS spec explicitly doesn't define ::first-letter to the letter because we want UAs to be able to come up with better algorithms.
Ian, the question is what effect, if any, setting line-height should have on the first-letter.
Up to the UA. Specifically: # 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. ...so if we do shrink-wrapping of letters to get good drop/initial caps, then we can ignore line-height. If we don't do that, then instead we must treat line-height as described in the spec for ordinary spans and floats and so forth.
Ah, ok. We do exactly such shrink-wrapping.
(In reply to comment #7) From wich I understand that Gecko does not apply line-height to the :first-letter. Fair enough according to the specs, although different from what other UA's do (Opera, Safari). But there is still a problem with this. If you look at the second test case, where I inserted a numerical entity (’) in the text (in the first paragraph with a grey border). The linebox of the first letter is much smaller than when no num. entity is inserted, causing the first-letter to jump upwards. Or should I file a new bug, specifically for this ?
Possibly. I can't reproduce the behavior you're describing -- the three sets of tests in the second testcase look identical as far as first-letter positioning goes in a current Linux trunk build.
(In reply to comment #10) > Possibly. I can't reproduce the behavior you're describing -- the three sets of > tests in the second testcase look identical as far as first-letter positioning > goes in a current Linux trunk build. It turns out to be a Mac OS X only problem. While reviewing my test files, I noticed also that the OS X builds behave differently from the Win XP builds (tested: 20050517). I'll attach a screenshot in moment. Requesting to reopen this, but only for OS X builds.
Created attachment 183902 [details] testcase with and without num. entities One more testcase illustrating the problem(s). One character entity use: & #8217;. See the difference in the size of the first-letter line-box between the paragraphs without (red border) and with (grey border) num. entities.
Created attachment 183903 [details] screen shot of the third case On the left OS X 10.3.9, Firefox 20050517. On the right XP Firefox 20050517.
The shrinked line-box for first-letter doesn't happen when the num.entity is preceeded by a span (<span>, <strong>,<a>, ...) - third group of paragraphs in testcase 3. It doesn't happen with all numerical entity either. Using ' instead of ’, and the line-box of the first-letter doesn't shrink. Any entity above Qxx does show the problem. I've also tested inserting a couple of Japanese characters, this has the same effect as using anything from Qxx onwards.
If this is mac-only, I suggest filing a new clear bug on GFX:Mac with a pointer to these testcases...
(In reply to comment #15) > If this is mac-only, I suggest filing a new clear bug on GFX:Mac with a pointer > to these testcases... OK, I filed bug 294733
Given that: (a) Firefox was the only browser implementing this special behavior (b) css-inline is bringing better initial letter support the working group decided to remove the special case for doing floating ::first-letter better, so we should remove the corresponding code.
CSSWG resolution in http://lists.w3.org/Archives/Public/www-style/2014Sep/0384.html
This might be a dupe of bug 13610 or vice versa
Quote David's comment in bug 1233271 (see bug 1233271 comment 3) below, so people who track from other duplicated bugs could have a clear explanation. == http://www.w3.org/TR/CSS21/selector.html#first-letter says: 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. This has been what we do for a long time (I think since it was more strongly recommended by the spec). That said, given that no other implementation does, we should probably stop doing so. ==
dbaron, do you still think this is something we should fix, and if so, if it would be difficult to fix anytime soon? I wouldn't mind trying my hand at making a patch, if you could give me some pointers on what would need to be changed.
I think it's pretty easy to do; it requires removing special-case code. However, I'm inclined to think we should do it when or after we ship initial-letter support, not before.
Since late 2016 or early 2017 I’m seeing several news sites which use `line-height:.6` or similar for big first-letters (2-3 lines high). Apparently this design trend is back. In Firefox the letter appears lower than expected, sometimes overlapping the next line. Developers seem content with this working in Chrome and Safari and looking busted in Firefox. Some examples: - T in "This month", overlaps with other text: https://www.theverge.com/2017/7/29/16017286/formula-e-new-york-brooklyn-photos-pictures - I in "Is a $4 million", misaligned (too low) but not overlapping: https://theoutline.com/post/1953/how-a-vc-funded-company-is-undermining-the-open-source-community Counter-example: - Using a <span> element for compatibility with Fx: https://www.theguardian.com/world/2017/jul/30/palantir-peter-thiel-cia-data-crime-police Fixing this bug without depending on 1223880 (which is unassigned) might be a quick win.