- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Wed, 19 Feb 2014 14:15:03 -0800
- To: Andrew Fedoniouk <news@terrainformatica.com>
- CC: "Tab Atkins Jr." <jackalmage@gmail.com>, Eric Eastwood <me@ericeastwood.com>, www-style list <www-style@w3.org>
On 02/19/2014 01:48 PM, Andrew Fedoniouk wrote:
>> On Tue, Feb 18, 2014 at 6:29 PM, Andrew Fedoniouk
>> <news@terrainformatica.com> wrote:
>>> According to this document http://www.w3.org/TR/CSS2/sample.html
>>> (non-normative I believe though) <button> and <input> are
>>> *inline-block* elements. And Eric was asking about purely display:inline
>>> elements that do not generate boxes by themselves.
[...]
> I see this:
>
> button, textarea,
> input, select { display: inline-block }
>
> in http://www.w3.org/TR/CSS21/sample.html
So, let's set those elements' display values aside for the moment.
Even if we specifically targeted "display:inline" (not inline-block) and
thereby avoided changing behavior for button/input, we'd still break
<img>, because it's definitely "display:inline" by default, at least in
Firefox/Gecko, Opera/Presto and Chrome/Blink. [the browsers/engines I
have available locally to test]
(From briefly searching, I couldn't find any spec text saying that <img>
should be display:inline by default, but it seems that browsers have
converged on that behavior (probably long ago), and that's not likely to
change.)
So the suggested change would still break any existing content that has
<img> as a flex item, even if it wouldn't break <input>/<button>/etc.
> When you apply flexbox on span's container that span gets
> treated as boxed element loosing its display:inline nature.
>
> Check this,
> [sample code omitted]
> two divs here should be rendered in the same way.
> That's what Eric was asking about I believe.
Yes, Tab already recognized and responded to that; see his first reply
on this thread:
http://lists.w3.org/Archives/Public/www-style/2014Feb/0565.html
~Daniel
Received on Wednesday, 19 February 2014 22:15:30 UTC