RE: [css-grid] Overlapping elements & backgrounds

(see edit at the end of the mail)

>> Why are the backgrounds drawn in z-index order for all items, and 
>> then only is the content ? Shouldn’t the “B” letter be rendered 
>> underneath the background of the C-box?
> 
> Yes, this is a painting order bug.  
> Though backgrounds are of course drawn before text, elements are drawn 
> whole before following siblings.

Okay, that's what I thought, too. 


>> Another question I had is: it seems Chrome renders the “B” in the 
>> right padding of the B-box. I call this the “absolute-min-content”
>> rendering because it doesn’t even meet the “min-width: min-content”
>> requirement. Is it the expected rendering or are we supposed to at 
>> least meet “min-width: min-content”?
>>
>> The latter is what I had understood from the spec, but this isn’t 
>> quite as clear as I would like.
> 
> No, there is no requirement for a box to be min-content sized.  
> In this case, the B's box is overflowing its cell, and the B itself is 
> overflowing its content box.  Where did you think such a minimum would 
> come from?

>From the fact that you don't "shrink-to-fit" when you stretch-align, but only grow-to-fit. I can see the point of not shrink-to-fitting (even if I believe it should not be the default) but I certainly can't see the point of it if it doesn't even prevent the element to be too small to hold its own content. What's the use case (or reasoning) behind the current Chrome behavior?

-------

I think I got the wrong info by looking at the latest CSS Align "ED". The current CSS Align "WD" specifies the Chrome's behavior.

-------

For reference, here's what the current Editor Draft says about "stretch":

--> ‘stretch’ : If the combined size of the items is less than the size of the alignment container, any ‘auto’-sized items have their size increased equally so that the combined size exactly fills the alignment container, and then clamped by their ‘max-width’/‘max-height’ constraints.

Given this text, I don't see any reason to "force-shrink" the element if it doesn't fit the cell; because no specific width was set on the element it has "width: auto" (which does not "force-shrink" the width), and because it overflows the cell, the stretch step should be ignored. The current Chrome's behavior supposes we did set a "width: ...px" on the element to force it to match the cell width, which is not what the spec says. 

-------

However, the current Working Draft says that:

--> 'stretch': If the ‘width’ or ‘height’ (as appropriate) of the alignment subject is ‘auto’, its used value is the length necessary to make the alignment subject’s outer size as close to the size of the alignment container as possible, while still respecting the constraints imposed by ‘min/max-width/height’. Otherwise, this is equivalent to ‘start’.

In this case, you are indeed encouraged to set 'box-sizing: border-box; width: (CW)px' where (CW) is the breadth or the column (which will force-shrink the element and render its text in its right padding, if it overflows).

-------

So, my conclusion is that Chrome renders correctly according to the current TR spec, but not according to the editor draft. Is that right?

Received on Saturday, 1 November 2014 20:49:59 UTC