Re: [csswg-drafts] [css-display] More precise box transformations

The Working Group just discussed `Defining box ↔ element style correspondence`, and agreed to the following resolutions:

* `RESOLVED: Accept change set https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3`
* `RESOLVED: Add the appendix https://drafts.csswg.org/css-display-3/#box-guidelines to Display 3`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael_> Topic: Defining box ↔ element style correspondence<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/1643#issuecomment-374414522<br>
&lt;dael_> Github: https://github.com/w3c/csswg-drafts/issues/1643<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3<br>
&lt;dael_> fantasai: We got two issues out of the one filed. First is that it's not defined that the things that apply to and element apply to a box. We tightent hat in this change set ^<br>
&lt;dael_> fantasai: That's the first issue.<br>
&lt;dael_> florian: Is it a one to one corrispondance?<br>
&lt;dael_> fantasai: No because some apply to principle box and some to others. On a table some are to wrapper box and some to table. So we said computed value to the box to which it applies.<br>
&lt;dael_> astearns: Quick read from me seems like that change is good.<br>
&lt;dael_> astearns: It's really expanding on the sort sentence we had.<br>
&lt;dael_> fantasai: Yes.<br>
&lt;dael_> astearns: Objections to this change?<br>
&lt;dael_> RESOLVED: Accept change set https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3<br>
&lt;dael_> florian: Question, you're saying inherited prop inherit through box tree. Does that do strange when some boxes are surpressed?<br>
&lt;dael_> fantasai: I don't htink so. When they're surpressed they're not in the box tree.<br>
&lt;dael_> fantasai: I don't know of a ase when an element generates two boxes where one is the child then the other and there's a surpressed box between.<br>
&lt;dael_> florian: So children of display:none has no inheritence?<br>
&lt;dael_> fantasai: Inheritence happens in the element tree. Before and after boxes inherit. Anon boxes inherit. First you do the cascade, then inheritencec, then you get prop for every element in the tree.<br>
&lt;dael_> florian: Sentence i"m reacting to is a clarification, not a requirement. It's not clear that's what was meant. It confused me.<br>
&lt;dael_> fantasai: Sentence says [reads]. So I don't know where you'll get a problem.<br>
&lt;dael_> florian: If you think enough there's only one explination and it's the sane one.<br>
&lt;fantasai> + In general, &lt;a>inherited properties&lt;/a> are assigned to the &lt;a>principal box&lt;/a>,<br>
&lt;fantasai> + and then inherit through the box tree<br>
&lt;fantasai> + to any other boxes generated by the same element.<br>
&lt;dael_> astearns: If you can come up with something clearer feel free to make a PR<br>
&lt;dael_> florian: This is fine.<br>
&lt;dael_> astearns: Second change?<br>
&lt;dael_> fantasai: Second it was asking for guidance on box tree construction. We added an appendix.<br>
&lt;fantasai> https://drafts.csswg.org/css-display-3/#box-guidelines<br>
&lt;dael_> fantasai: It has four bullet points of things you need to define if you're writing a spec that changes boxes.<br>
&lt;dael_> astearns: Looks fine to me.<br>
&lt;dael_> florian: That's useful.<br>
&lt;dael_> astearns: Objections to adding this appendix to display 3?<br>
&lt;dael_> RESOLVED: Add the appendix https://drafts.csswg.org/css-display-3/#box-guidelines to Display 3<br>
&lt;dael_> fantasai: That's if for this issue.  There was a grumble about 2.1 termonology.<br>
</details>


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

Received on Wednesday, 4 April 2018 23:27:11 UTC