Open
Bug 1427241
Opened 7 years ago
Updated 8 months ago
line-height (CSS) is not applied on ::first-line pseudo element
Categories
(Core :: Layout: Block and Inline, defect, P3)
Tracking
()
NEW
People
(Reporter: escoffier.n+mozilla, Unassigned)
Details
Attachments
(1 file)
368 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36
Steps to reproduce:
(Can reproduce all the time)
- create an html element containing a text (that spreads on more than one line)
- apply a line-height (CSS) to this element - for instance line-height: 32px;
- apply a different line-height (CSS) to the first line using the pseudo element ::first-line (or :first-line) - for instance line-height: 12px;
Actual results:
Result: the line-height of the first line stays the same as the rest of the text. Any other style (color, background-color, font-weight ...) is effectively applied but not line-height.
Expected results:
The first line of the text should have a smaller line-height
It works fine in all the other browsers I could test (latest Chrome, latest Safari, latest Opera, IE 7 to 11, Edge).
I built an example https://codepen.io/OxyDesign/pen/8925363c55abdf8e288ec17d50817c95
To my understanding it should be applied as per:
- W3C: https://www.w3.org/TR/css3-selectors/#first-formatted-line
- MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/::first-line#Allowable_properties
Updated•7 years ago
|
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Text
Ever confirmed: true
Product: Firefox → Core
Comment 1•7 years ago
|
||
Either Layout: Block and Inlines or style system, I'm not sure...
Component: Layout: Text → Layout: Block and Inline
Comment 2•7 years ago
|
||
> Either Layout: Block and Inlines or style system, I'm not sure...
I don't think there's a bug here at all. We apply line-height to first-line just fine. Just change the "12px" to "120px" in the linked testcase from comment 0 to see that.
The spec at https://www.w3.org/TR/css3-selectors/#first-formatted-line clearly says that "The ::first-line pseudo-element is similar to an inline-level element, but with certain restrictions". You can't use line-height on an _inline-level_ element to reduce line spacing in a block to below the block's line-height, because the blocks line-height puts a corresponding strut on every line.
I filed https://bugs.webkit.org/show_bug.cgi?id=181209 and https://bugs.chromium.org/p/chromium/issues/detail?id=798257 on Safari and Chrome respectively about the not following the spec here. Edge's bug system won't let me file bugs, unfortunately....
Comment 3•7 years ago
|
||
Note that https://drafts.csswg.org/selectors-3/#first-line and https://drafts.csswg.org/css-pseudo-4/#first-line-styling have the same language about ::first-line acting like an inline, so it's not like this has changed since selectors3 went to REC in 2011.
Reporter | ||
Comment 4•7 years ago
|
||
On the W3c the fictional tag sequences always use <P> and <DIV> tags to wrap the first line. Even when breaking a <SPAN>.
So to me it seemed like it should behave like a block element rather than an inline one.
That's my interpretation but I might be wrong
Reporter | ||
Comment 5•7 years ago
|
||
For me, an inline element inside text in a block shouldn't be able to reduce the line-height (only increase it if needed) because obviously the text around it needs the line height set. But in the first line pseudo element case, as it will fill the full line no matter what, it feels like it should behave like a block element. If you reduce the font-size for instance, then it makes sense to be able to reduce the line height as well, and it will never impact another line as it's the full line and only this line. If that makes sense
Comment 6•7 years ago
|
||
(In reply to Nicolas Escoffier from comment #4)
> On the W3c the fictional tag sequences always use <P> and <DIV> tags to wrap
> the first line. Even when breaking a <SPAN>.
> So to me it seemed like it should behave like a block element rather than an
> inline one.
> That's my interpretation but I might be wrong
<P::first-line> in the spec means ::first-line pseudo-element from the P element, and likely <DIV::first-line>. It says nothing about what the pseudo-element itself should be like.
Comment 7•7 years ago
|
||
> So to me it seemed like it should behave like a block element rather than an inline one.
Well, the spec pretty explicitly says it behaves like an inline. If you think the spec should change, you should probably raise this with the CSS working group...
Note that it's not clear to me whether ::first-line behaves like a block in other ways in non-Firefox UAs or not. It would need to be very carefully checked for all the properties that apply to first-line and behave somewhat differently for blocks and inlines (text-decoration and background come to mind immediately, but there may be others). So just saying that the spec should change to having ::first-line be a block may still not end up with the spec and other implementations matching; needs checking.
Comment 8•7 years ago
|
||
If I understood correctly, block containers no longer impose a minimum height for their line boxes. What happens is that there is an anonymous root inline box that holds all of the inline-level contents of the block container, and this root inline box inherits the line-height from the block container.
The ambiguity is that the ::first-line behaves like an inline-level element, so it should be inside the root inline box. But the root inline box is an inline box, so its first line fragment should be inside ::first-line (and then inherit line-height from ::first-line instead of the block container).
See https://github.com/w3c/csswg-drafts/issues/1384
Comment 9•7 years ago
|
||
> block containers no longer impose a minimum height for their line boxes
As of when? https://drafts.csswg.org/css-inline-3/#line-height clearly says "The CSS2 specification should be used as the guideline for implementation." And all the links to line-height in css-inline-3 go to https://drafts.csswg.org/css2/visudet.html#propdef-line-height
In any case, if the working group totally redefines how inline layout works, and actually creates tests to test its new spec, then we can obviously align with that new spec....
Flags: needinfo?(dbaron)
Comment 10•7 years ago
|
||
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #9)
> As of when?
I don't know when, but this is what I understood from what dbaron said in https://github.com/w3c/csswg-drafts/issues/1551
But maybe I misunderstood what he meant, he didn't confirm...
Comment 11•7 years ago
|
||
Right, hence the needinfo for dbaron.
What I was saying in https://github.com/w3c/csswg-drafts/issues/1551 was that when we introduced the "strut" concept to CSS 2.1, it was done because it was seen as a smaller change than introducing the "root inline box" concept, even though I believe the root inline box concept is a clearer explanation for the same things (minimum line-height established by blocks, and how that relates to other inlines in terms of vertical alignment). I still think it would be better for the relevant level 3 spec to use the "root inline box" concept instead and get rid of the "strut" defined in https://www.w3.org/TR/CSS21/visudet.html#line-height .
I don't see how that debate is particularly related to this issue. Either way, applying 'line-height' to ::first-line would require an exception from that rule.
Flags: needinfo?(dbaron)
Comment 13•7 years ago
|
||
(In reply to David Baron :dbaron: ⌚️UTC-8 from comment #12)
> I don't see how that debate is particularly related to this issue.
If a block container does not directly impose a minimum line height and the fragment in the first line of the root inline box inherits from ::first-line, then the behavior of other browsers seems expected.
Reporter | ||
Comment 14•7 years ago
|
||
Boris, as suggested I raised it with the w3c https://github.com/w3c/csswg-drafts/issues/2282
Thanks
Comment 16•3 years ago
|
||
This is a duplicate of issue #1686513.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•