RE: Positioned Layout proposal

Apologies for jumping in late. I have not yet read through the entire thread.

I will generalize this model to generalize and supercede the proposed
Flex-Layout[1]:

[1] http://lists.w3.org/Archives/Public/www-style/2010Oct/0276.html
http://www.terrainformatica.com/w3/flex-layout/flex-layout.htm

For a decade, I've wanted some way in HTML+CSS to position relative to the
right or bottom of the siblings and/or parent hierarchy container, if at
least for the simple use case of positioning elements at the bottom of the
viewport (which won't scroll away). I estimate that a majority of others
have too. That part is probably realistic.

The extra positioning constraints relative to siblings and/or parent
hierarchy container seem realistic, e.g. don't clip the viewport, and
please include 2D centering.

However, the Principal of Least Power applies to your proposed element().

Afaics, the arbitrary element() proposal will introduce circular
constraint cases that are unsolvable or become too complex for the layout
engine to solve in real-time, because these new edge constraints will
co-exist in arbitrary orders with respect to hierarchal constraints, e.g.
tables, columns, or float. This will be perhaps analogous to injecting
garbage collection search algorithms, but not searching just reference
ancestry, rather searching on complex dynamic relationships of layout
constraints, i.e. N-dimensional differential equations relations. I didn't
try too much yet wrap my mind around the general mathematical model.

Good news is that looking at Tab's main example use case (and the quickly
scanned other use cases), afaics the element() can be restricted to
non-float siblings (which are not table col or row elements), which afaics
will eliminate the problem of the prior paragraph.

> "When specifying which edge an element positions itself relative to,
> it's possible to create cycles, where following the chain of references
> from one element eventually leads back to the same element.

Agred even with the restriction of element() I made above, there are still
circular unsolvable constraint cases, e.g. elem1 left of elem2, elem2 left
of elem3, elem3 left of elem1. These constraints can probably be solved in
real-time on current mainstream CPUs, and the browser can generate an
error. Do we want to introduce a paradigm that has cases with no
well-defined layout? What do we display in cases of such circular
constraint error, e.g. revert to inline?

I suppose that when the constraints cause overlapping elements, then the
default z-order applies as per their order in the content, or any
override.

I suggest "Generalized Relative Constraints" as the name for this
proposal, because of the following suggestion.

Could this proposal thus generalize and supercede the Flex-Layout
proposal[1], if we generalize the proposal to not only specify relative
edge position, but also relative size between elements???  Yeah!

Overall, I love it this proposal given the restrictions I proposed. I love
this effort to generalize layout typography algorithms. Gimmie asap :D

Received on Tuesday, 19 October 2010 15:43:51 UTC