- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 12 Apr 2018 11:23:30 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `How does block inside inline affect the box tree, exactly?`, and agreed to the following resolutions: * `RESOLVED: In a block-in-inline split, the block is inside the inline in the box tree, and is a sibling of the two fragments of the inline in the fragment tree` * `RESOLVED: A multicolumn spanner that splits and inline is inside of the inline box tree and a sibling to the fragment in the fragment tree` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: How does block inside inline affect the box tree, exactly?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1477<br> <fantasai> Possible practical implication of previous issue might be getComputedStyle on ::marker?<br> <dael> TabAtkins: I recommend looking at the first comment because Loirooriol has a great markup example.<br> <dael> TabAtkins: Basic idea, in the box tree there's a span and a div list inside it is it an inline boc with a block box inside and during fragmentation we split that or does the splitting happen at box tree time?<br> <dael> florian: Observable?<br> <dael> TabAtkins: Effects how other properties are defined so yes in thoery. I don't think any property could be used as a probe of it. No one uses exact box tree for spec<br> <dael> ??: Saying splitting happens in the box tree is more consistant because operations happen in the order. If splitting is in box tree we need some kind of exception. CSS 2.1 doesn't distinguish between when it happens so it's like it happens between boxes.<br> <dael> TabAtkins: Impl information in FF eq they split and special case text-decoration so it propagates down.<br> <dael> koji: WE splits spans, wrap it in anon box, and for the box we split. That last part is same as Geck.<br> <astearns> s/??/Loirooriol<br> <fantasai> https://www.w3.org/TR/css-break-3/#break-decoration might need an update<br> <dael> TabAtkins: Our layout structure doesn't distinguish boxes and fragments either. Hard to argue we have one behavior or the other.<br> <dael> fremy: Not sure why we need to know<br> <dael> TabAtkins: Effects how we write specs.<br> <dael> iank_: Anything we do with block behavior should stay.<br> <dael> TabAtkins: Impl details don't matter, it's thetheoretical model. Being closer to impl matters. WE can live with either model. We just need to decide.<br> <dael> florian: Which makes spec writing easier?<br> <dael> TabAtkins: Split not until fragment time is easier I believe. Makes text-decoration easy. Other cases that treat them as a single thing work fine in that model.<br> <dael> dbaron: I worry a bit about making something trivial to define if it's actually more complex then impl. I think it's better if the thigns easy in impl are easy in spec and hard in impl are hard in spec.<br> <dael> TabAtkins: Agree.<br> <dael> florian: That's say split boxes not fragments.<br> <dael> fantasai: Shows up for box-decoration break.<br> <dael> ??: If splitting happens in box inline assumes if you general boxes in that case it uses the box. If one of the two inline boxes are choosen it's strange.<br> <astearns> s/??/Loirooriol<br> <dael> TabAtkins: And both are the principle box because both get all properties<br> <dael> fantasai: I'd prefer at fragment tree time and if we want to change the parentage maybe that's senseible. I don't think split in the box tree. And I think of this as framentation so it makes sense to say that's what's happening.<br> <dael> fantasai: Box decoration break should be controlling behavior at these breaks. We're slicing by default but may want to switch to clone. THis is how we define howt he side of a box that has been split are drawn and if we don't we have to define that it behaves as a fragment. If it is a fragment it' snot a special case.<br> <dael> florian: Split at fragment level makes a lot more sense. Seems to be a difference with impl that don't distinguish, but dbaron point earlier that this makes it easier to define hard to impl...<br> <dael> fantasai: Does it? There's a reason why we try to discuss and get review and it's to point out where model doesn't make sense. I see some reasons for define as fragments and only theoretical reason for the other.<br> <fantasai> s/reason/worries/<br> <dael> Rossen: The model in fragmentation spec makes a lot of sense to me. Early stages of writing draft there was back and forth for what is a fragments and what's a principle box. As an impl it was a time somewhat odd to map and refer to things not in our impl. There's not a principle box in the impl nor do we call anything a fragment, but the model matched well.<br> <dael> Rossen: If the model in the fragmentation spec doesn't make sense what do you propose to change?<br> <dael> fantasai: Didn't say it doesn't make sense? Issue is about block and inline splits. Is inline fragmented or of many boxes? A lot of impl has a structure that's not one or the other. We need the theoretical set up here.<br> <dael> iank_: Eventually we want to move to a model where we use fragment so I'm fine that way.<br> <dael> iank_: We don't want to do inline splitting at the box tree level eventually.<br> <dael> florian: I think so long as we have a conceptual model where boxes and fragments are different this should be at the box level. If we only want to alk baout boxes b/c matches impl that's a different conversation.<br> <dael> dbaron: I think there's another view to it then not having both concepts which is that you can keep boxes and fragments as terms but view the fragments as what you get when you split boxes rather then a later process stage.<br> <dael> florian: I't s aprocessed box?<br> <dael> fantasai: Isn't that what they are?<br> <dael> dbaron: That's what I thought until a few weeks ago. However people have said things that have made me think differently, including this issue.<br> <dael> florian: I don't think fragments are boxes that have bene processed in a particular way.<br> <dael> TabAtkins: As per spec you are right. fragment tree is the result of layout on boxes. You get a different tree out of that.<br> <dael> florian: Fragments is not a short term to mean a box piece. It' snot a whole buch of boxes some of which are fragments.<br> <dael> fantasai: A box is composed of one or more fragments.<br> <dael> florian: But later in the process we don't have boxes and fragments.<br> <dael> dbaron: You have a box tree and you go to a fragment tree by splitting things up.<br> <dael> dbaron: A box corrisponds to one or more fragments. If the box has children those are in one or more of the children.<br> <dael> fantasai: This is the case where it's not clear that's happening.<br> <dael> TabAtkins: In multicol even childs might fragment. putting some children in one fragment and one in the next is fair.<br> <dael> dbaron: If box a is parent of box b then any fragment of box b will have a parent of fragment a.<br> <dael> fantasai: How we lay this out they don't act like their the child of the parent. Layout wise it behaves like a sibling and lays out that way. Same is true of block. It lays out as if it's a sibling of the anon block before and after.<br> <dael> florian: It changes the varient but it doesn't change that you can consider the fragment tree as a processed version of the box tree. There's a little reparenting but not a lot.<br> <dael> Rossen: I'm trying to get to a model that makes sense. What's the model we define in the frag spec in your mind?<br> <dael> dbaron: I didn't see the fragmentation spec as contridicting my model.<br> <dael> fantasai: It doesnt' because it doesn't talk about columns.<br> <dael> TabAtkins: It's fragmenting easy cases.<br> <fantasai> s/columns/block-in-inline splits and column spanners/<br> <dael> Rossen: Is it easy? If you have a whole bunch of open inline elemnts, open spans, and text inside that generates some line effects and then a block element that breaks this line flow. At that moment what do you have?<br> <dael> dbaron: In my mental model? One of the things about the blocks inside is that some ways they act like not a child like backgrounds but for relpos they act like they are.<br> <dael> Rossen: If an inline element was an anchor open before and close after the block<br> <dael> dbaron: I think it's not dom event propagation.<br> <dael> Rossen: But it's type of hit test<br> <dael> florian: When you say some aspects siblings and some not, it's that the same as in box tree descendents and in fragments it's siblings?<br> <dael> dbaron: If you have it as though there's a thing there is some ways and not others it's easier to have the object there and disable features then not have it there and reconjur it when you need it.<br> <dael> fremy: If you have regions it's in 2 elements and your model can't have regions. They're in differnet places of the tree and they'll have fragments that aren't related.<br> <dael> dbaron: It was a model desc how fragmentations worked and I didn't mean you have to foloow it always. Still feels weird to me and I didn't know the spec was different until recently<br> <dael> florian: For Geck these are siblings or one child? The block that intrupts inlines.<br> <dael> dbaron: Child of the inline but it is a child of the block fragment of the inline and those are kind of special.<br> <dael> florian: BUt that's not a conflict. You have a single data structure that represents both box and fragment tree. In that single data structure there's a thing that keeps the parenting relationship. In box tree they're parented in fragment not. THe object is present in one of the two trees. You're just overlapping the two so it's difficult to talk abotu one concept without hte other.<br> <dael> Rossen: Is there a model we can agree on?<br> <dael> dbaron: I'm fine resolving on it. I just want to recognize it's pretty substantive decision.<br> <dael> Rossen: With that warning. What do people think? Ready to resolve?<br> <dael> TabAtkins: If people agree, yeah?<br> <dael> Rossen: Objections?<br> <dael> TabAtkins: Prop: A block inside an inline is a descendant in the box tree and a sibling in the fragment tree.<br> <dael> fantasai: And the inline is a single box that has been fragmented.<br> <dael> Rossen: You're agreeing<br> <dael> fantasai: They're two things.<br> <dael> astearns: It's not just the box that the block is a sibling.<br> <dael> florian: You're agreeing, there's wordsmithing.<br> <dael> fantasai: I want it clear that there's a single inline that has been fragmented. It's saying the block is a sibling that's a fragment which is a fragment and there's a following fragment doesn't say it's the same box.<br> <dael> Rossen: Prop: Blocks inside of...<br> <dael> Rossen: Objections to what fremy is typing?<br> <TabAtkins> <inline>foo<block>bar</block>baz</inline> <== 'block' is a child of 'inline' in the box tree; 'block' is a sibling of two fragments of 'inline' in the fragment tree.<br> <fantasai> proposed resolution: In a block-in-inline split, the block is inside the inline in the box tree, and is a sibling of the two fragments of the inline in the fragment tree<br> <fremy> Proposal: There is one inline box containing one block box (in the box tree). In the fragment tree, there are two inline fragments, sibling on each side of the block fragment.<br> <dael> Rossen: What fantasai said is the same. Objections to In a block-in-inline split, the block is inside the inline in the box tree, and is a sibling of the two fragments of the inline in the fragment tree<br> <dael> RESOLVED: In a block-in-inline split, the block is inside the inline in the box tree, and is a sibling of the two fragments of the inline in the fragment tree<br> <dael> fantasai: One more. Same applies to column spanners splitting a box. Same logic applies.<br> <dael> florian: Same problem but column spanner may break multi levels of parents.<br> <dael> Rossen: They can already have multiple.<br> <dael> Rossen: Agreed?<br> <dael> Rossen: Prop: A multicolumn spanner that splits and inline is inside of the inline box tree and a sibling to the fragment in the fragment tree<br> <dael> RESOLVED: A multicolumn spanner that splits and inline is inside of the inline box tree and a sibling to the fragment in the fragment tree<br> <dael> fantasai: We forgot anonymous boxes<br> <dael> <br type="lunch"><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1477#issuecomment-380771705 using your GitHub account
Received on Thursday, 12 April 2018 11:23:33 UTC