- 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