- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Jun 2017 16:47:46 +0000
- To: public-css-archive@w3.org
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`
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: Clipping of content that overflows a column<br>
<dael> Github: https://github.com/w3c/csswg-drafts/issues/314<br>
<dael> Florian: The TR version of multicol and the ED are contridicting<br>
<dael> Florian: Browsers aren't interop.<br>
<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.<br>
<dael> Rossen_: Do you mean overflow in the inline direction in a column, block, both?<br>
<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<br>
<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.<br>
<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.<br>
<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.<br>
<dael> Florian: That's bad, especially if one day we have a selector to selecto column boxes.<br>
<bradk> +1 on those examples<br>
<rachelandrew> I think currently firefox overflows, Chrome clips<br>
<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.<br>
<rachelandrew> https://codepen.io/rachelandrew/pen/YpXqNY?editors=110<br>
<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<br>
<dael> gregwhitworth: Is there a test case? I'm looking at bugzill and all browsers have overflow.<br>
<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.<br>
<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<br>
<dael> fantasai: Even if you have fix column count you can overflow by creating more columns<br>
<dael> Rossen_: YOu're correct.<br>
<dael> Rossen_: You can always have an item that overflow the height<br>
<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?<br>
<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?<br>
<dael> fantasai: I'm guessing one answer is easier to impl.<br>
<dael> Florian: Yes, and that's not what the spec says<br>
<dael> fantasai: Also, abspos elements is a different question as it's not in the column<br>
<dael> Florian: It depends on the containing block.<br>
<dael> fantasai: Right, they would be cliped by containing block, not the column necessarily. So the abspos cae splits into two sub-cases.<br>
<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.<br>
<Rossen_> https://codepen.io/rachelandrew/pen/YpXqNY?editors=110<br>
<dael> Rossen_: To be on the same page, rachelandrew pased a codepen^<br>
<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<br>
<dael> Florian: THat's one of the cases<br>
<dael> Rossen_: What is see is that all brwsers but FF clip.<br>
<dael> Rossen_: This is most likely a change in our behavior that was made for interop purposes.<br>
<bradk> I think the last time I tried to do a positioned tooltip in multicol, it wrapped to second column in some browser (horrible)<br>
<fantasai> Rossen, the original spec called for clipping iirc, that's why multiple browsers clip<br>
<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.<br>
<dael> Florian: I thought you said edge doesn't clip<br>
<dael> Rossen_: WE didn't used to. At some point we must have changed for interop<br>
<dael> fantasai: Or it could have been for spec. It did say to clip.<br>
<fantasai> s/spec/spec compliance/<br>
<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<br>
<dael> Florian: Another arguement for that is multicol has been more sucessful in printed media and prince does overflow.<br>
<dael> Rossen_: That could be, though I've seen epub readers use multicol for pagination. Those might suffer.<br>
<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<br>
<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.<br>
<dael> Florian: If we want to put it in author hands...<br>
<dael> dbaron: It seems like the overflow is the easy way to make it author controlled.<br>
<dael> Rossen_: dbaron did you mean overflow of multicol or have it apply to a selector<br>
<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<br>
<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<br>
<dael> Rossen_: If you put together market share I'd saya majority of content does clipping<br>
<dael> Florian: You can cope with it, doesn't make it good.<br>
<dael> Rossen_: It's what's expected on the web<br>
<dael> Florian: Except for people in print and people using FF<br>
<dael> dbaron: I also haven't seen this as a compat issue for us.<br>
<dael> gregwhitworth: [missed]<br>
<dael> dbaron: I don't remember seeing it<br>
<dael> Florian: I don't think it would be mobile browsers, I think it would be apps that use browser as the run time.<br>
<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; }<br>
<dael> Rossen_: That's what I was referring to. I've seen multiple touch webapps that do provide epub experience based on multicol<br>
<dael> Florian: I think that's how ibook works<br>
<dael> Florian: I'd like to go visible by default and hav e a column selector that could take overflow<br>
<dael> Florian: Current behavior isn't clip by default. It's clip by default except something and that's nto great.<br>
<dbaron> do Chromium, WebKit, and Edge all clip columns in both dimensions?<br>
<dael> Rossen_: What is not clipped? I couldn't find anything.<br>
<dael> Florian: abspos and the like?<br>
<dael> Rossen_: You cannot make a column be a containing block<br>
<dael> fantasai: You can make an element in the column<br>
<dael> Rossen_: In which case the lement itself is clipped.<br>
<dael> fantasai: Box can overflow the lement<br>
<dael> Rossen_: If you have a no-breaking word tha expands past the column it's clipped anywhere except FF<br>
<Rossen_> https://bug1282363.bmoattachments.org/attachment.cgi?id=8765359<br>
<dael> Florian: And floats with negative are clipped. I haven't tested transformed content. Maybe everything is clipped, I haven't tested all variants.<br>
<dael> Rossen_: Going through the test case what you're desc for abspos is clipped in FF<br>
<dael> Florian: If we can prove there's no compat problem, would we agree visible by default is a better behavior or not?<br>
<dael> Rossen_: I cannot speak on better or not.<br>
<dael> Rossen_: It's preferencial<br>
<dael> fantasai: It's more expected since that's what we do everywhere else.<br>
<dael> Rossen_: I'd like to hear from blink or webkit if they're willing to change.<br>
<bradk> Overflow should be visible<br>
<dael> ??: I'm not prepared to comment.<br>
<dael> TabAtkins: I dunno.<br>
<gregwhitworth> s/??/myles<br>
<myles> yes<br>
<rachelandrew> I don't have a strong opinion, not sure many authors are using this (on the web)<br>
<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.<br>
<bradk> +1<br>
<dael> Rossen_: In the absense of the column selector, are there obj to changing hte behavior of items being clipped to not clipped.<br>
<dael> Rossen_: obj?<br>
<dael> RESOLVED: Columns do not clip by default<br>
<dael> Rossen_: If there are use cases for clip we'll decide if we need the selector<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/314#issuecomment-310138645 using your GitHub account
Received on Wednesday, 21 June 2017 16:47:52 UTC