Re: [css3-layout] Issues/suggestions for Template Layout Module

On Tue, Apr 28, 2009 at 3:59 AM, Bert Bos <bert@w3.org> wrote:
> Alexis Deveria wrote:
>> 1. It wasn't clear to me what the height should be of a white space
>> row (i.e. " . . . ") when no height has been given to either the row
>> itself or the template. I believe my implementation currently sets the
>> height to 0, though Example IX seems to make it about 1em, or perhaps
>> it uses the height of the previous slot. Either way, the correct
>> behavior should probably be mentioned under [1] "Computing the height
>> of the slots"
>>
>> [1] http://www.w3.org/TR/2009/WD-css3-layout-20090402/#rowheight
>
> That's indeed an inconsistency, probably not the only one. Various
> contradicting ideas have left their traces in the draft...
>
> The draft currently says that the default height of a row is 'auto', i.e.,
> depends on the content. The intention is that a row with nothing but '.'
> thus has a default height of 0. But the height calculation is very likely
> underspecified.
>
> Personally, I go back and forth on whether I want the default height of rows
> to be '*' or 'auto'. One argument for '*' is indeed that a row of '.' then
> doesn't need a '/' + height in order to be useful.
>

Okay, glad to hear I'm not crazy. :) Can't say I have a suggestion
either way there, except that 0 seemed the most likely result to me.

>> 2. I feel like the spec is missing some examples on how templates deal
>> with slot elements with given widths/heights. As I understand it these
>> values are ignored, except when max-content, min-content, minmax(p,q),
>> or fit-content are used.
>
> You cannot set width/height on individual slots, only indirectly on rows and
> columns. Allowing width/height on individual slots seems to just introduce
> complexity with no benefit.
>
> The value is not important: 'width: fit-content' is ignored the same as
> 'width: 10em'. E.g., a style rule such as
>
>    ::slot(a) {width: fit-content}
>
> is syntactically correct, but the 'width' property does not apply to the
> slot pseudo-element and thus the rule is ignored.
>
> I'm not sure examples are needed. The spec says which properties apply, all
> the others are thus ignored.

Yeah, I do understand why this is. Again, I mistakenly said "slot
elements" when I meant the element that goes into the slot. Since my
script doesn't have a real slot element I'd gotten used to them being
the same thing.

I think I'll create a test template and share it with the list to see
if we can agree on the expected rendering (both according to the spec
as well as what the author would most likely want).

>> 3. Some examples have suggested that template slots deal with borders
>> and padding the same way table cells do, but this may not be quite
>> clear enough. So I would recommend adding at least one more example
>> with expected rendering of a template with various combinations of
>> paddings, borders, margins applied to slot elements.
>
> The main purpose of the template was to position elements, not to add any
> new decorations. Some people asked for backgrounds on slots. They were easy
> to specify and don't influence the layout, so they were added. But borders
> are much harder. The borders in the draft are only set on elements, not on
> slots. Unless there is a convincing case for adding more borders than there
> are elements, I prefer to keep the templates as simple as possible...

No, I don't see a real use for borders on slots. Though as the module
becomes more popular with authors, they may come to find a need for
more and more properties. Just speculation of course, but it might
become a slippery slope.

>> 4. I assume that when widths/heights in the template are defined in
>> "em" values, the base font is that of the template element, right? In
>> which case an row with a height set of 1em that included an element
>> with a larger font size would actually have part of it clipped off.
>
> Correct.
>
> (The Values And Units module defines a new 'rem' unit that helps in this and
> many other cases.)

Okay, thanks! And I hadn't heard about that, will look into it.

> Thanks for the comments!

Thank you!

Alexis

Received on Tuesday, 28 April 2009 12:42:39 UTC