W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: Positioned Layout proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 19 Oct 2010 11:26:41 -0700
Message-ID: <AANLkTin6yYJqTfTCZnQPVVjZ0d_3rRKDMZ1HgpjkYBJV@mail.gmail.com>
To: shelby@coolpage.com
Cc: Sylvain Galineau <sylvaing@microsoft.com>, www-style list <www-style@w3.org>
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.

Positioned Layout *does* make things somewhat "dumb" by killing the
concept of flow entirely.  That makes things simple.  Flexbox doesn't
do that, but it makes different simplifications that allow it to be
simple to understand and still powerful.  Template is different still.

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

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

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.

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

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

That sort of approach is inappropriate for either Positioned or Flexbox Layout.

Regardless, you can find the current Template Layout draft at

Received on Tuesday, 19 October 2010 18:27:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:39 UTC