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: Daniel Holbert <dholbert@mozilla.com>
Date: Mon, 25 Jun 2012 13:39:08 -0700
Message-ID: <4FE8CC6C.2050400@mozilla.com>
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)


  (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

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.

Received on Monday, 25 June 2012 20:39:39 UTC

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