Re: Positioned Layout proposal

This is a reply to a thread from October, wherein I will now attempt to
address the main problems raised:

http://lists.w3.org/Archives/Public/www-style/2010Oct/0334.html

I would appreciate reading any thoughts on this? I will probably go quiet
again and respond much later.

Cyclically insoluble relatively positioned element reference contraints
can be prevented by:

1) Each relatively positioned element may be positioned to any other
element, but that element must have been previously declared. Others had
mentioned this, and I believe Tab added it to his specification.

2) Not positioning an element relative to more than one element.

The following elements are declared in alphabetical order.

Here is ascii art illustrating what #1 prevents (A can't be simultaneously
left and right of C):

A <- B <- C <-+
|_____________|

Here is ascii art illustrating what #2 prevents (A and B can't be
simultaneously left and right of each other):

A <- C -> B
B <- D -> A

Note #1 prevents the circular constraints collisions mentioned by "Belov,
Charles":

http://lists.w3.org/Archives/Public/www-style/2010Oct/0337.html

Note #2 prevents the hierarchal and implicit constraints collisions
mentioned by "Robert O'Callahan":

http://lists.w3.org/Archives/Public/www-style/2010Oct/0359.html


============================================================

The above #2 restriction prevents the generalization of more than one row
or column of a table (and prevents row and column spans).

A single row or column can be constructed by positioning 3 sides of each
element relative to a prior one in the table. The concept of a row is
formed by snapping together (with some optional spacing) the top and
bottom edges, and juxtaposing the left and right edges. Conversely for a
column. Note this enables subsequent elements to control the size (height
for row, width for column) of prior elements, but this is not cyclically
insoluble. There is no way to tie rows together without positioning the
elements simultaneously as columns (or vice versa to tie columns
together), which requires relatively positioning to 2 elements
simultaneously.

The above #2 restriction prevents the generalization of inline layout,
because each inline element needs to be positioned relative to the prior
one (with additional edge choices for baseline, etc), and simultaneously
the topmost top edge of the row (aka 'line') has to be relatively
positioned (vertically aligned) to the parent container or prior row. Note
wrapping would be handled by an orthogonal declaration that overrides the
default relative position, because wrapping is not modeled with relative
element positioning.

Removing the #2 restriction would create the potential maximum entropy
computional complexity in the search for insoluble constraints (as well in
enforcing the soluble constraints) that Boriz Zbarsky warned about:

http://lists.w3.org/Archives/Public/www-style/2010Oct/0493.html

Computational complexity is reduced in CSS by using explicit constructs
for row positioning for tables and inline layout. I had expected this is
the solution to common use cases for reducing the potential maximum
entropy:

http://lists.w3.org/Archives/Public/www-style/2010Oct/0491.html

We could relax the #2 restriction for common use cases (e.g. tables) and
potentially detect them algorithmically to reduce computational
complexity, but I do not see benefit since this eliminates the semantic
benefit (designer intention of a table explicit in the code) of declaring
with an explicit table construct.

We could relax the #2 restriction (not my recommendation), so the designer
has general flexibility and just let the designer avoid very slow page
rendering if they exceed the computational complexity they find tolerable
for their audiences. It might help to show a warning in this case, so the
cause is known and to suggest not relatively positioning to more than one
element.

It seems with the #2 restriction, most of the prior mentioned valid use
cases could be achieved. For example, positioning of tooltips and other
popups/menus, corner treatment, etc..

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?  Seems multicol needs an integer
setting for column-span.

http://lists.w3.org/Archives/Public/www-style/2010Oct/0334.html
http://dev.w3.org/csswg/css3-multicol/#column-span

If yes, that illustrates the power of orthogonal specification (separation
of concerns)[1] and Principle of Least Power (which favors keeping the #2
restriction).


============================================================

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.

I haven't yet tried very much to wrap my mind around the complexity of
layout without the #2 restriction. As previously stated, there would be
computational complexity cost in the search for the insoluble error cases.
I guess still build a list of mutually dependent box sizes, but a much
higher risk of domino effect oscillation in the optimization of minimizing
overflow and page width.


============================================================

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

Received on Thursday, 23 December 2010 13:12:48 UTC