Re: Positioned Layout proposal

On Thu, Dec 23, 2010 at 5:07 AM, Shelby Moore <shelby@coolpage.com> wrote:
> 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.

While (2) would indeed make many things easier, it is too restrictive
in practice.  For example, it prevents us from addressing the "notes
in the margins" use-case that Google Docs exhibits, where you want to
position relative to at least 3 things: it should be positioned
vertically at the same level as the content it's notating; it should
be positioned vertically so that it's below any preceding notes; it
should be positioned horizontally so that it's in the margin of the
document.

It would also prevent the "ragged columns" use-case I'd brought up,
and generally vastly restrict the sort of arbitrary layouts you can
create with Positioned Layout.  I envision Positioned Layout as a
useful tool for handling complex layouts that don't fit within the
paradigms of our more powerful layout modes, so I don't want to
unnecessarily restrict this facility.

Depending on how you interpret it, it may also prevent the "contain"
ability that I envision, which is necessary for the "sticky table
headers" use-case and the "tooltips" use-case.


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

No, this would not be sufficient, because column-span works in a
different way than what is necessary for that use-case.  When a
column-span is found, all the prior content is balanced across all the
columns, then the span is placed, then the remaining content is flowed
in a new column-row.  In the "ragged columns" use-case, expanding a
story in the middle column with this behavior would cause all the
stories from the first column and all the preceding stories from the
middle column to balance themselves across all three columns, then all
following stories from the middle column and all stories from the last
column to flow after the expanded story.


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

The layout complexity isn't significant.  A graph of dependencies can
be created and searched for cycles using well-known and reasonably
fast algorithms.  After breaking the cycles, layout is roughly as
simple as current absolute positioning.


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

Yes, these two problems are orthogonal.  That's why they're being
solved in two different layout managers, with a minimal and
well-defined connection between them.


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

No, that doesn't work.  It doesn't solve any of the problems more
cleanly, as you need to measure each element to know how much rowspan
it needs.  In the application that inspired the "ragged columns"
use-case, avoiding having to do this measurement and synchronization
was the primary reason we switched to using abspos and a constraint
solver.  Positioned Layout removes this problem by pushing it entirely
to the browser, which has the information to solve this efficiently.

Adopting this idea would also massively complicate table layout, for
little benefit beyond solving my exact use-case.

~TJ

Received on Tuesday, 28 December 2010 22:00:02 UTC