- From: Mats Palmgren <mats@mozilla.com>
- Date: Tue, 12 Jan 2016 19:16:29 +0100
- To: www-style@w3.org
On 01/12/2016 17:46, Manuel Rego Casasnovas wrote: > First it resolves "2 foo", which creates 2 implicit tracks on the right: > [foo] [foo] > | 1st | 2nd | 3rd | > > Then it resolves "span bar", and here we've 2 possible options. > > 1.A) According to "all implicit grid lines are assumed to have that name". > So it should consider the implicit tracks already created on the right > in the previous step. > [foo] [foo] > [bar] [bar] > | 1st | 2nd | 3rd | > > Then it doesn't need to create any implicit track on the left. > > The item should only take 1 column, the 3rd one. > > 1.B) It creates 1 implicit track on the left: > [bar] [foo] [foo] > | -1 | 1st | 2nd | 3rd | > > So the item takes 4 columns, from -1 to 3rd (both included). > > IMHO, and with the current text in the spec the right answer is 1.A). > However this leads to the next issue. IMHO, the current spec text actually suggests 1.B, because the "If not enough lines with that name exist, " part is a condition for the "all implicit grid lines are assumed" part, which implies that you start searching the explicit lines first and then *when you run out of explicit lines* you continue into the implicit grid counting all lines as matching there. That's how I read it anyway and implemented in Firefox, fwiw. > Probably the best option is that we follow B) behavior in both issues 1) > and 2). Yes, I strongly prefer B) to avoid Issue 2 you mention, but also to avoid unpredictable results in general. Assuming the explicit grid contains a single line named "A": [A] | 1st | 2nd | ... you really want "span A / <x>" to always result in the grid area starting in A for all possible values of <x>, including the cases where it happens to be an implicit line. > IMHO, if that's the case the spec needs some further clarification. I agree that the spec text needs to be clearer about this. /Mats
Received on Tuesday, 12 January 2016 18:17:01 UTC