Re: [css3-layout] Various issues concerning Template Layout

On Wed, Apr 8, 2009 at 12:09 PM, Giovanni Campagna
<scampa.giovanni@gmail.com> wrote:
> No. I wrote "first the element bar is processed", then "bar::before",
> etc... so the preceding of "bar::before" (explicit generated inline
> box) is "bar" (explicit block box), followed by "bar's content"
> (anonymous inline or block boxes) and "bar::after" (explicit generated
> inline box).
> I explained it better in the following sentence:
> If the element or pseudo-element generates the first child box, it
> gets position:inherit
> Else it gets the same as previous sibling box.
> Box::before, if generated, is the first child box by definition, so it
> gets position:inherit, and all the remaining child box get the same
> slot.

But in the example bar::before wasn't the first child box.  Foo was.
In order, the children were foo, bar::before, bar, and finally
bar::after.

>>>> Ordering of multiple elements put into the same slot
>>>> ====================================================
>>[...]
>>
>>> In addition, I hope that
>>> the Generated and Replaced Content (or Generated Content for the Paged
>>> Media) will be referenced, as this is very similar to the Named Flow
>>> issue.
>>
>> It is indeed very similar.  My hope is just that all the various Named
>> Flow concepts get unified into a common syntax.  As I brought up last
>> time this was discussed, we've currently got something like 4
>> different ways to say "take this element out of the flow, and put it
>> into this other flow over here".
>
> Unfortunately, it doesn't seem that lots of implementors are concerned
> with this feature (as it requires a lot of computation on the UA side)

Eh, it's also more theoretical at the moment.  As these sorts of
things come closer to realization, I'll be pushing harder for
unification.

> I'm not sure if you can have negative lenghts on ".". You cannot have
> negative widths anyway (and "." are regular but unfillable slots)

Ah, no, by 'negative space' I was referring to the art term.  It means
space that isn't occupied, empty space that draws the eye purely
because it *isn't* emphasized.


> Well, I always thought that the use for margin was fundamentally the
> same as border-spacing (which is resolved by "." in template layout),
> but about negative margins I agree with you, they can be very useful.

Margins and border-spacing are basically the same thing.  The
difference is that border-spacing is uniform, while margins can be
individualized.  But relying on "." for all spacing issues makes the
template much more bloated and clunky than it has to be.  I'd prefer
keeping it for the clearer role of just defining certain slots as
things you definitely won't be filling with content.


> Just I was thinking... is the slot (rather than content inside the
> slot) a *positioned element*:
> I hope yes, since this would solve the negative margin and overlapping
> slot problems, and would allow to specify a z-index on the slot rather
> than on the template ancestor, in case you have real absolutely
> positioned elements, without resorting to put all elements in the slot
> in a different stacking level than the slot.
> This would be especially useful if we decide to use a different
> property than "position" for Named Flows (and slot individuation).

I believe it is much more natural to treat the slot as an abspos
element, yes, with some magic for handling the min-content,
max-content, and fit-content values.


> Thinking of Template Layout as syntactic sugar for Grid Positioning
> (with implicit block box creation) is interesting, but there are
> several differences, like the fact that a slot can push the other, if
> it becomes too big (and if the template allows for that), instead grid
> units are fixed and absolutely positioned elements are taken
> completely out of the flow.
> Broadly speaking, with a bunch of percentage and calc(), you don't
> need Grid Units at all, because the layout model is Absolute Position.

You're right, Grid Positioning sets up a static grid.  Currently
Template Layout would use a bit of magic to get around that.  I feel
like there's an abstraction sitting underneath this that we can
extract, though I'm not sure what it is yet (perhaps linked to Grid
Positioning's speculation about named grid lines...).  I'd like to
reduce Template Layout's magic to an absolute minimum, so that we can
reuse these tools in other contexts.


>>>> Layout within a ::slot pseudoelement
>>>> ====================================
>>>> Currently, objects positioned into a slot are laid out according to
>>>> normal static flow (+ float).  At the moment the 'flow strategies'
>>>> are: static, table, and multicol.  Further flow strategies will appear
>>>> in the future, such as horizontal box flow.  I would like the ability
>>>> to change the flow strategy within a slot so I could, for instance,
>>>> make the contents of the slot occupy two columns, or position multiple
>>>> display:table-row elements into a slot and have their table-cell
>>>> children align appropriately.
>>>
>>> Currently you cannot, because position other than static / relative
>>> implies display(-role):block, and the same you cannot float things on
>>> rigth / left of slots. This is the reason I opposed with reusing
>>> "position".
>>
>> Actually, an element can be template-positioned and still float.
>> Check section 11 of the draft.
>
> I didn't see it the other day, but I see that this is an inconsistency
> with both CSS21 and css3-box. And I definitely don't like it (but I
> don't like the use of "position" at all, so it doesn't matter)

Indeed, it is an inconsistency.  I don't have a particular problem
with how Template breaks the rule, but there may be a gain in making a
run around it instead.  I'm still partial to the "move-to: slot(a)"
syntax.  ^_^


>> As well, your answer is somewhat unrelated to my question.  The
>> positioned elements can be display:block for all I care, but I can
>> easily want them to flow using a multicol strategy.
>
> Sorry, I understood that you wanted display(-model):table on the
> ::slot pseudo-element, to make the table-rows get the corret height.

Also so that the cells in the various rows would align their vertical
borders like in a proper table.  It seems like currently each row
would wrap itself in its own anonymous table box.


>>>> At the moment flow control is sort of all over the place, so I guess
>>>> this would require the ability to specify display (at least the block
>>>> and table values) and the column-* properties on a ::slot
>>>> pseudoelement.
>>>
>>> You could specify "display-model" on ::slot pseudo-elements to allow
>>> different layout modes (but not display or display-role).
>>
>> I would like to be able to do so, yes.  Currently the draft doesn't allow it.
>
> Currently we don't have a "display-model" at all, it has been removed
> from css3-box in 2007.

Well, yeah, but I meant in a general sense.  *However* we handle
display models, I'd like to be able to specify it on a ::slot()
pseudoelement.


~TJ

Received on Wednesday, 8 April 2009 17:57:49 UTC