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

Alex Mogilevsky <alexmog@microsoft.com> writes (Wed, 20 Jun 2012 02:33:27 +0000):

> ± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] ± Sent:
> Wednesday, May 16, 2012 4:11 PM ± ± The Flexbox spec declares any
> child of a flexbox that is a block or ± inline-block (more or less - I
> won't get into the details) to be a ± flexbox item, while inline
> elements instead get wrapped into an anonymous ± item.  Unfortunately,
> replaced elements are display:inline, and may not ± even be replaced
> at all in some circumstances (Firefox renders <img> as a ±
> non-replaced inline when the image fails to load).
>
> I don't understand why this is an issue. Yes, some elements change
> from inline to replaced when content is loaded. Layout has to take
> that into account, and possibly get updated once content is loaded.

I'd also like to know why this is problematic.

Regarding:

http://wiki.csswg.org/topics/css3-flexbox-flexbox-replaced-children

First of all: None of the proposals would be considerably hard to
implement in Opera, but I must say that I'd like to keep it simple and
stupid.

I don't see how we could reasonably do B now, at least not with the
'display-inside' thing, since that property (AFAIK) is not part of any
spec yet. I also find it strange to have 'display:flex-item' in the UA
stylesheet for replaced elements, just to be able to connect the dots
for corner-case issues in a certian box model. What would the next box
model that has such a need do? A slightly off-topic analogy here: Should
the default UA stylesheet have "ul, ol { column-gap:<large enough to
keep the marker from being clipped>; }", just to satisfy exotic usage of
multicol?

Furthermore, if we introduce a display type for the items, shouldn't we
for the sake of consistency (and to avoid confusion) require that all
items be of such display type, so that:

<div style="display:flex;">
  <div id="elm">...</div>
</div>

Or:

<div style="display:flex;">
  <table id="elm">...</table>
</div>

Or:

<div style="display:flex;">
  <div id="elm" style="display:flex;">...</div>
</div>

Or:

<div style="display:flex;">
  <button id="elm">...</button>
</div>

... would all cause an anonymous 'display:flex-item' box to be wrapped
around 'elm'? Otherwise, the 'flex-item' value would really only be a
half-hearted band-aid, wouldn't it? Requiring this would of course be a
complete disaster for tables (and nested flexboxes), as they would then
never be able to become flex items.

So, in my opinion, B causes more mess than it solves.

Proposal A would be nice, if it instead could say something like
"elements whose type indicates that they are intended to be replaced"
rather than listing specific elements types (who wants to maintain such
a list?). In other words: we could modify the current spec, by removing
point 3 from http://dev.w3.org/csswg/css3-flexbox/#flex-items ("An HTML
<img>, <canvas>, ..."), and move its generic parts to point 2, by adding
something like this there: 'Any element that is "intended to be" a
replaced element, even if it becomes non-replaced (like an <object> that
doesn't load and is replaced by its contents) is considered to be
"atomic"'.

However, there's still room for confusion here. Consider the following:

<span style="content:url(some-image.jpg);"/>

If this is a child of a flex container, is it an item? No, probably not
an item if we use the above wording, but is it obvious enough and does
it make sense?

Regarding proposal C, I'm fine with that one. But I think this is what
the spec used to say back in early May, and that it's the reason why
we're having this discussion in the first place.

So if C is not an option, I like proposal D. There needs to be an
exception for absolutely positioned boxes there somehow, though?

-- 
---- Morten Stenshorne, developer, Opera Software ASA ----
---- Office: +47 23692400 ------ Mobile: +47 93440112 ----
------------------ http://www.opera.com/ -----------------

Received on Monday, 25 June 2012 12:23:31 UTC