Re: template layout edits

On Wed, Apr 28, 2010 at 5:10 AM, Bert Bos <bert@w3.org> wrote:
> On Tuesday 27 April 2010 17:47:50 Tab Atkins Jr. wrote:
>> On Tue, Apr 27, 2010 at 8:10 AM, Bert Bos <bert@w3.org> wrote:
>>>  - Added that the sizes of the rows and columns of a template
>>> element that is broken across multiple pages are calculated
>>> separately on each page. (They may thus be different on each page.)
>>
>> What if a single cell breaks across a page boundary?
>
> I'm not sure I have fully understood page breaks that occur in multiple
> boxes side by side (e.g., also in two side-by-side floats, or in a
> table). One needs to find good page breaks at about the same height in
> all adjacent boxes, and maybe it even requires multiple tries to get
> the most text on each page while not making the breaks too ugly.
>
> We said for page breaks in general that the boxes on both sides of the
> break could have different widths, because the pages themselves could
> have different margins. That holds equally when it is a simple,
> one-column text that is broken as when it is a table or a template.
>
> I'm hoping that we can formulate a clear framework (some set of
> constraints) that applies equally to all cases: breaking inside tables,
> inside floats, inside templates, or inside anything else.

Huh.  Kinda weird for a cell to be different widths across a page, but
yeah, it's a general problem that we need to solve for more than just
Template.


>>>  - Added an issue: should a '::slot()' accept the 'block-flow'
>>>    and 'box-shadow' properties?
>>>
>> ::slot should accept *all* properties except display (given a
>> shorthand display, it should accept display-inside, but not
>> display-outside).  It should be treated exactly equivalently to a
>> table-cell.
>
> I'm not so sure. My preference is for no properties at all: a template
> is just a replacement for absolute positioning, i.e., its single
> purpose is to position elements, not to create new ones.

That's inconsistent with the way Template works.  If you could only
assign a single cell per slot, and it automatically filled the full
size of the slot, then sure.  But that's not how Template works.  It
flows multiple elements into a slot, which then act like they're in a
normal block context, *not* like they're absposed.

Template creates shadow elements.  There's no way around it without
fundamentally changing the way Template works, which would
substantially reduce its usefulness.


> I could see that people want to add properties to a slot that do not
> affect layout, i.e., the background properties.
>
> I also see a small case for 'vertical-align' on slots, because the
> syntax would get too complicated if vertical alignment were expressed
> in the template itself. (I'd have preferred that, but I couldn't come
> up with a readable syntax: "a^ b_" for top-aligned a and bottom-aligned
> b?) I also considered allowing 'vertical-align' on the positioned
> elements. That works reasonably well, except if there are two elements
> in the same slot...

A template slot should act like a table-cell; vertical-align should
apply to it.  There's no need to go any further - we can treat a
Template *exactly* like a shadow table, just with a new table-layout
algorithm.  This keeps things as simple as possible.  Anything you
know how to do with a table, you know how to do with a Template.


> But I prefer not to go beyond that. I think CSS will become impossible
> to use if it allows arbitrary extra elements to be created. It is
> simply not designed for that. It would have needed a model more like
> that of XSLT and DSSSL in that case.

Arbitrary elements?  Sure, that's probably not doable.  But this isn't
arbitrary.  Template is nothing more than a description of a table
layout, combined with source-independent placement.  The easiest and
least arbitrary way to deal with this is to *make* a shadow table and
treat elements as being children of those shadow cells.

This is reordering of content.  It doesn't change the DOM at all, and
inheritance still works exactly like it should from the DOM.  But
we're explicitly reordering the CSS box tree, so that elements change
their parent/siblings for rendering purposes.  Trying to pretend
otherwise is a fool's errand, given the complexity we need for
layouts.

Flexbox works similarly, with the box-ordinal-group property that
rewrites sibling relationships.

Like I said, though, we're only reordering the CSS box tree.  The DOM
is unchanged, which means inheritance and selectors are unchanged.


> Imagine this:
>
>    div {display-inside: "@"}
>    div::slot(@) {display-inside: "@"}
>    div::slot(@)::slot(@) {display-inside: "@"}
>    /* Let's make a few more, just so we have enough... */
>    div::slot(@)::slot(@)::slot(@) {display-inside: "@"}
>    div::slot(@)::slot(@)::slot(@)::slot(@) {display-inside: "@"}
>    /* Now we have enough elements to make triple borders,
>       quadruple backgrounds... Power! */
>
> What's the DOM for that? How is a WYSYWYG editor going to take that
> apart?

The DOM is unchanged.  The CSS box tree is reorganized to contain
multiple nested shadow tables.

Note, though, that's a really silly example.  On the other hand, I
have live examples of a layout that would need nested templates to do
correctly - check out cnn.com.  Note that it has 3-column near the
top, and 4-column near the bottom.  There's no way to do both of those
in a single template.  The easiest and most understandable way to mark
it up is like this:

body {
  display-inside: "a"
                  "b"
                  "c"
                  "d"
                  "." /5px
                  "e"
                  "." /5px
                  "f"
                  "." /5px
                  "g"
                  "." /20px
                  "h"
                  "i"
                  "j"; }
body::slot(d) {
  display-inside: "a.b.c"
                  250px 5px 416px 5px 300px;
}
body::slot(f) {
  display-inside: "a.b.c.d" /*
                  "......." /20px
                  "e.f.g.h" /*
                  "......." /20px
                  "i.j.k.l" /*
                  "......." /20px
                  "m.n.o.p" /*
                  "......p" /20px
                  "qqqqq.p" /auto
                  220px 20px 220px 20px 220px 20px 220px;
}

I find this very simple and easy to understand, given the
requirements.  On the other hand, the horrendous abortion of markup
that they're currently using to create this layout is impossible for a
human to understand - I sincerely hope that it is machine-generated.

> I don't think the layout of a page is so important that we need such
> monstrosities for average HTML pages. And for cases where it really is
> important to make a layout that cannot be done with just the elements
> in the document, we already have XSL and XSLT. They're designed for
> this kind of work and much more powerful than we can ever make CSS.

Neither of those work for HTML, and they're too complex for general
author usage in XML.  We don't *need* their full power to enable
powerful, complex layouts that solve real problems that authors have,
with a simple and understandable syntax that can be both easily
hand-written by authors, and easily machine-generated by GUI layout
builders.  This is similar in principle to how CSS is gaining a small
number of abilities currently possessed by SVG, when the functionality
is very useful and we can expose it in a simple, understandable way
for authors.

~TJ

Received on Wednesday, 28 April 2010 18:36:51 UTC