[css-multicol] Clipping of content that overflows a column

[cvrebert]

• https://www.w3.org/TR/css3-multicol/#overflow-inside-multicol-elements

Content in the normal flow that extends into column gaps (e.g., long words or images) is clipped in the middle of the column gap.

• https://drafts.csswg.org/css-multicol/#overflow-inside-multicol-elements

Floated or in-flow content that extends into column gaps or neighboring columns — e.g., long words or images — is not clipped and may therefore cause overflow.

The ED change occurred in aa41389.
The email announcing the draft change cites the TR as the reasoning for the change...😕

---

A. Some testing suggests that only Firefox implements the ED's "don't clip" behavior. Does the group think that the other browsers are actually going to change their behavior here? It's been 3 years.
B. The ED's text addresses floated and in-flow content. What about non-float out-of-flow content, such as position:absolute? Or in the case of the CR's text, what about out-of-flow content? I ask because of https://bugzilla.mozilla.org/show_bug.cgi?id=1282363

[bradkemper]

Personally, I'd like absolutely positioned content to get a waiver on being clipped or chopped up between columns. When I have absolutely positioned content inside columns, it is usually for help tip type things (positioned relative to a small span or hyperlink), which would work best if they could remain in one piece when overflowing in the block direction, and not be clipped, not affect the height of of the multicol box, and have a z-index and stacking context relative to the whole multicol box (not just the current column) so that subsequent columns don't cover it. There is no way to do that currently, and different browsers do different things (which sometimes depends on whether the item is near the top or bottom of the column).

[cvrebert]

The user in twbs/bootstrap#20161 likewise wishes there wasn't clipping in this case.

[cvrebert]

@frivoal Any thoughts here (since you edit css-multicol-2)?

[frivoal]

Not clipping in these cases makes sense to me as well.

Both the TR wording and the ED wording are problematic though, as neither of them defines the behavior for all cases. So, what are we after?
1 - in flow
2 - floated
3 - abspos / fixpos
4 - relpos / transforms
5 - ... someting else?

As discussed above, I seems that we have a reasonably good justification for 3 to not be clipped, as there are valid use cases that depend on that. For the rest, I am less sure about use cases, as overflow seems more of an error case to me. In that case, clipping will lead to unreadable content, while overflow may do so, if the overflowing content overlaps with something. Neither seem great, but the later seem better.

On top of that, maybe one day we'll have a pseudo element selector for the column box, and authors will be able to change the value of the overflow property on it. With that in mind, it would be preferable that the behavior we pick today can be explained in terms of values of that property. “Always clip” can, and so does always “overflow”, but having a few things clip while others do not sound harder to retrofit.

=> I think we should let things overflow without clipping in all cases.

(Note: all that is independent of things that overflow in the block direction in a way that triggers fragmentation, as discussed in the next section of the spec. That's fully governed by css-break. We're only discussing the things that overflow without causing fragmentation)

[frivoal]

One more reason to avoid clipping by default is discussed in http://www.w3.org/mid/44710381-60EF-4F3D-8695-2631F9A6887E@rivoal.net :

The default styling for lists (ols and uls) puts padding on the list itself, rather than on the list items. If you make the list into a multicol, that means there's no space for the list markers in columns after the first one. This is annoying enough (but likely unfixable as it's been that way forever), but if we clip in the middle of the column gaps, the markers not only overflow, but also become invisible. So no clipping is better.

[frivoal]

Agenda+ to bring this to more people's attention, and see if we can resolve on not clipping anything that overflows columns.

[css-meeting-bot]

The CSS Working Group just discussed Clipping of content that overflows a column, and agreed to the following resolutions:

• RESOLVED: Columns do not clip by default

The full IRC log of that discussion

<dael> Topic: Clipping of content that overflows a column
<dael> Github: https://github.com//issues/314
<dael> Florian: The TR version of multicol and the ED are contridicting
<dael> Florian: Browsers aren't interop.
<dael> Florian: If something overflows from a col should it be visably overflowing or clipped when the line is in the middle of the two columns.
<dael> Rossen_: Do you mean overflow in the inline direction in a column, block, both?
<dael> Florian: That's the other part. Specs are vague and they dont' define all cases. The case I'm interested in is not the kind that triggers fragmentation. I'm interested in any other kind of overflow
<dael> Florian: Both versions contradict. TR says clip, ED says overflow. Both use wording that means you do that in some cases, but don't say what to do in other cases.
<dael> Florian: I think we should not clip and overflow for everything for 3 reasons. First, there are use cases for positioned content to overflow. 2 is that lists, numbered or bullet, because the default HTML styling have the bullets overflow by default because it's padding on the ul in the stylesheet. That means bullet stick out and that's bad.
<dael> Florian: If we're doing it for this we should be consistant and not invent a new behavior to let some things overflow and some clip.
<dael> Florian: That's bad, especially if one day we have a selector to selecto column boxes.
<bradk> +1 on those examples
<rachelandrew> I think currently firefox overflows, Chrome clips
<dael> Rossen_: Seaking of our impl, the columns themselves do not clip and the multicol box wrapping around all the columns may or may not clicp depending on the overlfow prop. You're not clip in either horz or vertical. I don't have bugs suggesting we change this. So I would be in support of your proposal.
<rachelandrew> https://codepen.io/rachelandrew/pen/YpXqNY?editors=110
<dael> Florian: Current spec says no to clip in some cases, but doesn't define other cases. THe behavior you desc agrees with FF, but not Chrome. I think Safari is with Chrome
<dael> gregwhitworth: Is there a test case? I'm looking at bugzill and all browsers have overflow.
<dael> Florian: 5 minutes ago I made a test case and i lost it, but with a float with a margin that makes it stick out and Chrome clips that.
<dael> Rossen_: That's why I was asking about inline or block. Block direction has very specific rules in fragmentation and when we have monolythic boxes that don't fragment multicol lets you create net column. If your column count is fixed you may overflow in the box direction eventually and that should be controled by overflow property
<dael> fantasai: Even if you have fix column count you can overflow by creating more columns
<dael> Rossen_: YOu're correct.
<dael> Rossen_: You can always have an item that overflow the height
<dael> fantasai: We're talking about an item that overflows the column box itself. Overflow in block we're clear it's visible. Overflow in the inline you have a box in the first column and it'll overflow, will it overlap content in the second column?
<dael> Florian: That's the core. Slightly broader do we want to distinguish between types of content that might overflow or do we want one answer for all the things?
<dael> fantasai: I'm guessing one answer is easier to impl.
<dael> Florian: Yes, and that's not what the spec says
<dael> fantasai: Also, abspos elements is a different question as it's not in the column
<dael> Florian: It depends on the containing block.
<dael> fantasai: Right, they would be cliped by containing block, not the column necessarily. So the abspos cae splits into two sub-cases.
<dael> Florian: I think I would like nothing gets clipped and if people come up with use cases to clip we'll add a selector for column boxes and they can use overflow on that.
<Rossen_> https://codepen.io/rachelandrew/pen/YpXqNY?editors=110
<dael> Rossen_: To be on the same page, rachelandrew pased a codepen^
<dael> Rossen_: I want to make sure this is the test case we're talking about. THere's an image in the middle which is too wide. Question is does it clip
<dael> Florian: THat's one of the cases
<dael> Rossen_: What is see is that all brwsers but FF clip.
<dael> Rossen_: This is most likely a change in our behavior that was made for interop purposes.
<bradk> I think the last time I tried to do a positioned tooltip in multicol, it wrapped to second column in some browser (horrible)
<fantasai> Rossen, the original spec called for clipping iirc, that's why multiple browsers clip
<dael> Rossen_: If we agree to not clip it means we'll have to change all but one impl. We have to be mindful of the effect of the overall web compat.
<dael> Florian: I thought you said edge doesn't clip
<dael> Rossen_: WE didn't used to. At some point we must have changed for interop
<dael> fantasai: Or it could have been for spec. It did say to clip.
<fantasai> s/spec/spec compliance/
<dael> Rossen_: What I wanted to point out is if we change the spec it means changes to webkit, blink, and edge. I'm not sure what that would mean for web compat
<dael> Florian: Another arguement for that is multicol has been more sucessful in printed media and prince does overflow.
<dael> Rossen_: That could be, though I've seen epub readers use multicol for pagination. Those might suffer.
<dael> Florian: Then again, these do not want to have the selective clipping and overflow, they likely want always clipping which is not what we have today
<dael> Rossen_: It might suggest this is either an optional value to multicol where you can say clip or not and then put the behavior in the author hands and then we decide what the default is.
<dael> Florian: If we want to put it in author hands...
<dael> dbaron: It seems like the overflow is the easy way to make it author controlled.
<dael> Rossen_: dbaron did you mean overflow of multicol or have it apply to a selector
<dael> dbaron: Prob some sort of pseudo element. Problem is overflow defaults to visable and it's weird to have one thing default to clipping
<dael> Florian: I think visible is a good default. For regular multicol there's no clear reason why clipping would be a good default and turning list into multicol isn't crazy
<dael> Rossen_: If you put together market share I'd saya majority of content does clipping
<dael> Florian: You can cope with it, doesn't make it good.
<dael> Rossen_: It's what's expected on the web
<dael> Florian: Except for people in print and people using FF
<dael> dbaron: I also haven't seen this as a compat issue for us.
<dael> gregwhitworth: [missed]
<dael> dbaron: I don't remember seeing it
<dael> Florian: I don't think it would be mobile browsers, I think it would be apps that use browser as the run time.
<fantasai> Those would be easier to handle, since when they pull a new copy of the engine they can make the adjustment via ::column { overflow: hidden; }
<dael> Rossen_: That's what I was referring to. I've seen multiple touch webapps that do provide epub experience based on multicol
<dael> Florian: I think that's how ibook works
<dael> Florian: I'd like to go visible by default and hav e a column selector that could take overflow
<dael> Florian: Current behavior isn't clip by default. It's clip by default except something and that's nto great.
<dbaron> do Chromium, WebKit, and Edge all clip columns in both dimensions?
<dael> Rossen_: What is not clipped? I couldn't find anything.
<dael> Florian: abspos and the like?
<dael> Rossen_: You cannot make a column be a containing block
<dael> fantasai: You can make an element in the column
<dael> Rossen_: In which case the lement itself is clipped.
<dael> fantasai: Box can overflow the lement
<dael> Rossen_: If you have a no-breaking word tha expands past the column it's clipped anywhere except FF
<Rossen_> https://bug1282363.bmoattachments.org/attachment.cgi?id=8765359
<dael> Florian: And floats with negative are clipped. I haven't tested transformed content. Maybe everything is clipped, I haven't tested all variants.
<dael> Rossen_: Going through the test case what you're desc for abspos is clipped in FF
<dael> Florian: If we can prove there's no compat problem, would we agree visible by default is a better behavior or not?
<dael> Rossen_: I cannot speak on better or not.
<dael> Rossen_: It's preferencial
<dael> fantasai: It's more expected since that's what we do everywhere else.
<dael> Rossen_: I'd like to hear from blink or webkit if they're willing to change.
<bradk> Overflow should be visible
<dael> ??: I'm not prepared to comment.
<dael> TabAtkins: I dunno.
<gregwhitworth> s/??/myles
<myles> yes
<rachelandrew> I don't have a strong opinion, not sure many authors are using this (on the web)
<dael> Rossen_: I thinkt he overall behavior proposed change is well understood. Let's try to close and see how to move forward. Florian proposal is to change the behavior and define that overflow of items inside columns of multicol are not clipped. And if we add a column selector with overflow is seperate.
<bradk> +1
<dael> Rossen_: In the absense of the column selector, are there obj to changing hte behavior of items being clipped to not clipped.
<dael> Rossen_: obj?
<dael> RESOLVED: Columns do not clip by default
<dael> Rossen_: If there are use cases for clip we'll decide if we need the selector

[cvrebert]

Pinged the relevant pre-existing Chrome bug: https://crbug.com/269061#c19