Closed Bug 756671 Opened 8 years ago Closed 7 years ago

Add way of checking for elements that are "intended to be replaced", at frame-construction-time

Categories

(Core :: CSS Parsing and Computation, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: dholbert, Unassigned)

References

()

Details

See this www-style post: http://lists.w3.org/Archives/Public/www-style/2012May/0558.html

Basically, the flexbox spec wants elements like <img> to _always_ become their own flex items (when inside of a flex container), regardless of whether they end up being replaced.

(Previously, this behavior depended primarily on whether the <img> was "atomic" which in turn depended on whether it was replaced.)

http://dev.w3.org/csswg/css3-flexbox/#flex-items has a list of elements that would be affected.

One strategy that was proposed for achieving this was to use a hidden property (e.g. "-moz-should-always-be-flex-item)", which defaults to "false" but which we would manually set to "true" in our UA stylesheet on the elements in question.  And then we'd check that property when determining how to build frames for the element.

(not sure if there's a better way)
I was going to say we could put this in the fcdata, but I guess the point is that <img> should become a flex item even when it falls back to alt text (at which point it no longer uses the image fcdata), right?
Yeah, in that case either a new prop with rules in ua.css or just a hardcoded list in C++ is the way to go.  Note that the latter would work fine modulo needing to walk the list, since we do have the element in the fcitem.
Hmm, good point -- hardcoded list in C++ is probably faster and has less fallout. (We also only need to scan that list if our parent is a flexbox container, so this strategy wouldn't have any perf impact on non-flexbox contexts.)
Summary: Add an internal property for elements that are "intended to be replaced" → Add way of checking for elements that are "intended to be replaced", at frame-construction-time
Right.  And we only need to scan it if our display is inline, which should be a rare case anyway.
This is actually slightly more complicated than I initially thought -- I don't think a naked inline frame (for a non-replaced <object> or <img> element) will work correctly as a child of a flexbox, unless we give it a block formatting context.

(By "will work correctly" I mean "will do linewrapping, honor height/width properties, etc")

I just asked about this on www-style:
  http://lists.w3.org/Archives/Public/www-style/2012May/0747.html
The element's effective 'display' type changes when it's a child of a flex container: it's now 'display-outside: flex-item; display-inside: block' (i.e. 'display: flex-item'). Except we don't have a 'display' value that means that yet, so for layout we pretend we have one, and for its computed value return the appropriate display value from the table in CSS 2.1 Chapter 9.7.
In other words, if the parent of one of these elements is a flex container, it is no longer 'display: inline' in any sense. It's equivalent to having had specified 'display: block'.
(In reply to fantasai from comment #8)
> It's equivalent to having had specified 'display: block'.

...but getComputedStyle("display") would still return "inline", right?  (just want to be clear)
(for now, I mean -- until we have display-inside / display-outside / "flex-item" as a display value)
No, it would return 'display: block'; see the last sentence in http://dev.w3.org/csswg/css3-flexbox/#flex-items :

  # The computed value for ‘display’ for elements that are flex items must be determined
  # by applying the table in CSS 2.1 Chapter 9.7.
Ah, sorry -- I completely missed that new chunk in the flexbox spec (probably because it was added below the large [example] section) :).

So flexbox items are now always converted inline-table --> table, inline --> block, etc.  Cool, that resolves Comment 6.
(In reply to Daniel Holbert [:dholbert] from comment #12)
> So flexbox items are now always converted inline-table --> table, inline -->
> block, etc.  Cool, that resolves Comment 6.

...though to prevent ourselves from applying this to <span> / <i> / etc, we'll need to be able to distinguish the "non-replaced-ish" elements from the "replaced-ish" elements, from within the style system, so that we can actually compute their style correctly.

This means we'll likely need to actually use an extra property route (instead of just using a hardcoded list-of-tagnames somewhere).  Otherwise, we won't be able to distinguish these two types of elements from inside the style system when we're trying to compute their 'display' property.
I'd suggest going the extra property value route, and implement display: -moz-flex-item or somesuch as described here:
  http://lists.w3.org/Archives/Public/www-style/2012May/0564.html
and just have it compute to 'block' instead of 'flex-item' on flex items for now.
I'm resolving this bug as INVALID, since the flexbox spec has changed again (a little while back) to remove the "intended to be replaced" stuff.  (Now, it says _all_ child nodes of a flex container (not just "intended to be replaced" ones) are supposed to have their "display" values blockified, along the lines of comment 7.  I filed a fresh bug (bug 783415) on doing that.)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.