- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Mon, 25 Jun 2012 13:39:08 -0700
- To: www-style list <www-style@w3.org>
- CC: Morten Stenshorne <mstensho@opera.com>, Alex Mogilevsky <alexmog@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
On 06/25/2012 05:21 AM, Morten Stenshorne wrote: > Regarding: > > http://wiki.csswg.org/topics/css3-flexbox-flexbox-replaced-children I'm concerned about Proposal B as well as Proposal-A-as-it-might-be-extendable-into-Proposal-B, because of the dependence on parent-node computed style in this provision (quoting the URL above): > Introduce 'display: flex-item', which computes to > 'inline' except on the child of a 'display: flex' element Right now, when Gecko generates its internal representation of computed style, it does not necessarily have access to the parent node's computed style. (Except for inherited-by-default properties, and for properties that have explicitly received a specified value of "inherit"). I believe this lets us optimize by breaking up the style-computation work and avoid having to compute all the style at once. [waves hands... bz knows more on this. :)] However -- to honor the provision quoted above, we would in fact require access to our parent's computed "display" in order to compute the value of our own "display" property, in common cases (e.g. to compute the 'display' value of <img>, <embed>, etc.). To accommodate this, we'd have to do one of the following: (i) neuter these optimizations for the "display" property (treating it as an always-needs-to-know-the-parent-computed-style property, as if it were inherited-by-default) OR: (ii) make "display:flex-item" just compute to "flex-item" internally, and then add checks in every piece of code that uses the computed value of "display", to manually convert it to "inline" as appropriate in all of those places. I don't really like either of those strategies. :-/ I think (ii) is slightly more feasible, but it feels like a hack. (For the record, (ii) is the strategy I've used to implement "align-self:auto" -- which also depends on parent style -- but it's significantly easier for that property because it's new & its computed value is only used in a few places.) So right now, I'm tending to lean towards the "stupid but less magic" behavior that originally fell out of the spec, which I believe is Proposal C. ~Daniel
Received on Monday, 25 June 2012 20:39:39 UTC