- From: Bert Bos <bert@w3.org>
- Date: Tue, 28 Apr 2009 09:59:07 +0200
- To: www-style@w3.org
Alexis Deveria wrote:
> Some issues that came up when working on my JavaScript implementation:
>
> 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.
>
> 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.
>
> 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...
>
> 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.)
Thanks for the comments!
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Tuesday, 28 April 2009 07:59:49 UTC