Re: Positioned Layout proposal

On Tue, 28 Dec 2010 13:59:07 -0800, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

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

Agreed, (2) above can be relaxed to allow multiple constraints when the
relatively positioned element is removed from the normal flow.

Caveat: the targets of the constraints can't be multiply constrained,
unless do an search for the insoluble cyclical case (see ascii art
illustration I had provided for #2).

I had written in prior post:

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

In general, multiply constrained is simple if relatively positioned
element is removed from the normal flow, table, and flex box layout, i.e.
nothing else in the document depends on its dimensions. Otherwise, the
relativity constraints must be incorporated into the layout model for
minimizing inline (horizontal) overflow, which in general case has
unrealistic potential entropy (computation complexity):

http://lists.w3.org/Archives/Public/www-style/2010Dec/0428.html (see #1)

With "notes in the margins", if the margin is not a relativity dependency
(e.g. user can adjust it), and thus the vertical alignment of the "note"
within that margin does not cascade to rest of the document, thus there
are no cyclical constraints on the layout model for minimizing inline
(horizontal) overflow of the rest 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.

Agreed. I now understand that your proposal has always been about the
generality when the relatively positioned element is removed from the
normal flow (correct?) and there will be no instrinsic layout of the
relatively positioned element's inline dimension.

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

Can "contain" (within viewport, referenced element, etc) intrinsically
size the relatively positioned element's inline dimension? This could
cause cyclical insolubility.

>> 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 had also written in the subsequent post that it would not work, because
more fundamentally, the relatively positioned element must be removed from
the normal flow.

Off topic, I am not implying I agree entirely with the design of the
current column algorithm.

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

Agreed, if the relatively positioned are removed from normal flow
constraints (which are inherently cyclical and thus any new cyclical
generality will break them and drive up the computation complexity).

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

Agreed, the relatively positioned element can be a table or flexlayout
container.

I was also disagreeing with an aspect of current CSS design, for example
alignment and widths in the table (and proposed flexlayout layers), imo
these should be orthogonal (size and align the elements contained within
them, not burden the container with these orthogonal details).

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

I think it is the only way you can do it, since you are keeping these in
the normal flow. Perhaps that contributed to my confusion about whether
relatively positioned elements stay in the normal flow in your proposal?

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

I am thinking that if the column rows are aligned to news story tops and
bottoms, then fractional rowspans is declaratively bijective to your use
case and thus all constraint computation is in the table layout algorithm.

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

I studied the table layout algorithm description and it seemed to me (at
that time) there is no complication with fractional rowspan, only with
fractional colspan. And off top of my head, even fractional colspan may
not be that the difficult. I had the reasons in my head the other day when
I was reviewing the table layout algorithm, but I have since moved my mind
on to reasonably complex project of writing a custom grammar, lexer and
AST generator (not reusing existing generators) for a fairly complex new
language, so I don't have the table layout issues loaded in my mind right
now.

Received on Wednesday, 29 December 2010 14:00:22 UTC