[csswg-drafts] block-overflow, ::first-line, and ::first letter

frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== block-overflow, ::first-line, and ::first letter ==
@MatsPalmgren said in https://github.com/w3c/csswg-drafts/issues/390#issuecomment-372143424:
> Does the inserted text affect ::first-letter/::first-line in any way? (even if it doesn't, it'd be good to spell that out explicitly for clarity)

I said in https://github.com/w3c/csswg-drafts/issues/390#issuecomment-372160977:
>If it is in the first lines (e.g. max-lines:1), then it should take the styles that affect the first line. Otherwise, we'll get weird and inconsistent typography in the first line. I believe that is already a consequence of "placed [...] as a direct child of the block container’s root inline box", but it doesn't hurt to say so if we agree (or to argue it out and then spec it if we don't).
>
>For ::first-letter, I am less sure. I'm not what sure what the use case would be, and neither of what the implementation complexity would be. Any suggestion?

In https://github.com/w3c/csswg-drafts/issues/390#issuecomment-372302097, @MatsPalmgren responded:

> OK, but I disagree that that follows from "placed [...] as a direct child of the block container’s root inline box". It really is necessary to point that out explicitly if that's the behavior you intended.
> Please note that `list-style-position:inside` `::marker` boxes does **not** affect `::first-letter/line` in current implementations, fwiw.
> 
> Anyway, the problem with the `::first-*` pseudos is that some UAs construct boxes for them in the box construction phase, which happens before the layout phase, so if the inserted ellipsis should be affected by these styles then it might affect boxes that were already constructed.  For example, if the ellipses is so wide that it requires the entire length of the line then any existing `::first-letter/line` boxes needs to be undone somehow.  For `::first-letter` there's also the case where leading punctuation on the line should be included together with the first character of the ellipsis.  The implementation of these pseudos is already quite messy (and buggy) in Gecko and I suspect that might be the case for other UAs too. This is why I'm asking for a detailed spec about how the interaction (or not) between these boxes should work, because otherwise we'll almost certainly end up with incompatible implementations.
> 
> I would strongly prefer to keep the `block-overflow` property simple though, i.e. not interacting with boxes other than shortening the last line.  We can introduce a more general "`::fragment-before/::fragment-after`"  in the future, that would magically appear at fragmentation boundaries (possibly with additional conditions that an author can control).  For example, it's quite common in printed newspapers to insert a "continued from page N" at the _start_ of a fragment when it continues from an earlier page.

In https://github.com/w3c/csswg-drafts/issues/390#issuecomment-374749084, @fantasai said:

> Wrt `::first-line` and `::first-letter`, I think the ellipsis should be considered part of the first line, but not the first letter pseudo. The `::first-letter` pseudo behaves much more like an inline element, and the ellipsis is placed outside of any elements. Meanwhile `::first-line` encompasses the entire line, it would be weird if something on it were somehow exempted.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2906 using your GitHub account

Received on Wednesday, 11 July 2018 09:34:27 UTC