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

Sent this yesterday, forgot to do a "Reply all".

On Mon, Apr 27, 2009 at 1:31 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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*.

Okay, I see how that works when all other rows happen to be the same
height, but what if each content-filled row is a different height?
Take the average?

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

Ah, actually I meant the width/height given to element(s) that are
flowed into the slot. My mistake for not making that more clear. I
believe Giovanni confirmed what I suspected in his response to that. I
think both your suggestions regarding ::slot makes sense, though.

Thanks,

Alexis

Received on Tuesday, 28 April 2009 12:13:04 UTC