- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 12 Apr 2018 09:34:23 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Spanning elements late in the content, treated as column-span: none`, and agreed to the following resolutions: * `RESOLVED: No change to L1 refiled against L2 to think about in context of n-spanners` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Spanning elements late in the content, treated as column-span: none<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2448<br> <astearns> s/commented/commented that they can open an issue on level 2<br> <dael> rachelandrew: You've got a spanner that's late enough that there isn't space to span. UA may treat it as if non has been set. I raised this as an issue against chrome. FF doesn't span yet. THere's an example code pen in the issue from the spec.<br> <dael> rachelandrew: Chrome's behavior isn't particularly useful.<br> <dael> rachelandrew: There wasn't interest in impl the issue and they thought authors should refain from this. Is it useful to have in the spec?<br> <dael> florian: Chrome behavior is terrible so we shouldn't allow that.<br> <dael> rachelandrew: Yes, but their point was they didn't think this was usefult o have in the spec.<br> <dael> florian: If we have a good behavior it's worth a may in the spec. Is there an alternative to the may?<br> <dael> fantasai: No.<br> <dael> rachelandrew: What will you do with them?<br> <fantasai> s/No/Can't think of anything/<br> <dael> dbaron: This is column spanning lements in a multi col with a fixed height?<br> <dael> florian: Yeah.<br> <dael> dbaron: Model of column spanning elements if you split the multi col into multiple mulcticol and you can only apply the fixed height on the last. So you get to it and you've gone past the max height and what should you have done earlier to make it fit?<br> <dael> fantasai: I gues alternative is overflow downwards instead of creating more columns.<br> <dael> dbaron: Normally multicol with fixed heigh make more columns but you can't do that here unless you go back.<br> <dael> florian: Overflow toe xtra columns and span that?<br> <dael> fantasai: Don't know number of columns.<br> <dael> fantasai: [whiteboards] when you make a spanner it breaks into multiple sets of spanner columns.<br> <dael> fantasai: [draws a row with 3 small boxes and then a row with one long box and then seveal other rows] when you have one set of columns and run out of space it generates more columns. You spanner goes down. [draws a row with 5 columns/boxes] you overflow here and make more columns. It's not awesome but it's another possibility of what you can do.<br> <dael> Rossen: I see how you draw that but introducing breaks in columns is nuts.<br> <dael> florian: You have the spanner and the contents before you basically end up in a 2 pass thing.<br> <dael> dbaron: I could make a no-more multipass suggestion which is that if you have a multi-col with col-spans you never overflow by making more columns. Instead any sets of columns before a column span are auto height. THat's always true. You fill the height you need. Then you have to fill the height you need.<br> <dael> dbaron: Basically you ignore the height when you're generating sets of columns before the span and then you ignore when generating the span itself. Then you get to the last set of columns and you honor the height if it means making it taller. If it makes it shorter you do auto-height again. It's all overflow going down.<br> <dael> florian: I think okay.<br> <dael> dbaron: Only thing you'd do to honor the height is make the last set of columns taller to fix. Pretty different from waht multicol does otherwise, but seems not completely crazy.<br> <dael> florian: Are you suggesting you keep the may and allow either what's in the spec or this or just this?<br> <dael> dbaron: I'd like to spec one behavior. We can try and spec something sane for the other. BUt if you start to allow column spans in some cases you get a bottom column that's shorter and shorter.<br> <dael> florian: And then all the sudden it pops out of the spanner<br> <dael> fantasai: So dbaron your method is a mode switch depending on if you contain spans?<br> <dael> dbaron: You should know if you have spans up front.<br> <dael> florian: Depends on if it spans the entire multicol or the current fragment of the multicol. If it's the second you still have to do layout.<br> <dael> dbaron: I feel like fragments in the multicol aren't that different from [missed]<br> <dael> florian: That's true. If you're in a non-fragmented multicol you trigger on presense of spanners and if you're in fragmented multicol you always do this and only place you have to start worrying is the last one.<br> <dael> fantasai: Seems to me we should make the behavior undefined.<br> <dael> rachelandrew: That results in...well...<br> <dael> florian: Chrome does something bad.<br> <dael> astearns: What we have isn't what Chrome does<br> <dael> fantasai: They're filling hte content then there's a spanner and it has to go below.<br> <dael> florian: You don't layout your columns and then find out there's a spanner, you find out firs there's a spanner.<br> <dael> Rossen: Also when we want to have variable column count spanners it becomes hokey. Triggering breaks and switching overflow in what direction. Multicol is simple and elegent in what it does Overflow columns are always in one direction and spans always span the columns. You're not really creating rows and trying to use those rows...<br> <dael> fantasai: I think if you have a spanner you don't want column rules underneath. Conspectually you have rows of column boxes. Going forward we should not have a model of column boxes trough the spanners.<br> <dael> rachelandrew: I think that's right.<br> <dael> rachelandrew: Do we want to try and resolve or to go away and think?<br> <dael> Rossen: L1 or L2?<br> <dael> rachelandrew: The may is in L1. Edge does spec behavior.<br> <dael> Rossen: And chrome has a bug they can fix<br> <dael> florian: BUg allowed by spec.<br> <dael> rachelandrew: If this is what we want we should remove the may.<br> <dael> florian: And if we want to do the thing dbaron suggests it shouldn't do one or the other. Author should choose.<br> <dael> fantasai: What bother's me about dbaron model is for all content befor ethe spanner I add content, get one behavior and as soon as there's a spanner i get different behavior and that's weird. What if you want the other behavior anyways? Empty spanner?<br> <dael> dbaron: If you want continuity you should get that going from end of multicol not start. If you want hte thing with the spanner to be the same as without one way is to try and make it so the bit after the last spanner behaves same as no spanners.<br> <dael> dbaron: Still ahrd.<br> <rego> this example looks bad in Chromium: https://codepen.io/mrego/pen/GxLQJm<br> <dael> florian: If you try for that you're past max height so you have no space left and an infiniate number of 0 height columns.<br> <dael> dbaron: I'm thinking that way because balancing for the bit after the last span is the thing that honors things like column fill.<br> <dael> fantasai: Right. I still think it's...if you as an author wanted that I'll stil a 0 height spanner at the bottom. I don't think that's great. Interesting way for a mode switch.<br> <dael> florian: If you don't set a height we don't have the problem in the first place.<br> <dael> florian: If you combine that with Rossen comment that eventually we want to span n columns instead of all<br> <dael> Rossen: That's been a request since we into multi col<br> <dael> Rossen: Let's try and move forward. There's more work to be done if we want to move forward with this. And it's in L2. Let's resolve on L1.<br> <dael> Rossen: Choices 1) continue with the may 2) change to an undefined 3) may changes to must<br> <dael> florian: 3.<br> <dael> Rossen: And we'll add continuation in L2<br> <dbaron> I think one of the prior mistakes here was probably allowing column-spanning elements anywhere within a multicol rather than just at the start...many things would have been simpler if they could only be at the start.<br> <dael> fantasai: I vote 1 or 2 because as we try to figure out how n column spanners work we may have a better idea of how this should work.<br> <dael> florian: Which allows chrome to fix themselves.<br> <dael> astearns: But you shouldn't expect that to happen.<br> <dael> fantasai: I think that rethinking this once there's a model for n spanners it'll give us a way forward. Rather then prematurely desciding this case.<br> <dael> Rossen: Would chrome people have a problem with this as a must?<br> <dael> eae: It's very hard for us to implement that behavior. We know current isn't great.<br> <dael> Rossen: Outside of test cases I haven't see compat problems.<br> <dael> rachelandrew: It's edge casey.<br> <dael> Rossen: I propose we stay with the may for L1. If give Chrome the ability to continue but validates the other model Edge uses. In L2 we think more.<br> <dael> rachelandrew: I'll raise this against L2.<br> <dael> fantasai: And I'd mark rediscussed after we figure out n columns<br> <dael> florian: Well, while we do n columns.<br> <dael> Rossen: Do we need resolution?<br> <dael> fantasai: Prop: No change to L1 refiled against L2 to think about in context of n-spanners<br> <dael> Rossen: Opinions or Objections?<br> <dael> RESOLVED: No change to L1 refiled against L2 to think about in context of n-spanners<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2448#issuecomment-380740480 using your GitHub account
Received on Thursday, 12 April 2018 09:34:27 UTC