W3C home > Mailing lists > Public > www-style@w3.org > December 2007

some comments on the Advanced Layout draft

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 19 Dec 2007 12:20:26 +1300
Message-ID: <11e306600712181520n25cda9eehf743addb40daa922@mail.gmail.com>
To: www-style@w3.org
http://www.w3.org/TR/2007/WD-css3-layout-20070809/

I was just reading over the draft and overall I like it, although I'll have
to think about it some more and no doubt there are issues that will only
become apparent when trying to implement it.

Comments:
* 3.2ff: Clarify whether we're talking about content widths, margin-box
widths, etc
* 3.3: Does an efficient algorithm exist to compute the heights? It's
clearly a linear programming problem, but that only means a poly-time
algorithm exists (and a very hard algorithm at that). It's not a fully
general LP problem but I don't see how to exploit the structure. If an
efficient algorithm does exist it would very useful to give it as
informative text.
* 3.2, 3.3: What effect do min/max width/height on elements in slots have on
the layout?
* 3.4: How are elements placed in the same slot laid out together? Do their
margins collapse? Do multiple display:table-cell elements combine to form a
single table? Do display:inline elements get put in the same line? Etc.
* In example VIII, where are the dimensions of the whitespace coming from?
* 3.5 should not talk about padding of elements. Either talk about the
positioning of elements or possibly padding of the slot.
* Pagination: Should an element template not at the top of a page prefer to
move to the next page
instead of breaking?
* What is the default stacking order in the absence of z-index? Document
content order, or
order according to the template?
* It seems that adding min/max width/height to ::slot pseudos would greatly
complicate
layout.
* I don't like the other approaches in section 3.11. rowspans and colspans
seem harder
to author and create more error cases.
* Tabbed displays could be a separate module. Templates are big enough for
their own module.

Comparing templates to XUL-style flexbox is interesting. It would be nice if
they could be unified in some way. The features that seem missing from
templates:
-- Handling variable number of children
-- Direction reversal
-- Variable flex
-- Flexbox can give each element its intrinsic width/height and then
distribute leftover space (weighted by flex) to each element. These
templates can't do that.

Advantages of templates over flexbox:
-- A template element can control the layout of descendants deeper than its
immediate children; this may be particularly useful for graceful degradation
when templates aren't available
-- Less need to build complex markup nesting
-- Can express some things that flexbox can't, e.g. things Mozilla uses XUL
<grid> for

Maybe flexbox and templates could be combined. E.g., add "display:flexbox",
which combined with the the box-orient, box-pack and box-direction
properties creates a template with one slot for each child element, e.g.
"abcdef" or "fedcba" or the equivalent vertical template, with
"position:a/b/c/..." implicitly assigned to each child element. box-pack
would add flexible whitespace to one or both ends of the template. Add
"box-flex" which would allow any element in a template slot to control
flexing in any template.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]
Received on Tuesday, 18 December 2007 23:20:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:57 GMT