Re: Positioned Layout proposal

> On Tue, Oct 19, 2010 at 10:22 AM, Shelby Moore <shelby@coolpage.com>
> wrote:
>> [snip]
>>
>>>> And I have generalized your proposal, to propose that we should also
>>>> offer
>>>> relative sizing of the box width and height, so as to combine and
>>>> generalize the Flex-Layout proposal:
>>>>
>>>> http://lists.w3.org/Archives/Public/www-style/2010Oct/0372.html
>>>
>>> I don't believe it is worthwhile to attempt to generalize this enough
>>> to somehow solve the problems of both Positioned Layout and Flexbox
>>> Layout.
>>
>>
>> Afaics, the constraint and layout rendering algorithms issues they
>> create
>> are the same.  I think you kill 2 birds with one stone.  If you do one,
>> the other comes nearly for free.
>>
>> Position and size are the same constraint category.
>
> They're actually not, unless you purposely make CSS somewhat "dumb" in
> regards to sizing.  There's a bunch of sizing/positioning issues that
> don't resolve into a simple constraint model that's hackable by
> ordinary authors.  For example, baseline alignment.


Afaics, baseline alignment is an orthogonal computation. I don't
understand your point in raising it here?

Could you give an example?

For example, if you tell two adjacent elements to be relatively positioned
and sized to each other, then this is for the purposes of normal flow
logically the same as placing them in a <span style='inline-block'> where
the imaginary <span> will bound the two elements in their relative
position and size.  Thus the baseline alignment of that imaginary <span>
is an orthogonal calculation that comes after the calculation of the
relative position and size.


> Positioned Layout *does* make things somewhat "dumb" by killing the
> concept of flow entirely.


I didn't realize you are proposing that the normal flow is always
excluded??  I thought you would offer that as a setting whether to pull
the relatively positioned element out of normal flow?


>  That makes things simple.


It is less general.  I need those new relative positioning targets for
normal flow too, e.g. the tooltip and corner treatments use cases.


>  Flexbox doesn't
> do that, but it makes different simplifications that allow it to be
> simple to understand and still powerful.


Afaik, Flex-Layout only proposes to have flow within its relatively
positioned cells.


>  Template is different still.


I see the link below.


>
>
>>>  The two are intended to solve different features, and involve
>>> different types of constraints.
>>
>>
>> Afaics, they are the same generalized constraint category. My mind works
>> very abstractly at times.
>>
>> The layout engine is going to have to consider the position and size in
>> each of it's computations of layout constraint.
>
> I do not consider the complexity of layout engines to be something to
> emulate and expose to web authors.


Others can build "simpler" (less general) models on top of the exposed
layer.  It will allow maximum experimentation in the market. Let the
market decide.

I conceptually find the general model to be simpler and more elegant, but
let market pick winners and losers. That can change when we will drill
into the details.


>  Even if something is in principle
> solveable by a general model, that's not always what you want to work
> in.  (As an analogy, consider relativistic physics versus Newtonian
> physics.  The former is more general and more correct than the latter,
> but you teach the latter in school because it's much simpler and
> covers the majority of common cases.)


Understood.  Ditto above.


>>>  While it is possible in principle to
>>> merge them, I believe it would be too confusing to authors and too
>>> expensive for browsers (as you'd probably need to do something like
>>> simulated annealing to solve the constraints).
>>
>>
>> Why do you think so?  I see the opposite.  The model becomes very clear
>> and fully generalized.  No more special cases.  For example, your
>> proposal
>> eliminates position:fixed as a special case.
>>
>> The problem with CSS direction now is the potential proliferation of
>> special cases, rather than employing a simpler to specify generalized
>> model, e.g. making tooltips a special category is a special case.
>
> I don't agree with making tooltips a special category.  Andrew is the
> implementor of his own layout engine, which implements a custom fork
> of CSS with many proprietary modifications.  His emails and documents
> detail only how his own layout engine works, not how the W3C and
> browser vendors define CSS.


Glad we agree on that, and I will add if Andrew wants to build extensions
on an hypothetical exposed generalized layer, then that is great.  I like
when the market can anneal, because we are not all knowing and we are not
fast enough here.


> I do agree that special cases are generally bad.  But overgeneralizing
> is also bad, if it results in an abstraction that's too high-level to
> easily work with.


Ditto above.


> I think the CSSWG is charting a good course here, by embracing
> multiple specialized layout models that interact in a minimal and
> controlled fashion.


Okay but it seems (see Boris's comments) eventually we reach gridlock in
the layout engines. Special case design ends as spaghetti, because special
case assumptions were made in the design of the layout engine too.

I am not saying I know where to best delineate.  I am just talking in
abstract terms, that such a line exists some where.  You all have to
decide.

I like discussing ideas here, because even if they are not implemented in
CSS, they give me ideas about things to implement.


>>> Instead, I believe it's best to design separate layout models that are
>>> powerful by themselves and well-designed for solving particular
>>> use-cases.  The current set of new layout models I'm pushing
>>> (Positioned, Flexbox, and Template) all satisfy this.
>>
>>
>> What is Template? I will help you generalize all 3 into one simple and
>> robust model.
>
> I assure you that you can't.  Template Layout is just some sugar and
> magic sprinkled over Table Layout, with the end result that you can
> specify a page's overall layout in a somewhat-WYSIWYG fashion that's
> really easy to understand and hand-author.


I will look as time allows.


> That sort of approach is inappropriate for either Positioned or Flexbox
> Layout.
>
> Regardless, you can find the current Template Layout draft at
> <http://www.w3.org/TR/css3-layout/>.

Thanks.

Received on Tuesday, 19 October 2010 19:14:21 UTC