On 06/25/2012 01:39 PM, Daniel Holbert wrote:
> 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.
If you assume that in the future, 'display: flex-item' will exist and
will be the computed value returned by any non-inline element that is
a child of a flex container, then you already have this problem. Right?
And we *are* assuming that 'display: flex-item' will exist at some
point in the future, it's just not in the spec right now (afaict because
we're unsure what to do with it outside a flex item?)
~fantasai