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

On Mon, Apr 27, 2009 at 11:37 AM, Alexis Deveria <adeveria@gmail.com> 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

Note example VII, which is explicit about what a missing height means
(it implies 1*).  The "." rows in example IX are the same height as
the content-filled rows, since they're all unspecified, and thus all
1*.

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

Currently, ::slot pseudos don't take any of these properties.  They
accept the full set of background properties, vertical-align, and
overflow, but that's it (check section 7).

I think that's a significant limitation, and don't see any reason not
to treat the ::slot elements as table-cells.  You need some conflict
resolution for width/height, but border, padding, and margin all seem
easy to deal with (margins wouldn't collapse).  As Giovanni says, I
suggest ::slot elements by default having box-sizing:border-box.

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

Yup, the em unit still follows standard inheritance to obtain its
value.  It would indeed overflow the element (and possibly clip it,
given an appropriate overflow value) in your example.

~TJ

Received on Monday, 27 April 2009 17:32:17 UTC