Re: Positioned Layout proposal

[snip]
> Am I correct to think that Tab Atkins ragged table could be achieved by
> combining multicol (using explicit column breaks) with this relative
> positioning to create and align the rows?

Considering the way CSS works, issues below and others, the relatively
positioned element must be removed from the normal (inline) flow.

Afaics, the ragged column and row is best handled as an extension to
table, with a fractional rowspan and colspan. Fractional colspan will
complicate the table layout algorithm's aportionment of proportional
space.

[snip]
> ============================================================
>
> With the #2 restriction, the layout algorithm seems (in my limited
> experience with implementation) reasonably simple to express. Assuming the
> inline direction is left-to-right and block direction is top-to-bottom
> (otherwise swap "top, left" for "bottom, right"), then when there only
> relative positioning on the top, left edges of the element being
> positioned, thus allows laying out the elements in the order of
> declaration. For bottom, right edge cases, if the top, left edges are also
> relatively positioned (respectively), then the height, width
> (respectively) of the relatively positioned elements are mutual dependent.
> So just as with table rows and columns, you need a list of these and must
> factor this into the optimization of minimizing overflow and page width
> (e.g. inline wrapping). Other than the case where the width and height of
> an element are simultaneously mutually dependent (which with #2, seems to
> be a degenerate unlikely use case, maybe we could even disallow it) where
> changing width changes wrapping of inline content and changes the height,
> I can not think of any domino effect that could cause oscillation.

Table layout algorithms minimize overflow, and maximize the table
dimension (proportioning columns heuristically), in the inline direction:

http://w3m.sourceforge.net/STORY
http://www.ietf.org/rfc/rfc1942.txt (see page 23)
http://mxr.mozilla.org/mozilla-central/source/layout/tables/

Issues with positioned layout proposal:

1. Intrinsically sized elements that are juxtaposed (regardless of
spacing) in the inline direction need to apply table layout algorithm,
regardless if the sizes of the elements are (relatively declared to be)
mutually dependent. Perhaps this requirement is why relative positioning
does not already support bottom and/or right edge?

2. I currently don't see any use cases for mutually dependent element size
(width and/or height). The only use cases I see are extending CSS's
current relative positioning to arbtrary elements (probably also to the
viewport), and adding bottom and right (maybe even text alignment)
targets.

[snip]
> ============================================================
>
> As far as I understand so far in my study, the relative positioning of
> elements (and to viewport) is orthogonal[1] to the model and goal of
> flexible box space layout proposals. The size and positioning for the flex
> container to the viewport edges should be orthogonal to the flex box
> specification, as it is in the model of relative positioning (and size can
> be implied by relative positioning, e.g. the viewport edges). Flex box
> space's unique model and focus is to apportion space (yielded by the
> inflexible constraints) within a box with proportional ("flex") units.
>
> [1] http://lists.w3.org/Archives/Public/www-style/2010Oct/0563.html

Generally speaking, I take issue with the following stated design philosophy:

http://www.ietf.org/rfc/rfc1942.txt (see page 5)

   "For tables, the alignment of text within table cells, and the borders
   between cells are, from the purist's point of view, rendering
   information. In practice, though, it is useful to group these with
   the structural information, as these features are highly portable
   from one application to the next."

I am contemplating if the tsuris I regularly experience (every time I make
a website) with CSS's conflation of concerns (and thus special cases and
layout results which deviates from simplistic expectation of designer,
i.e. quirky) to far outweigh the cost of forcing conflated designs in
other applications to be lossy (not bijective) on interoption. It could be
that I am designing in quirks mode, or encountering browser bugs, but my
comprehension thus far is that it is fundamental.

Until further study illuminates to me otherwise (which is entirely
possible given I am not experienced in the specific interoption cases for
tables), I wish table layout declaration was orthogonal to alignment,
margin, padding, etc.. For example, that table spacing could be
accomplished with a margin rule shared by all cell elements, ditto
padding. Thus re-using the orthogonal element margin and padding. Afaik,
intra-cell alignment is orthogonal to computation of table layout
dimensions and could thus be handled within the cell element. I don't see
why table cells have to be <td>, why couldn't they be any block element?

K.I.S.S., Modularity, and Principle of Least Power are stated design
objectives of the W3C:

http://www.w3.org/DesignIssues/Principles.html

Received on Friday, 24 December 2010 13:29:13 UTC