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

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>

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

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

> As well, how does this interact with generated content?  Take the code
> from the previous example (to avoid ambiguity, assume that both of the
> pseudoelements have position:b).  I would assume that the ::before
> pseudoelement contents would come before the contents of bar, and the
> ::after pseudoelement contents would come after.

See above my interpretation.

> 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

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

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

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

>
> Multiple template ancestors with unique slot names
> ==================================================
> Assume I have an element <foo> which has a child <bar>, both of which
> have templates specified on them.  Both use completely unique letters
> for the slots in their templates, so there is no overlap.  Now,
> consider a descendant of bar with position specified, naming a letter
> present in foo's template.  I *believe* this will fail and compute to
> 'static', as positioning into a slot only looks at the most recent
> template ancestor, and ignores all others that are further up the
> ancestor chain.  Is this correct?

I suppose the same.

> ~TJ
>
>

Giovanni

Received on Tuesday, 7 April 2009 12:56:02 UTC