Re: Positioned Layout proposal

Below I provide an example for proposed CSS syntax for the generalized
model...

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

I am reading the Flexbox now.

> allows you to align flexbox
> children such that their baselines line up.

I see that now.

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

Relative-positioning could be relative to baseline. To be more general, I
would allow one relative-positioning target be relative 'vertical-align'
of the elements.

I still don't yet see a case where the model of relative position and
relative size is not the general model. Even 'position:static' is just a
special case of relative positioning of 'vertical-align' for adjacent
'display:inline' elements.

The fully generalized model that encompasses current CSS and everything we
want to do, is less foggy to me now and coming into view. That is what I
have been hoping to discover, so I thank you.

Once we generalize the model, we can make much more powerful layout
engines and then build what ever we want without having to change any code
in the layout engines.

Any way, I am just thinking out what I may or may not want to do,
irregardless of what this group does.  But I hope to synergize here on W3C
standard, or to find out that I am thinking in the technically wrong
direction.

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

By 'imaginary' above, I meant 'anonymous'. Above I was thinking about how
the parent element of the relatively position content could remain in
normal flow. Please see the reply I made to myself on the above, wherein I
corrected and elaborated. So I think the above was not applicable to the
baseline positioning issue.

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

Please see where I wrote "To be more general..." above.

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

It seems to be less complex (more orthogonal) than the current Flexbox. 
For example, in Flexbox:

box { display:box; box-align:baseline; box-orient:horizontal }
single { box-flex:1 }
double { box-flex:2 }

<div class='box'>
   <div class='single'></div>
   <div class='double'></div>
   <div class='single'></div>
</div>

In generalized relative positioning and sizing:

half { position:element; rvpos:baseline; rvmargin:0; rsize:0.5 }
next { element:next-sibling; rhpos:right-left; rhmargin:0 }
prev { element:prev-sibling; rhpos:left-right; rhmargin:0 }

<div class='half next'></div>
<div></div>
<div class='half prev'></div>

Are those settings obvious, or do I need to describe their semantics?

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

I dealt with this in another reply:

http://lists.w3.org/Archives/Public/www-style/2010Oct/0401.html

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

Agreed.  I think perhaps I provided the solution at the link above.

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

I do not really understand well. Perhaps you may see how that relates to
the comments I made at the above link and see if you find any value in
taking that further with me.

[snip the Flexbox link]

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

Oh but how do you know that someone isn't going to extend CSS reusing the
generalized model and then build it into the browser and make it very
popular so it becomes a standard?

I see the day of a few tightly controlled browsers is coming to an end
very soon. Or at least what I mean is more coding of the browser platform
itself.

Besides we can reuse a general model to design new specs here, so that
browser can implement them simply by CSS translation!

We can test new specs faster.

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

I don't think my example above is less complex, and it is certainly more
general.

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

Agreed. See my example above please.

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

Yup and let's generalize it and make it easier, more fun, and even more
powerful. :D

Received on Wednesday, 20 October 2010 01:58:54 UTC