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

Re: [css3-layout] shorthand for slot construction

From: Stephen Hay <haymail@gmail.com>
Date: Mon, 19 Oct 2009 15:39:07 +0200
Message-ID: <f29fb5880910190639wd13a59etce767bad13042b93@mail.gmail.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
Cc: news@terrainformatica.com, Www-style <www-style@w3.org>
On Mon, Oct 19, 2009 at 2:15 PM, Giovanni Campagna
<scampa.giovanni@gmail.com> wrote:
> 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.

I think Andrew's point is that proper layout tools could avoid these
types of problems.

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

The way CSS tables are specified now, that's simply peanut butter in
chocolate as opposed to chocolate in peanut butter. CSS tables are
*meant* for tables in the tabular data sense, are they not? If I
understand you correctly, you're proposing extending them to
accommodate the demands of page layout? If CSS tables already do what
they're supposed to for tables, why extend the meaning, and why not
simply create a separate model (which css3-layout seems to be) for a
page/element layout framework?

>> 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 13:39:42 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:40 UTC