- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 22 Oct 2018 10:09:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `gap properties for block layout`, and agreed to the following:
* `RESOLVED: Add the margin-trim property with values [ none | in-flow | all ] to css-box-3`
* `RESOLVED: margin-break controls not just margins at fragmentation breaks, but also at the beginning and end of the fragmentation chain`
<details><summary>The full IRC log of that discussion</summary>
<heycam> Topic: gap properties for block layout<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/3068<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/2848<br>
<heycam> fantasai: basically the request from authors is to get rid of the margin at the very top and bottom of an element<br>
<heycam> ... so top before the first element, and bottom of the last element<br>
<heycam> ... suggestion in one is to have a different box-sizing value of some kind<br>
<heycam> ... other suggestion was can we have gaps to do this, add gaps to block layout<br>
<heycam> ... I don't thinkI want to add gaps to block layout<br>
<heycam> ... margin collapsing is its own special thing, fairly complicated<br>
<heycam> ... but we can solve the problem by having a property that gets rid of the margins in the interior of an element<br>
<heycam> ... I think tables do this automatically in quirks mode<br>
<heycam> ... so this proposal is to add a property that would do this, and have an on/off switch, or do it for all items, or only in flow items, or something<br>
<heycam> ... I want to see what people think about this, and whether to add it to the css-box-3 spec<br>
<heycam> TabAtkins: we already have a use case for it in css specs themselves<br>
<heycam> ... notes, examples, etc. have a :first-child { margin-top: 0 } rule, which works unless you start the element with raw text<br>
<heycam> ... so the necessity of making this actually robust seems fairly clear to me<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/3068#issuecomment-417486499<br>
<heycam> fantasai: there's a rough proposal in this comment<br>
<fantasai> margin-trim: none | in-flow | all<br>
<heycam> ... up for bikeshedding, etc., but that's the starting point proposal<br>
<heycam> florian: that would work on elements that establish a BFC?<br>
<Jia_An> join #tpac-chat<br>
<heycam> fantasai: yes, also reasonable to do on flex containers<br>
<heycam> TabAtkins: does it work on blocks taht don't establish a BFC?<br>
<heycam> fantasai: yes<br>
<heycam> s/taht/that/<br>
<heycam> iank_: is this the same thing as the -webkit-margin-collapse?<br>
<heycam> TabAtkins: I don't know what those are<br>
<heycam> fantasai: it doesn't control collapsing, it switches to discarding<br>
<heycam> TabAtkins: might just be a terminology issue<br>
<heycam> ... I don't know what those properties do<br>
<heycam> iank_: I believe one of the values nukes the whole margin collapsing result<br>
<heycam> ... and just makes it go to 0<br>
<heycam> fantasai: this is different in that it keeps the margin of the element itself, it kills the margin of its first child<br>
<heycam> TabAtkins: the reason why this is important, rather than putting prop on first child, is when the first child is a text node<br>
<heycam> ... if there's an element right after that you want to keep the margin<br>
<heycam> ... either that or have the ability to target text node, which I would rather avoid<br>
<heycam> iank_: is there an example of that in an issue somewhere?<br>
<heycam> TabAtkins: I'll find one<br>
<fantasai> <div><br>
<fantasai> some text<br>
<fantasai> <p>more text</p><br>
<fantasai> </div><br>
<fantasai> <div><br>
<heycam> florian: if you select the first child with a selector, it might be display none, which would do the wrong thing<br>
<fantasai> <p>some text</p><br>
<fantasai> <p>more text</p><br>
<fantasai> </div><br>
<heycam> eae: sounds like a good idea<br>
<heycam> ... would like to see an example<br>
<heycam> fantasai: in this example, in either case, you don't want margins at the top and bottom of htethe div<br>
<heycam> ... you just want the margin to go away because you've specified how much space you want between the border hwich is visisble, and hte text which is visible<br>
<heycam> ... if you were trying to rely on hte :first-child selector, you could not do this correctly<br>
<heycam> ... since it would select the <p><br>
<heycam> ... which is after some amount of text<br>
<heycam> ... this is the example Tab pulled from the specs<br>
<fantasai> s/is visible/is visible as 'padding'/<br>
<heycam> TabAtkins: it ends up happening rarely in CSS, since it relies on the first text child not having links in it<br>
<heycam> ... which is rare<br>
<heycam> Rossen: what spec is this going in?<br>
<heycam> fantasai: I would suggest css-box-3, which has no new features right now<br>
<heycam> ... it's just what's in CSS 2 with updated terminoligy<br>
<fantasai> https://www.w3.org/TR/css-box-3/<br>
<heycam> TabAtkins: I agree<br>
<heycam> Rossen: would margin-break go there too?<br>
<heycam> fantasai: there or fragmentation level 4<br>
<heycam> ... which is where box-decoration-break is<br>
<heycam> ... should xref from here for sure<br>
<heycam> Rossen: proposal is to add margin-trim with the values as above<br>
<heycam> TabAtkins: does the all value affect all floats touching the start edge of the container?<br>
<heycam> ... want to make sure that's a reasonable thing to do<br>
<heycam> iank_: I'll have to check<br>
<heycam> Rossen: should be straightforward<br>
<heycam> ... you're positioning your floats in the beginning of your container, and at that time you can decide to trim the margin<br>
<heycam> ... you're not going to affect anything below you at this point<br>
<heycam> ... the thing that will be a bit iffy is when you start pushing margins to the next line<br>
<heycam> ... want to make sure you're not losing the margins, but these are impl details<br>
<heycam> fremy: does the all value also affect the margin at the bottom of a float?<br>
<heycam> ... that seems more problematic<br>
<heycam> ... you don't know when you place the float if you're going to be at the bottom of the element<br>
<heycam> fantasai: if you get to the bottom and the float is what it's causing it to be taller, you can back up to the border edge<br>
<heycam> ... but you're right that is a trickier situation than the top<br>
<heycam> florian: if the margin of the float is pushing the bottom edge, and you can just remove it by changing the rest of the layout, it's fine<br>
<heycam> ... but if removing it entirely, some lines could intrude where they couldn't before<br>
<heycam> ... trim only the amount of the margin that is extending<br>
<heycam> iank_: does this eat just the first and last margin of the first element? or eat the whole collapsing margin?<br>
<heycam> fantasai: the whole collapsed margin<br>
<heycam> florian: the element, its first child, etc., as long as they're collapsing<br>
<heycam> Rossen: just to be sure, when we talk about the first float, we're talking about floats that are at the beginning? two or many adjacent?<br>
<heycam> florian: yes because your goal is to get visual alignment<br>
<heycam> Rossen: just want to be explicit since we keep talking about "the first"<br>
<heycam> ... but with float you can have many<br>
<heycam> TabAtkins: all margins touching the start edge<br>
<heycam> RESOLVED: Add the margin-trim property with values [ none | in-flow | all ] to css-box-3<br>
<heycam> florian: now that we have this and the thing we resolved on before the break, discarding margins around frag breaks, if we go back to Jen's use case<br>
<heycam> ... the first para of first multicol column, we can address it with the thing we just created<br>
<heycam> ... maybe we should also address it with the margin-break thing we were discussing<br>
<heycam> fantasai: I think I would lean towards having both of those properties controlling this particular break<br>
<heycam> florian: in the frag context, you probably want the same beahvioru after the first forced break, and at the beginning<br>
<heycam> ... because there's no desire for the second chapter to look different from the first chapter<br>
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6305 <-- an example of the "zero out the margins of first/last child" strategy giving bad results<br>
<heycam> florian: the summary is that margin-break, the value that causes the margin to be discarded causes it to be discarded not only after breaks, but also at the beginning of the first fragmentainer<br>
<heycam> s/margin-break/margin-break:discard/<br>
<heycam> ... when you explicitly opt in to discarding things, not only discard around breaks, but also at the start<br>
<jensimmons> and at the end?<br>
<heycam> ... effectively you count the start as a forced break<br>
<heycam> fantasai: proposed resolution is that margin-break controls not just margins at fragmentation breaks, but also at the beginning and end of the fragmentation chain<br>
<heycam> Rossen: and this will be an additional requirement on margin-break?<br>
<heycam> fantasai: yes<br>
<heycam> Rossen: and this also applies at the end, not just the start<br>
<heycam> RESOLVED: margin-break controls not just margins at fragmentation breaks, but also at the beginning and end of the fragmentation chain<br>
<gregwhitworth> florian & fantasai: is there a reason that we NEED two seperate properties that are doing the same thing, just in two different contexts?<br>
<fantasai> gregwhitworth, yes, you want to control behavior at breaks and behavior of a container separately<br>
<fantasai> gregwhitworth, also one applies to the element's own margins and one applies to its contents :)<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3068#issuecomment-431777940 using your GitHub account
Received on Monday, 22 October 2018 10:09:51 UTC