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: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Tue, 26 Jun 2012 21:11:23 +0800
Message-ID: <4FE9B4FB.4090208@csail.mit.edu>
To: Anton Prowse <prowse@moonhenge.net>
CC: WWW Style <www-style@w3.org>, Morten Stenshorne <mstensho@opera.com>, Alex Mogilevsky <alexmog@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
(12/06/26 14:41), Anton Prowse wrote:
> On 25/06/2012 14:21, Morten Stenshorne wrote:
>> 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.
> 
> The trouble with C, as fantasai points out in [1], is that two adjacent
> inline images which fail to load will have their alt text glommed
> together into one (anonymous) flex item.  

This is under the assumption that for <img>s that don't load, they would
be rendered as non-replaced elements. Even if that behavior is what's
currently in the HTML spec, given that only Firefox does this, I wonder
if this is for sure a valid concern.

Also, the text in the HTML spec is

  # When an img element represents some text and the user agent does
  # not expect this to change, the element is expected to be treated as
  # a non-replaced phrasing element whose content is the text,
  # optionally with an icon indicating that an image is missing.

which is also a bit confusing to me. How can a non-replaced element
render an extra icon?

But anyway, there are always some more proposals for this kind
particular concern at the HTML side. Say,

Proposal E: An <img> is always rendered as replaced element, no matter
whether the image is loadable.

Proposal E': An <img> with a 'width'/'height' attribute is always
rendered as replaced element, no matter whether the image is loadable.

> This seems pretty user-unfriendly.

Here "user" you mean an author or a user?

> The only reason we're trying to do magic here is to account for the
> fact that apparently authors aren't going to figure out that their
> buttons etc need to be set to display:inline-block; yet if they're
> not going to figure that out then I'm doubtful they're going to think
> particularly deeply about how to play safe in the case that images
> don't load. Hence C is a footgun,

I don't think so. Beyond Firefox's behavior, this concern seems to be
under more assumptions:

* Authors use <img>s directly inside an element with 'display: flex;'
* The <img>s fail to load
* Authors don't bother to test situations when <img>s fails to load
  or authors forever can't get the display:inline-block trick
* For two <img>s that failed to load, having them merge into a single
flexitem is worse than having two separate flexitems.

I am particularly not sure about the last one. If some <img>s fail to
load in a Web page, that seems to have great impact to the design of the
page already. Making sure that UA displays two separate flexitems in
this situation doens't seem to be of big importance.

> and the resulting guru recommendation for authors is likely to be to
> do something like
> 
> #div {display:flexbox}
> #div > * {display:inline-block}
> 
> which is presumably what we're trying to avoid by having this discussion
> at all.  (Note that that recommendation is effectively an implementation
> of Proposal D.)
> 
>> So if C is not an option, I like proposal D. There needs to be an
>> exception for absolutely positioned boxes there somehow, though?
> 
> Unexpectedly, I'm now coming around to proposal D as well.  It's not
> that I don't like B – I think we'll have to introduce it in future in
> any case – it's just that I think it's too early for it.

I don't think it's a good idea to disable the author-friendly
optimization for the <button> in a flex container case, which seems to
be a lot more common than the concern above, which is, as I said, under
too many assumptions.


Cheers,
Kenny
Received on Tuesday, 26 June 2012 13:11:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:55 GMT