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

2009/4/8 Tab Atkins Jr. <jackalmage@gmail.com>:
> On Tue, Apr 7, 2009 at 7:55 AM, Giovanni Campagna
> <scampa.giovanni@gmail.com> wrote:
>> 2009/4/7 Tab Atkins Jr. <jackalmage@gmail.com>:
> [...]
>>> position:same on generated content
>>> ==================================
>>> Assume that foo and bar are sibling elements in the DOM, in that order.
>>>  What is the result of the following CSS?
>>>
>>> foo {
>>>  position: a;
>>> }
>>>
>>> bar {
>>>  position: b;
>>> }
>>>
>>> bar::before {
>>>  position: same;
>>>  content: "Baz!";
>>> }
>>>
>>> bar::after {
>>>  position: same;
>>>  content: "Quux!";
>>> }
>>>
>>> Will I see the two generated strings in ::slot(a) or ::slot(b)?  The
>>> spec specifies that it should follow the "most recent element with a
>>> letter as position that has the same template ancestor", but it
>>> doesn't seem clear what the "most recent element" is in this case.
>>
>> I expect that first bar is processed, then bar::before, then bar
>> contents, then bar::after.
>> Another way to say this is "If the element generates the first child
>> box of its parent, position:same is equal to position:inherit, else
>> the used value is the same its previous sibling box", so ::before
>> boxes, anonymous boxes (block or inline) and display:none are taken
>> into account when deciding.
>
> Hmm, I'm not sure exactly what you intend that to mean in the context
> of my question, though.  It *seems* like you mean that bar::before
> should go in slot a (as the preceding element is foo), and bar::after
> should go in slot b (as the preceding element is bar).  Is this right?

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.

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

>
>[...]
>
>>> Properties applicable to ::slot pseudoelements
>>> ==============================================
>>> I would like to be able to apply more properties to the ::slot
>>> pseudoelements.  Specifically, I want to be able to provide all of the
>>> border-* properties, box-shadow, padding, and margin.  Border-* and
>>> box-shadow are required for the same reasons that background is -
>>> without the ability to specify this on the slot, you are forced to
>>> move only a single element into the slot and make it completely fill
>>> the slot if you want to make the properties look like they apply to
>>> the slot.  Padding is also necessary; you can fake horizontal padding
>>> on the slot by using margin on the elements positioned into the slot,
>>> but vertical padding can't be done without foreknowledge of the first
>>> and last elements that will be positioned into the slot.  Margin can
>>> be faked by putting extra rows and columns into your template, but
>>> that is ugly and inconvenient when we have the appropriate property at
>>> hand.
>>
>> You don't need margin (that btw would create problems with
>> collapsing), "." slots are here for that reason.
>
> Yeah, I hinted at that.  However, it can end up being *very*
> inconvenient, as you need to add an additional row/column for every
> edge of margin you want on a slot.  The "." slots are very convenient
> for other purposes (negative space), but as margin replacements there
> are barely acceptable.

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

> As well, it still doesn't allow us to do many things.  Take Example
> XX.  In there, element #c is flowed into slot c, and given negative
> margins.  The example appears to make the assumption that flowing an
> element into a slot forces it to completely fill the slot, which is
> incorrect.  The behavior shown is only possible if you can ensure that
> #c completely fills the height of the slot, which means that it's the
> *only* element put into that slot.  If you're positioning multiple
> elements into a single slot, you must specify background on the
> ::slot() instead, and without a margin property, it becomes impossible
> to achieve the example's rendering.
>
> The margin collapsing issue is only a problem if you let margins
> collapse.  That's not a necessity in this case, and I think it would
> be reasonable to state that slot margins do *not* collapse with the
> margins of other slots.  Slots are essentially abspos elements, and
> abspos elements don't collapse margins with anything else.

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

>> For the other
>> properties, you need some more processing to layout, because with the
>> current model you assume that you don't need additional space.
>> The solution could be to imply "box-sizing:border-box", but I'm not sure.
>
> I would assume box-sizing:border-box, yes.  That's the most intuitive
> value for a ::slot pseudoelement to take by default.  Since I'm
> strictly defining how large I want the slot to be in the template, I
> wouldn't want borders and padding to mess with that by default.
>
> Essentially, I'm just wanting the ::slot pseudoelement to act like a
> normal abspos element with its placement and dimensions stated in Grid
> Positioning units.  If we don't answer these issues now (like what to
> do about margins), they'll come up again when/if Grid Positioning gets
> pushed through, and possibly in a confusing incompatible way.  After
> all, Template Layout is nothing more than Grid Positioning + Named
> Flows, with a little bit of automatic container-creation magic.

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.

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

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

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

> ~TJ
>

Giovanni

Received on Wednesday, 8 April 2009 17:10:06 UTC