Re: [csswg-drafts] [css-pseudo] Spec clearly whether text inputs are supposed to support first-line / first-letter (#13926)

The CSS Working Group just discussed `[css-pseudo] Spec clearly whether text inputs are supposed to support first-line / first-letter`, and agreed to the following:

* `RESOLVED: ::first-line / ::first-letter don't apply to input / textarea for now, revisit once we have better-defined layout for them`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> emilio: Blink only supports :first-line somehow<br>
&lt;fantasai> emilio: It feels weird. I almost changed this in Gecko accidentally, while fixing support for field-sizing.<br>
&lt;fantasai> emilio: Spec is ambiguous, but I wouldn't expect it to dig into contents of a replaced element.<br>
&lt;lea> q?<br>
&lt;fantasai> emilio: So I think we should be explicit that they don't apply to replaced elements, same way as ::before/::after don't apply<br>
&lt;tantek> presumably our reasoning on this is specific to inputs rather than generalizing to say, any use of contenteditable?<br>
&lt;fantasai> astearns: I don't see a problem with ::first-letter, but ::first-line seems odd<br>
&lt;lea> q+<br>
&lt;fantasai> emilio: I would prefer not to support any of them. I'm half-sure it is accidental in Blink.<br>
&lt;astearns> ack lea<br>
&lt;PaulG> order matters, if you put scrollLeft first, it will scroll left but not up. So, I understand now.<br>
&lt;emilio> lea: from an author-facing perspective they expect it to work<br>
&lt;fantasai> lea: From author-facing, I think if they're using it they're expecting it to work<br>
&lt;emilio> ... not sure that's undesirable<br>
&lt;emilio> ... the argument they're replaced elements make sense<br>
&lt;emilio> ... I wish ::before / ::after would work<br>
&lt;emilio> ... if we could make it work that'd be the better outcome<br>
&lt;tantek> do those pseudos work on a contenteditable element?<br>
&lt;emilio> ... do we want to put theoretical purity<br>
&lt;emilio> ... I don't see a huge user need<br>
&lt;emilio> ... so if it complicates implementations I don't think it's worth it<br>
&lt;PaulG> q+<br>
&lt;emilio> ... no strong opinion either way<br>
&lt;PaulG> q-<br>
&lt;fantasai> emilio: They do work on contenteditable<br>
&lt;fantasai> emilio: Big issue is that the layout is not fun.<br>
&lt;lea> s/do we want to put theoretical purity/per the PoC, do we want to put theoretical purity above author needs?/<br>
&lt;dbaron> the proposal seems reasonable to me; I don't think ::first-letter and ::first-line make much sense in input and textarea<br>
&lt;fantasai> emilio: Even without auto appearance, the way these elements are laid out internally is not specced and does not match across implementations<br>
&lt;fantasai> emilio: Making them work reliably is sketchy<br>
&lt;fantasai> emilio: There are some extra elements, for example, in a password input. Is that part of the ::first-line or not?<br>
&lt;fantasai> emilio: I think the real issue is, same for ::before/::after, they shouldn't work because we don't have interoperable layout for these elements<br>
&lt;TabAtkins> +1 to emilio here<br>
&lt;fantasai> emilio: Need to define how it interacts with ::placeholder, etc. etc.<br>
&lt;fantasai> emilio: Internal contents of these elements are not defined per spec<br>
&lt;fantasai> +1 to emilio<br>
&lt;kbabbitt> +1 to emilio<br>
&lt;emilio> astearns: I think we should define these not to work for now given that<br>
&lt;schenney> I suspect the Chrome behavior is an accidental artifact of recent changes to the internal layout structure of text areas. If so definitely something not easy to spec. +1 to emilio.<br>
&lt;tantek> not apply for now is reasonable because we can expand it in the future with new information<br>
&lt;emilio> RESOLVED: ::first-line / ::first-letter don't apply to input / textarea for now, revisit once we have better-defined layout for them<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13926#issuecomment-4983249817 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 15 July 2026 17:01:44 UTC