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

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>:
>> Use of inline in display: property
>> ==================================
>> The current draft allows an optional "inline" before the template
>> proper in the display property, to indicate whether the element should
>> be block or inline in addition to being a template.  However, there
>> are many reasonable display values beyond block or inline that can be
>> reasonably be applied to an element with a template.  Specifically,
>> among the current display values listed in the Box Module, it seems
>> reasonable to be able to combine a template with the following:
>> inline, block, inline-block, list-item, run-in, table-cell,
>> table-caption, and possibly compact.
>>
>> Is there any particular reason that these display values are unable to be used?
>
> Actually, I hope that the change proposed in an old draft of the box
> model will be approved: display-model vs display-role.
> Display-model is the way the element lays out its children (BFC, IFC,
> Template Layout, Table Model, Ruby, Matrix Layout), display-role is
> how the element is used inside its parent. This way, all currently
> valid display values would be usable with a Template.
> The draft, which is quite old actually, is available at
> <http://www.w3.org/TR/2002/WD-css3-box-20021024/#L706>

Indeed, and that's basically what I was getting at with my question.
The fact that an element positions its children according to a
template has very little to do with how the element is positioned by
its parent.  The current hack (preceding the template with the display
role) works, but it's clunky and, in the current draft, very limited
in what it can do.

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


>> Ordering of multiple elements put into the same slot
>> ====================================================
>> The examples seem to indicate that, if multiple elements are
>> positioned into the same slot, they are flowed within the slot in
>> document order.  However, I can't find any explicit acknowledgement of
>> this within the spec.
>
> "Multiple elements may be put into the same slot. They will be
> layed-out according to their ‘display’ property in the order they
> occur in the source document." in section 6.

Ah, excellent.  I had just missed it, then.


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


>> As well, take this example:
>> <foo>
>>  <bar/>
>> </foo>
>>
>> foo {
>>  position: a;
>> }
>>
>> bar {
>>  position: b;
>> }
>>
>> foo::before {
>>  position: b;
>> }
>>
>> foo::after {
>>  position: b;
>> }
>>
>> bar::before {
>>  position: a;
>>  content: "Baz!";
>> }
>>
>> bar::after {
>>  position: a;
>>  content: "Quux!";
>> }
>>
>> Where would the contents of the two pseudoelements be placed, relative
>> to the contents of the foo and bar elements in slots a and b?
>
> If template is "a" "b"
> You get
> "Foo Baz! Quux!" on one line
> "Foo::before Foo::after Bar" on the other

Yup, this seems clear now.


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

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.


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


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

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.


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

~TJ

Received on Wednesday, 8 April 2009 15:40:21 UTC