- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Feb 2024 00:49:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css2][css-flow][cssom] How does avoiding floats affect margins?`, and agreed to the following: * `RESOLVED: Auto margins align between the remaining space after accounting for floats (existing interoperable behavior)` * `RESOLVED: For elements with a principal box, getComputedStyle always returns used values` * `RESOLVED: We'd like resolved margins to round-trip` <details><summary>The full IRC log of that discussion</summary> <emilio> oriol: so CSS2 when translated in modern terminology, it says that a block level element which establishes an independent formatting context, shouldn't collapse its margins<br> <dbaron> s/collapse its margins/overlap the margin box of floats/<br> <emilio> ... it can do so by being moved next to the floats or below the floats<br> <emilio> ... if it's moved below then this is done by inserting clearance<br> <emilio> ... which is a well-defined concepts<br> <emilio> [room chuckles]<br> <emilio> dbaron: it's a defined concept<br> <emilio> oriol: problem is what to do in the inline axis<br> <emilio> ... by what mechanism are we placing this element next to the floats<br> <emilio> ... the proposal is to modify the used margin value to not overlap the floats<br> <emilio> ... we could introduce another concept instead<br> <emilio> ... I'd go with using margins<br> <emilio> ... this has one potential problem for the auto value<br> <emilio> ... because gCS exposes the used value of margins for auto<br> <emilio> ... (spec says always but they only do for auto).<br> <emilio> iank_: floats and margins don't work like you'd expect to<br> <emilio> ... margins start at the containing block edge<br> <emilio> not at the float edge<br> <emilio> ... so margins always are referring to the CB edge<br> <emilio> ... auto margins are different<br> <emilio> ... auto margins center in the area between the float and the edge of the CB<br> <emilio> oriol: right so question is what should getComputedStyle return<br> <emilio> ... gecko returns 0 and zero<br> <fantasai> [oriol reports the results of such testcases]<br> <fantasai> [they are various levels of broken]<br> <emilio> oriol: blink aligned with servo<br> <emilio> ... would like to resolve on them<br> <emilio> ... first proposed resolution would be that we avoid overlapping floats by changing the used margin<br> <emilio> iank_: don't wanna go down that road<br> <emilio> ... there are other mechanism that affect float positioning<br> <emilio> ... there's a lot of weird stuff in there, I think the current box is positioned<br> <emilio> oriol: but margin + border-box should be the width of the containing block<br> <emilio> ... should we drop that constraint?<br> <emilio> iank_: yes<br> <emilio> fantasai: that seems fine to drop in presence of floats<br> <emilio> q+<br> <emilio> astearns: this specific issue is about what value you report for gCS<br> <emilio> ... there are other things that affect placement of formatting contexts that affect that equation<br> <emilio> nicole: Can we get more consistent behavior across browsers without that constraint?<br> <emilio> iank_: yeah the biggest inconsistency is what to report for auto margins in gCS<br> <fantasai> emilio: is there inconsistency only in the presence of floats? e.g. if there's no floats, do we get reasonable results?<br> <emilio> iank_: in absence of floats you report the right values<br> <emilio> oriol: not sure if you clear what the reported behavior is<br> <fantasai> emilio: was curious about what the mechanisms are<br> <emilio> iank_: alignment of table cells<br> <emilio> ... might be a webkit-ism<br> <emilio> ... let me find the other ones<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to comment on alignment<br> <astearns> ack emilio<br> <emilio> fantasai: the border-box + margin-box filling the containing block we give up in the alignment spec via e.g. justify-self<br> <emilio> ... I think round-tripping via gCS would be great<br> <emilio> ... but I don't need we need to make the equation add up<br> <emilio> emilio: for round-tripping in this case you do need that equation to add up<br> <emilio> ... because the margin would start from the CB edge<br> <emilio> iank_: the other things that affect this is the webkit values of text-align<br> <emilio> ... which is equivalent to justify-self center<br> <emilio> dbaron: for the html alignment attrs?<br> <emilio> iank_: yes<br> <emilio> dbaron: gecko has similar ones<br> <emilio> oriol: I think we could resolve on auto margins centering in the remaining space which I don't think it's specified<br> <emilio> ... also that gCS should return a value that round trips<br> <emilio> ... so, align with blink and servo<br> <emilio> RESOLVED: Auto margins align between the remaining space after accounting for floats (existing interoperable behavior)<br> <dbaron> Unrelated side note: at least I still remember CSS2's float rules well enough to be able to write a testcase where browsers are not interoperable and get it to show non-interop on the first try:<br> <dbaron> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22width%3A%20200px%22%3E%0A%20%20%3Cdiv%20style%3D%22float%3A%20left%3B%20height%3A%20100px%3B%20width%3A%2010px%3B%20background%3A%20blue%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%20style%3D%22margin-left%3A%2020px%3B%20width%3A%2050px%3B%22%3E%0A%20%20%20%20%3Cdiv%20style%3D%22float%3A%20left%3B%20width%3A%2060px%3B%20height%3A%2020px%3B%20background%3A%2<br> <dbaron> 0fuchsia%22%3E%3C%2Fdiv%3E%0A%20%20%3C%2Fdiv%3E%0A%3C%2Fdiv%3E (WebKit follows the letter of the spec; Gecko and Chromium follow the spec's resummarization that follows "Loosely: ".)<br> <emilio> astearns: resolving on round-tripping doesn't seem super-useful if you're an implementor reading the spec<br> <emilio> astearns: proposal is to spec that auto-margin values round trip in getComputedStyle()<br> <emilio> fantasai: we don't know how, one is what oriol said, the other is returning "auto"<br> <emilio> astearns: might not be web compatible<br> <emilio> fantasai: specifically for the float case you could round-trip to auto<br> <emilio> iank_: no no no no<br> <emilio> ... the reason why we aligned to Servo's behavior<br> <emilio> ... we moved towards FF but too aggressively (return 0 for auto margins)<br> <emilio> ... and got bug reports<br> <emilio> ... so we need to return a decent used value<br> <emilio> fantasai: your proposed resolution has 2 interpretation, if only one is workable then we should write that down<br> <emilio> dbaron: are there any cases where there's no non-auto-value that round-trips?<br> <emilio> dbaron: can't think of one off the top of my head<br> <emilio> dbaron: part of the lesson is that we shouldn't write specs in terms of constraints because they have solutions that don't add up to what you thought<br> <emilio> dbaron: can we resolve on a goal rather than an exact spec?<br> <emilio> dbaron: if we resolve that we want ^<br> <emilio> fantasai: there shouldn't be two different ways of fixing that<br> <florian> q+<br> <fantasai> emilio: Proposed resolution 1: return used values, proposed resolution 2: they must round-trip<br> <astearns> ack florian<br> <emilio> florian: I think we shouldn't edit in css2<br> <emilio> ... wherever it goes, not css2<br> <florian> s/ not css2/ not css2: it is not in a publishable state, and after a few years, we evidently do not know how to get it to a publishable state<br> <emilio> RESOLVED: For elements with a principal box, getComputedStyle always returns used values<br> <emilio> s/used values/used values for margins<br> <emilio> RESOLVED: We'd like resolved margins to round-trip<br> <emilio> [rant about css2]<br> <bramus> ScribeNick: bramus<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9174#issuecomment-1939934462 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 February 2024 00:49:36 UTC