[CSS21] floated :first-letter pseudo-element should act like normal inline (e.g., support line-height)

NEW
Unassigned

Status

()

Core
Layout: Floats
P5
normal
13 years ago
16 hours ago

People

(Reporter: philippe (part-time), Unassigned)

Tracking

(Depends on: 1 bug, {testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tlt-backlog [webcompat])

Attachments

(4 attachments)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
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.

Updated

13 years ago
Keywords: testcase
(Reporter)

Comment 2

13 years ago
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
(Reporter)

Comment 3

13 years ago
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)?
Component: Layout: Floats → Layout
QA Contact: layout.floats → layout
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
(Reporter)

Comment 9

12 years ago
(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.
(Reporter)

Comment 11

12 years ago
(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.

(Reporter)

Comment 12

12 years ago
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.
(Reporter)

Comment 13

12 years ago
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.
(Reporter)

Comment 14

12 years ago
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 &#39 instead of
&#8217, and the line-box of the first-letter doesn't shrink.  Any entity above
&#81xx does show the problem. I've also tested inserting a couple of Japanese
characters, this has the same effect as using anything from &#81xx onwards.
If this is mac-only, I suggest filing a new clear bug on GFX:Mac with a pointer
to these testcases...
(Reporter)

Comment 16

12 years ago
(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.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Duplicate of this bug: 366359
Duplicate of this bug: 803539
Status: REOPENED → NEW
Summary: [css] :first-letter pseudo-element, float and line-height → [CSS21] floated :first-letter pseudo-element should act like normal inline (e.g., support line-height)
Priority: -- → P3
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
Component: Layout → Layout: Floats
See Also: → bug 13610
Duplicate of this bug: 1233271
Duplicate of this bug: 1214552
Assignee: nobody → jeremychen
Assignee: jeremychen → nobody

Updated

11 months ago
Priority: P3 → P5
Whiteboard: tlt-backlog
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.
==
Duplicate of this bug: 1337456

Updated

3 months ago

Updated

3 months ago

Updated

3 months ago
Flags: webcompat?
Whiteboard: tlt-backlog → tlt-backlog [webcompat]

Comment 26

3 months ago
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.
Flags: needinfo?(dbaron)
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.
Flags: needinfo?(dbaron)
Depends on: 1223880
Flags: webcompat?

Comment 28

22 days ago
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.
Duplicate of this bug: 1392164
You need to log in before you can comment on or make changes to this bug.