[css-overflow-4] max-lines and independent formatting contexts

[fantasai]

While trying to work through how to implement the size attribute on <select>, we were wondering if max-lines could, instead of ignoring independent formatting contexts in the count, count each one as the equivalent of one line.

This would solve the problem for <select> and also be more generally useful, if we can make it work. The main question is Web-compat, or if we can work around the Web-compat issue.

[astearns]

@frivoal @andreubotella

[andreubotella]

For -webkit-line-clamp, both Chromium and Firefox treat independent formatting contexts as not increasing the number of line. Webkit counts lines inside independent formatting contexts, including clamping inside tables[^1]. Given this, neither of these options are probably set in stone.

[^1]: While looking at this, I found a number of cases where Webkit has related bugs, including one where it elipsizes inside of the table, but the clamp happens outside ignoring the number of lines inside the table?

[bfgeek]

This would solve the problem for <select> and also be more generally useful, if we can make it work. The main question is Web-compat, or if we can work around the Web-compat issue.

Can you provide an example of why this is desirable? Crossing IFCs with line-counting brings up a whole class of issues that I'd rather avoid.

[emilio]

+1 to what @bfgeek said.

The use case would be a listbox select, this comes up from https://github.com/w3c/csswg-drafts/issues/12510.

Consider:

<select-like-thing>
  <complex-option>....</complex-option>
  <complex-option>....</complex-option>
  <complex-option>....</complex-option>
  ...

You want to clamp at 2 items, but you don't want to recurse into the options, nor skip counting the options. So if options are their own BFC (display: flow-root or so) it allows to achieve the use case trivially (select-like-thing { max-lines: 2 }).

[frivoal]

Crossing IFCs with line-counting brings up a whole class of issues that I'd rather avoid.

Counting the number of lines in IFCs would be way more complicated indeed (especially if we don't limit ourselfs to independent BFCs, but all sorts of formatting contexts), but if I understand correctly, the request here is not to count the lines inside the IFC, just to could a IFC as a single line, regardless of its content, which doesn't seem nearly as complex. Or is that hard too?

If we were to go this way, I presume this would be limited to block-level IFCs, and not count inline-blocks (or inline grids, or what not) as 1 line.

It would also open the question of what we should do about block-level replaced elements, such as blockified images. If we were to adopt the change proposed, I suppose it would make sense if they counted as 1 too.

[bfgeek]

(in case it wasn't clear initially IFC == "independent formatting context" from comment above).

So today everyone has compat on not treating block-level IFCs as lines, e.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=14276 https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=14277

So we are compat constrained here.

[frivoal]

Due to the compat constrain mentioned by @bfgeek, we're going to need to keep the default behavior, at least when using -webkit-legacy, working as it currently does, without counting IFCs as 1 line.

If we think counting IFCs as 1 line is desirable behavior, we could have it in a different mode. Maybe that would be keyed on -webkit-legacy vs not. Maybe it could be opt-in (on the max-lines property?)

My sense is that (a) the fewer differences we have between -webkit-legacy vs "normal", the better, and (b) this is a twist on max-line, not on continue, so my inclination if we want to have this behavior would be to have it as an opt-in keyword in max-lines.

Then again we could do both: have it as an opt-in keyword in max-lines and set that keyword when the shorthand is used, except when it includes -webkit-legacy.

[Loirooriol]

Skipping IFCs entirely seems reasonable to me. Randomly guessing that they have 1 line seems weirder.

Is this 1 just trying to cover the select usecase?

[fantasai]

Crossing IFCs with line-counting brings up a whole class of issues that I'd rather avoid.

I didn't say anything about crossing IFCs. I agree that would be annoying. I just said you count them (as 1, rather than 0).

Is this 1 just trying to cover the select usecase?

I think authors would find it more generally useful, actually, as well as working for the select use case.

[fantasai]

So today everyone has compat on not treating block-level IFCs as lines, e.g.

We have interop on not treating IFCs as lines, but do we have compat?

Related question would be making this work on non block-containers, so, counting the number of flex lines or flex items in a flex container, counting the number of tracks in a grid, etc.