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

On 26/06/2012 15:11, Kang-Hao (Kenny) Lu wrote:
> (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.

Firefox's behaviour is the only one that makes sense, as Boris describes 
later in this thread.

>> This seems pretty user-unfriendly.
>
> Here "user" you mean an author or a user?

User.  Authors are unlikely to even realize what they've done, which is 
why user concerns are of importance in this topic.

>> 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;'

I think this is quite likely for toolbar etc, although I accept that 
that's only one of several use cases.

> * The <img>s fail to load

Yes, it's not the typical situation.  But then again, neither are many 
things that fall to accessibility.

> * Authors don't bother to test situations when <img>s fails to load

I defer to Boris ;-)

>    or authors forever can't get the display:inline-block trick

But that's what we're assuming in this whole thread, right?  Else there 
was no need to change the spec from what it was a while ago.  Proposal C 
would be good enough.

> * 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.

But equally, nor does /not/ doing that.  In the grand scheme of things, 
this discussion isn't that important, no.  But if we're bothering to 
address the issue at all, we might as well aim for best possible, right?

>> 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.

Proposal D doesn't disable that (assuming we're talking about the same 
thing, namely that authors want to dump buttons into flexbox containers 
without changing their display type).  I wouldn't be supporting it if it 
did!

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Tuesday, 26 June 2012 16:18:04 UTC