Re: Positioned Layout proposal

On Tue, Oct 19, 2010 at 12:13 PM, Shelby Moore <shelby@coolpage.com> wrote:
> Tab Atkins wrote:
>> 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, the Flexbox draft (note: this is *not* the same thing as
Andrew's Flex-Layout document, which describes something he's
implemented in his own layout engine) allows you to align flexbox
children such that their baselines line up.

You can't express that with positioning without bringing in more
complex constraint systems, which I think would make the whole thing
too complex.  Layout is difficult to understand.


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

I'm not sure how you're envisioning this being applicable.  To draw
this example into Positioned Layout, it would involve some value for
'top', say, that meant "set top to such a value that the element's
baseline aligns with this other element's baseline".  Alternately, it
may involve aligning based on the baselines directly, rather than on
the top/bottom edge.

Either of these are too much complexity for me to feel comfortable with.


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

I think we may be talking past each other here.

What I mean is that other layout modes offer a "flow", where a bunch
of carefully designed implicit constraints are used to relate boxes to
each other in various ways.  Positioned Layout instead gives the user
explicit control over the constraints, which opens up the possibility
of accidentally creating dependency cycles (which don't exist in the
flow-based models, if designed correctly).

Handling the explicit dependency cycles is complex enough.  Trying to
mix that with the implicit constraints of other layout flows would be
hellish.  As it is, I'll have to do some work to minimize the contact
that this layout mode has with others.

(As for your direct question, a positioned element is always pulled
out of normal flow, leaving a placeholder behind.  This placeholder
has differing behavior based on the positioning mode.  In 'relative'
mode, the placeholder acts just like the positioned element would.  In
'absolute' or 'fixed' mode, the placeholder acts like a 0-height
0-width non-replaced inline block.  This captures the behavior we
decided to mandate with abspos table cells, and gives me a sane way to
talk about the 'auto' position.)


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

Andrew's Flex-Layout is not the same as the Flexbox Layout draft that
I'm talking about.  You can find the current Flexbox draft at
<http://dev.w3.org/csswg/css3-flexbox/>.  Alex Mogilevsky and I are
working together on a relatively minor update right now - the general
shape of the spec is well-described by the current draft.


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

(Un?)fortunately, that's not how CSS works.  Unlike javascript, or
many other programming languages, you can't really write libraries on
top of CSS.  The best you can do is write a CSS preprocessor like LESS
that "compiles" your custom language into normal CSS.

We explicitly don't design the CSS language to be used in that manner.
 It certainly *can* be used in that way (there's absolutely nothing
wrong with preprocessors like LESS), but an argument that it's okay to
design something that's too complex for regular authors because you
can write libraries on top of it won't fly.  CSS is meant to be as
human-readable as possible.  That goal does gradually recede as the
language becomes more powerful, but we always keep it in sight.

This approach has both advantage and disadvantages, but it's where we
are, and it's extremely unlikely to change.  CSS is not a
general-purpose programming language; it's a specialized
domain-specific language for expressing styling that is designed to be
readable and writeable by humans.

~TJ

Received on Tuesday, 19 October 2010 20:35:05 UTC