10 years ago we, at W3C-style WG mail list, started discussion of giving CSS at least some flexibility.
That was the time of semantic Web battles that showed up in “don’t use <table> for layout purposes” witch-hunt among others. The problem was that CSS did not offer any option to vertically align stuff inside browser window and the only option to put something in the middle was (and pragmatically speaking still is) this construct:
<table width=100% height=100%>
<tr>
<td valign=middle>
… stuff in the middle of the page …
</td>
</tr>
</table>
Yet tables at that time were the only way to achieve flexible horizontal flow and grid layouts.
So idea was to add to CSS some feature that would match <table> layout power but without the need of <table> itself.
Google’s team at www-styles proposed to port existing Mozilla XUL’s <vbox>/<hbox> solution as it is.
And I proposed flex/flow model (below) that I had implemented already at that time in Sciter.
display:flex – XUL’s hbox/vbox model.
XUL’s layout model was quite foreign to CSS as it used DOM attributes to define layout properties, yet it has quite peculiar box model.
As a result 12 (sic!) new flexbox-only-properties were added to already huge CSS property namespace (200 properties and counting). All that just to make FlexBox anyhow useful.
But the biggest problem of the solution is that the flexbox breaks existing CSS box model – dimensions of elements are now defined not just by width/height properties but bunch of others like align-items and align-self.
Go figure out why “align” property shall change dimensions and why explicit height:100px declaration shall be ignored …
flow/flex – Sciter’s model
At the same time I’ve proposed flex/flow solution that I’ve implemented in Sciter (that was known as HTMLayout that time).
Basic idea is dead simple and was about adding single property flow and the flex length unit.
flex length units
The flex length unit ( width:1* or just width:* ) can be applied to pretty much any existing CSS property : width/height, margins, paddings, etc. and has very clear physical model – it is a strength of a coil attached to the particular side/part of the element.
Example: to align .child element to bottom / right side of its .parent we just need to attach two coils as top and left margins of the child:
Whenever .parent’s dimensions change, these coils will move the .child to right/bottom sides of the container.
In the same way, when we want .child to stretch and span space inside the container we can attach such coils to width/height of the .child:
Here we have coils as top/bottom margins and width of the .child. That way the .child will be replaced in the middle of the .parent vertically and span/stretch whole available space in it.
As you see this model is very intuitive and can be used without even reading the spec.
The flow property
The flow property in my proposal defines the way child elements get laid out.
The flow accepts the following values:
flow:horizontal, flow:horizontal-wrap, flow:vertical, flow:vertical-wrap, flow:row, flow:grid and others.
Where the flow:grid is essentially what display:grid offers now – grid layouts with elements spanning multiple cells.
Example: the famous “Holly Grail” layout is simply this:
main {
flow:grid(1 1 1,
2 5 3,
4 4 4);
}
main > :nth-child(5) { /*middle section */
width:*; /* coils to take all available space */
height:*;
}
and its rendering in Sciter:
As you see Sciter’s flex/flow not just covers display:flex but also display:grid cases.
And note, all that with just single CSS property and the flex unit!
The funny fact: we had off-list conversation with couple of devs from Mozilla involved in flex development, they said my variant is exactly what we needed. But who are we and what is Google?
I terribly regret not having to convince members of W3C CSS WG at that time.
So we might have flexes and grids even 10 years ago without wasting so much time on those ugly attempts to use float:left/right to achieve that should really be just flow:horizontal or flow:grid.
Mea culpa, people. Terribly sorry.
Brilliant, really. I would love to use your syntax. I was around when float was the only non-table option for layouts. Flex and grid were welcome, at least until you start to use them, and discover how forgettable the syntax of both are. These embarrassingly complex rules definitely contributed to the rise of boilerplatey CSS frameworks and utility libraries.
Perhaps complexity was a goal. Not handling more complicated layouts per-se but introducing complexity that made it harder to build a web rendering engine. With Chrome backed by Google folks being a major proponent you can imagine paid employees being fine with tackling that whereas anyone who wanted to write one in their free time would be much more hard pressed. Your syntax was just too easy to implement so it couldn’t be accepted. Still it would have been nice if the Googlites could have met their employer’s requirement to make it hard to compete with Chrome while still providing a syntax that is easy to read, write and remember, like the CSS I started out with.
> Your syntax was just too easy to implement so it couldn’t be accepted.
flex/flow (Sciter) and flexbox/grid (Chrome) have comparable implementation complexity. At the end both allow to achieve similar layouts and are implementations of LP algorithms at their core.
I suspect that the main reason of such design mistake (flexbox design) was human factor really.