- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Nov 2017 00:18:37 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Background and borders for spanners`, and agreed to the following resolutions: * `RESOLUTION: If the fragment before the spanner is empty, nothing special happens; the top mbp is above the header, and it's just an empty fragment.` <details><summary>The full IRC log of that discussion</summary> <eae> Topic: Background and borders for spanners<br> <eae> github issue: https://github.com/w3c/csswg-drafts/issues/1072<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-299076034<br> <eae> fantasai: What if the spanner is the very first element in an element that has borders and margins and paddings?<br> <eae> fantasai: Is the top margin pushed to after the spanner?<br> <eae> fantasai: For an inline what florian suggest in the issue that would be broken, what would we do in that case?<br> <eae> rachelandrew: I'd like to see what implementations do at this point. Heavn<br> <eae> 't looked at that<br> <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?<!DOCTYPE html>%0A<span style%3D"border%3A solid%3B">%0A <span style%3D"display%3A block">splitblock<%2Fspan>%0Arest of text<%2Fspan><br> <eae> fantasai: Here is an example with a block splitting an inline. You can see that the border and then the split inline.<br> <eae> fantasai: There is a lot of fragmentation bugs as well. Entirely separate pile of "fun". Right now we're only dealing with the multicol aspects. What are the implications for this split.<br> <eae> * fantasi gives an example with spanners and multicol and borders *<br> <eae> iank_: What appears if the spanner is the first child? What do you want to appear before the spanner? Maring border padding?<br> <eae> fantasai: Yes<br> <eae> iank_: Makes sense<br> <eae> fantasai: I don't know if I want that but it is what would fall out from it being analogs<br> <eae> s/analogs/analogous/<br> <eae> Rossen: The example is having a section inside an element with border?<br> <eae> * fantasi draws an example *<br> <eae> fantasai: We have a multicol with some stuff and a section element, then we have an h2 and the h2 is a spanner.<br> <eae> fantasai: The section has a border<br> <dbaron> The in-progress Gecko implementation treats it as analogous to block-in-inline splitting.<br> <dbaron> although it's a little harder in a few ways, and a little different in others.<br> <eae> fantasai: We definitively have a border around the section. The question is where the border goes.<br> <eae> fantasai: Remember the header is inside the section.<br> <eae> fantasai: First piece of border is before the split. Then you have the block and then the border continues.<br> <eae> fantasai: If that is bad behavior we could say that this fragment doesn't exist and then ...<br> <eae> * these notes makes no sense without the visual of the example... *<br> <eae> Rossen: For the purpose of margin collapsing, When we take the spanner out of the element, the right element, asusming it was the only content, then margin collasoing with the red border would change.<br> <eae> Rossen: If the element is effectively taken out of the flow of the containing blocks flow and then I don't see a reason why this element would be breaking the position of the top border of its parent.<br> <nainar> Board images: https://photos.app.goo.gl/sm5cc7q8pywbSF0P2<br> <eae> Rossen: Now that the spanner is outside of the containing block and margin collasping would change, the red box in the digram could be pushed further down due to margin collapsing.<br> <eae> florian: So you're saying it would normally be posioined here but there being no margin between them there would be no space between them and the margin would not be in between. I think that is a pretty good point, arguing for leaving it up here.<br> <eae> s/florian/fantasi/<br> <eae> rachelandrew: It is little weird, if that was one line of text up there it is still odd.<br> <jensimmons> q+<br> <eae> iank_: Effecitvely the spanner is treated as out of flow positioned?<br> <eae> Rossen: Yes, pulling it out of flow is getting tricky. We're there already<br> <dbaron> Reading the IRC, this doesn't make any sense to me.<br> <eae> iank_: That would mean that margins would collapse though it<br> <dbaron> but I don't know what people are pointing at.<br> <eae> o<br> <dbaron> I also suspect you haven't even gotten to any of the interesting issues yet... :-P<br> <jensimmons> hey, is what I just said getting noted?<br> <jensimmons> seems like a lot of this conversation is being missed, sadly<br> <TabAtkins> ScribeNick: TabAtkins<br> <eae> fantasai: I think rossens argument about the marign collapsing bebehvor this is confusing. The margin top is never going to be between the header and the first paragrapgh. If we go with the behavior where the top fragment doesn't exist then the margin is between the header and first paragraph. Then why is it above the header?<br> <TabAtkins> fantasai: That for me is the compelling argument to not do anything.<br> <TabAtkins> jensimmons: I can see a use-case where section>h2>content is the proper markup for content, and for small viewport sizes it's styled one way, and for large it's done in this diagram style<br> <bradk_> does box-decoration-break apply to the first fragment above the spanner?<br> <TabAtkins> jensimmons: I think it's fine if we let it break<br> <TabAtkins> rachelandrew: I think so too. Just need a resolution for that so it's tied to the spec<br> <TabAtkins> fantasai: I think this is a common situation, just question of where to draw top mbp; it goes above the header<br> <TabAtkins> rachelandrew: Happy with that.<br> <TabAtkins> RESOLUTION: If the fragment before the spanner is empty, nothing special happens; the top mbp is above the header, and it's just an empty fragment.<br> <fantasai> s/RESOLUTION/RESOLVED/<br> <fantasai> ;)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-342668025 using your GitHub account
Received on Wednesday, 8 November 2017 00:18:41 UTC