Re: [csswg-drafts] [css-display] Should anonymous boxes always inherit through the box tree?

The CSS Working Group just discussed Should anonymous boxes always inherit through the box tree?.

<details><summary>The full IRC log of that discussion</summary>

```
<astearns> topic: Should anonymous boxes always inherit through the box tree?
<astearns> github topic: https://github.com/w3c/csswg-drafts/issues/1118
<myles> fantasai: There are anonymous boxes in the box tree. We defined an anonymous box in the box tree has initial values except for the ones which are inherited (from its parent box in the box tree). But! When we have display:contents, if the parent of the anonymous box, then the element's parent is really its grandparent!
<myles> TabAtkins: "parent box" is reasonably well-defined now, but with display:contents, not so much
<myles> fantasai: what I expect is that we look at the parent box in the box tree and we look at the element which generated that box
<myles> fantasai: However, implementations don't look at the box tree, they look at the parent element and its properties.
<myles> fantasai: sooooooo this is busted
<TabAtkins> (Specifically, "parent box" is simple enough, in a pre-display:contents world, that we don't have to worry much about the fact that it's weakly defined. With display:contents, tho, the full box tree starts being more relevant, adn the weak definition si more troublesome.)
<myles> fantasai: so are these bugs? Or should we update the spec?
<myles> TabAtkins: we should do the latter. Inheritance doesn't pay attention to the box tree. The fact that this uses the box tree was hand-wavey
<myles> TabAtkins: <gives obscure example>
<fantasai> <section> <div>Foo</div>
<fantasai> </section>
<fantasai> <section> <div><span>Foo</span></div>
<fantasai> </section>
<fantasai> section { color: red;
<fantasai> }
<fantasai> div { color: green; display: contents;
<fantasai> }
<myles> TabAtkins: explains the example
<myles> dbaron: there are 2 different distinctions to make (but one may not be observable)
<myles> dbaron: gecko recently changed how how anonymous boxes inherit (but only for nested anonymous boxes). Previously, if you have 2 nested ones, one would inherit from the other. Now, all nested boxes inherit from the closest real element.
<myles> Florian: is there an observable difference?
<myles> dbaron: not to regular users
<dbaron> xidorn: what about a writing-mode change on an element with display:contents and text inside it?
<myles> astearns: we need to change the spec to match the implementations
<myles> fantasai: if you have an inline element and its the child of a block, then it's the child of the root inline of that block. If you remove that inline element, then the contents of that inline element (the text) becomes a child of the block's root inline. There's no intervening box belonging specifically to the text. Now, if we make that box go away, there's nothing that is holding the properties that apply to the text other than the root inline. The root inline'
<myles> properties apply tot he text because there's nothing between there.
<myles> fantasai: if you put an inline in between the text and the root inline, give it a property, then pull it away with display:contents, then it's not in the formatting tree. How is it contributing a color when it's gone?
<myles> TabAtkins: inheritance always follow the element tree
<myles> TabAtkins: text doesn't have properties, but it does know things like color
<myles> fantasai: we have to invent this idea of a text frame, and say that it has properties, and it's an anonymous object which you can't get rid of
<myles> TabAtkins: we kind of had to do that with selectors already.
<myles> TabAtkins: we say that clicking on raw text correctly triggers, even when there are intervening shadows & etc.
<myles> fantasai: it is already a thing, but it doesn't have properties. Now we are saying that it has its own properties.
<myles> TabAtkins: yes, to achieve what all implementations do and what makes sense
<myles> TabAtkins: display:contents shouldn't change inheritance
<myles> fantasai: background color doesn't go away when you take away the box
<myles> TabAtkins: in the example in the issue, do you think in the first bit that text should be red?
<myles> TabAtkins: where red is assigned to <section> and green is assigned to <div>
<myles> fantasai: reads really hard
<myles> fantasai: i expected div of to take the color of the section, and div span foo to take the color of the div.
<myles> TabAtkins: i disagree.
<myles> TabAtkins: i agree with the originator and what implementations do
<myles> TabAtkins: we can work through the implementations to make things well-defined
<myles> astearns: this will be difficult to specify.
<myles> fantasai: it requires inventing a new type of box in the inline layout model which we don't' have yet.
<myles> TabAtkins: putting the span in there changes how inheritance works, which changes what users see, and this is unreasonable. The present of an element shouldn't make the color jump over the div.
<myles> Florian: the consequences that a non-styled span changes things is scary.
<myles> astearns: let's table this.
<myles> fantasai: If we make a new box, it belongs in the inline layout module, not this module
<myles> TabAtkins: let's put all the boxes in display:
<myles> fantasai: but you can't create it with display:
<myles> fantasai: TabAtkins: <tries to figure out which modules this should go in>
<myles> astearns: please stop
```
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1118#issuecomment-295141872 using your GitHub account

Received on Wednesday, 19 April 2017 07:39:02 UTC