W3C home > Mailing lists > Public > www-style@w3.org > September 2011

RE: [css3-flexbox] & others: resolution for the display:inline-* proliferation

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Sat, 24 Sep 2011 00:28:15 +0000
To: Nicholas Shanks <contact@nickshanks.com>, "www-style@w3.org" <www-style@w3.org>
CC: Tab Atkins Jr. <jackalmage@gmail.com>, "L. David Baron" <dbaron@dbaron.org>
Message-ID: <D51C9E849DDD0D4EA38C2E5398569284121369A0@TK5EX14MBXC213.redmond.corp.microsoft.com>
This sounds very similar to display-inside/display-outside proposal. If "flow" here was replaced with "display-outside" we would get the same result. 

The difference in this proposal is to not allow control of "display-inside" without also setting "display-outside" to some value, potentially to be overridden by separate property "flow". It doesn't look like an advantage to me.

The reason display-inside/display-outside is not formally defined yet is not because we disagree on the value of the separation, but because we need a detailed proposal that works through interactions of these separate properties with existing features and addresses alternatives suggested on this list (including this one)...

I believe writing it up is on Tab's list of things to do, notably lower than specs that will have more dramatic effect when implemented.

Alex 

-----Original Message-----
From: nickshanks@gmail.com [mailto:nickshanks@gmail.com] On Behalf Of Nicholas Shanks
Sent: Friday, September 23, 2011 6:51 AM
To: www-style@w3.org
Cc: Tab Atkins Jr.; Alex Mogilevsky; L. David Baron
Subject: [css3-flexbox] & others: resolution for the display:inline-* proliferation

I note that the current flexbox spec states:


ISSUE: The proliferation of "inline-*" display values is untenable and restrictive. Table cells should be able to use the flexbox layout mode for their contents, for example, rather than being forced to use block layout. It's expected that this will be fixed by splitting the ‘display’ property into subproperties controlling how the element formats its contents (‘display-inside’) and how it reacts to its surroundings (‘display-outside’). [snip]


I think a better approach would be a single new property, flow, which has the values "block", "inline", and "none", and would act like the suggested "display-outside" property, in that it would only affect how the element is treated in document flow relative to it's siblings and ancestors. The existing display property would act like the above suggested "display-inside" for UAs supporting "flow", and would thus remain both forwards and backwards compatible. I think this is a better solution than introducing two new properties and making "display" a shorthand for them both.

UAs supporting "flow" would implicitly set an initial value of "inline" for all inline-level elements, as well as any elements or generated content set to display:inline(-*) by CSS. Elements with position:fixed, position:absolute, display:none and visibility:collapse (did I forget anything?) would get an initial value of flow:none. Everything else would get 'block'. This means that the initial value can only be computed after the final computed value of 'display' is available, which may or may not be difficult for UAs.
This initial value gets overridden by author CSS as would any other property (so computing it may not be necessary anyway).

Going forward, new display values would not need to specify "inline-*"
versions of themselves, but instead require that the flow property is supported.

div.class1 { /* current syntax */
    display: inline-table;
}
div.class2 { /* optional (explicit) transitional syntax for existing
inline-* values */
    display: inline-table;
    flow: inline;
}
div.class3 { /* syntax for display values not yet imagined, and hypothetically when all deployed UAs support flow (e.g. intranet) */
    display: table;
    flow: inline;
}
div.class4 { /* deliberate author divergence for UAs supporting flow and those not doing so */
    display: inline-table;
    flow: block;
}

Now that the flow property is established, the second step in the process is to permit the flex-* properties and flex() function to be applied to any and all elements without requiring their display property to have a certain value.

for example, the flex functions here:

table {
    width: 100%;
}
td:nth-child(odd) {
    width: flex(2);
}
td:nth-child(even) {
    width: flex(1);
}

would still make the cells flexible, despite the tr having a display value of table-row, and would be equivalent to the width attributes of the following HTML 4 markup:

<table width="100%"><col width="2*"><col width="*"><tr><td><td></table>

--
Nicholas.

Received on Saturday, 24 September 2011 00:28:45 GMT

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