W3C home > Mailing lists > Public > www-style@w3.org > October 2009

Re: [css3-layout] shorthand for slot construction

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Mon, 19 Oct 2009 14:15:41 +0200
Message-ID: <65307430910190515t4b922dfbq1a9736497babb3ea@mail.gmail.com>
To: news@terrainformatica.com
Cc: Stephen Hay <haymail@gmail.com>, Www-style <www-style@w3.org>
2009/10/19 Andrew Fedoniouk <news@terrainformatica.com>:
> Giovanni Campagna wrote:
>>
>> 2009/10/18 Stephen Hay <haymail@gmail.com>:
>>>
>>> On Sun, Oct 18, 2009 at 8:48 PM, Giovanni Campagna
>>> <scampa.giovanni@gmail.com> wrote:
>>>
>>>> This also means that strange flex units are not really needed, you
>>>> just go with percentages on width, height + min-width / min-height.
>>>> Actually, this would make the whole ascii art concept a bit less
>>>> useful (since you need to set the [min-/max-]width, [min-/max-]height
>>>> on the ::slot()). We could go back to the @template syntax in the 2007
>>>> version of css3-layout.
>>>
>>> From a designer's perspective, almost all layout grids (I mean
>>> traditional layout grids, not css3-grid) are very explicit, and
>>> percentages will be good enough for most flexibility. For those rare
>>> instances where they aren't, min/max on the ::slot() shouldn't be a
>>> problem.
>>>
>>> Why was @template changed?
>>
>> Actually, they first invented display:"abc" "ade", then they thought
>> of @template, now they dropped it...
>>
>>>> In conclusion, my opinion is go tables, go absolute positioning, go
>>>> percentages and go syntax sugar. New layout systems and algorithms are
>>>> not that needed, not in the 2009 world of full CSS2 support.
>>>
>>> Right now there is still no actual grid layout system, as tables are
>>> not grids, although they share certain characteristics.
>>
>> Why are they not? Or better, what do you mean by "grid layout system"?
>> To me a "grid" is just a set of vertical and horizontal offsets (the
>> grid lines), at which you snap objects through some other layout
>> system (absolute positioning)
>
> That is sort of oxymoron statement in my opinion.
>
> Absolute positioning by its definition is flow-less (or manual if you wish)
> positioning schema. When you define some layout management for
> elements involved then then they are not position:absolute anymore but
> rather position:static when that static position is determined by
> the layout manager[1] (e.g. flow:vertical for normal <div>s or flow:table
> for rows and cells). So it is not clear what you mean.

Ok I should not have used layout manager. Let's use "layout algorithm"
for the purposes of discussion, and let it be "a sequence of
computations for displacing an element's box"
Absolute positioning does exactly that (finding the used values of top
/ left / bottom / right, mixing with height and width and obtaining
the place for the box), not differently than position:static.

Actually, the way CSS defines this (using "display" and "position") is
complicated, because you mix the layout algorithm for the element and
the layout algorithm for children, and because the current layout
managers treat absolutely positioned elements differently than static
/ relative positioned ones. As an aside, positioning an element has
side effects like getting a pseudo-stacking context.

You can say that "position:static" means "use the position given by my
layout manager (table, BFC, IFC)", while "position:absolute" means
"use the position the author set explicitly".
A property / value like "display-role:block-out-of-flow" would make
more sense theoretically for absolutely positioned elements (but would
be useless), reducing the CSS layout system to:

display-role: define how the layout manager will treat this
display-model: define what layout manager will this element use for
its children (if it's a layout manager)
position: define what to do with what the layout manager say about this element
float: in a BFC layout manager, select what flow (sequence of boxes)
to use. In other layout managers it should either not apply or infer
the right amount of anonymous boxes to keep display-role, but this is
historical)

> Main difference of static from absolute positioning is that the first
> one is flexible/scalable in the sense that if content in one static
> element changes its dimensions then correspondent layout manager will
> adjust positions and dimensions of other elements that it manages so
> information presented to the human can be seen in full.

That depends on the layout manager, actually. Ok, it holds for what
CSS currently supports, but it could change (for example if we want to
support flexible lengths for vertical grids in some author-friendly
way), and anyway, the layout manager will change the static position
of all its children, just some of them will ignore it.

> In principle position:absolute and float:left|right (when it used
> for simulating flow:horizontal) should be used as an exception but
> not as a rule. Remember tons of UI bugs when the same absolute positioned
> system of elements used for presenting information in different locales
> (different length of strings in different languages). That is all about
> absolute positioning. And those percentage length units ...

Bugs are not relevant to this discussion, we're talking about what FF5
or Opera 12 will support, not IE 6 or Konqueror 3, and of course using
display:table-cell works better if you need a three column liquid
layout.

> It's a pity that in 21st century CSS has nothing for authors to make
> their design more stable to changing locales, font sizes, etc. Designers are
> forced to use other tools (like absolutes, floats and that ugly
> display:cell) that are not suitable for robust designs at all.

Why are they not? Just they have different uses.

> Take a look on today's W3 front page in this resolution:
> http://www.terrainformatica.com/w3/w3-nw.png
> Note that thing on the left sidebar that is barely readable and
> items in <ul class="main_nav"> are gone completely.
> So if W3C cannot do robust layouts then who can ?!

One who can design for Safari 6, Chrome 4 or IE10 for example. The W3C
is constrained by current browser support.

> [1] http://en.wikipedia.org/wiki/Layout_manager
>
>>> While I see your point, I think we still need one grid layout system.
>>> My opinion is that we should take whatever is necessary from flexbox
>>> and css3-grid (only the 'gr' unit IMO), add them to template layout,
>>> and keep that as a grid layout system. So then:
>>>
>>> Template layout = grid layout system
>>> Positioning = position things on and within the grid
>>> Floats = float things within the grid
>>> Table layout = for laying out tables :)
>>
>> The point is: what is template that cannot be done with tables and
>> content adjusting?
>
> So we will end up in recommending authors to use tables for
> layout purposes, eh?

Yeah, of course. The important part is: use tables, not <table>.

> And what is that "content adjusting"?

Changing the source document to achieve a particular layout, dropping
semantics, adding more container elements, breaking logical order.

Giovanni
Received on Monday, 19 October 2009 12:16:22 GMT

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