W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [css3-flexbox] Fixing the "replaced elements may or may not be inline" issue

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 25 Jun 2012 14:28:20 -0700
Message-ID: <4FE8D7F4.6000707@inkedblade.net>
To: Daniel Holbert <dholbert@mozilla.com>
CC: www-style list <www-style@w3.org>, Morten Stenshorne <mstensho@opera.com>, Alex Mogilevsky <alexmog@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
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?)

Received on Monday, 25 June 2012 21:29:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC