Closed
Bug 1238890
Opened 10 years ago
Closed 10 years ago
[css-grid] Span to unknown named grid line don't consider all the implicit lines
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
INVALID
People
(Reporter: rego, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/602.1 (KHTML, like Gecko) Version/8.0 Safari/602.1 Debian/buildd-unstable (3.18.2-1) Epiphany/3.18.2
Steps to reproduce:
In a 2 columns grid position an item using:
grid-column: span bar / 2 foo;
You can use the following jsbin to reproduce the issue (or the attached example):
http://jsbin.com/pupixo/1/edit?html,css,output
Actual results:
The item takes from -1 to 4th column.
So, it's creating one implicit track on the left and 2 implicit tracks on the right.
Initially we've just 2 columns:
| 1st | 2nd |
First it resolves "2 foo", which creates 2 implicit tracks on the right:
[foo] [foo]
| 1st | 2nd | 3rd | 4th |
Then it resolves "span bar", and it creates 1 implicit track on the left:
[bar] [foo] [foo]
| -1 | 1st | 2nd | 3rd | 4th |
So the item takes 5 columns, from -1 to 4th (both included).
Expected results:
According to the spec (https://drafts.csswg.org/css-grid/#grid-placement-span-int):
"
If a name is given as a <custom-ident>, only lines with that name are counted.
If not enough lines with that name exist, all implicit grid lines
are assumed to have that name for the purpose of counting this span.
"
So in this case when resolving "span bar" it should consider the implicit tracks already created on the right in the previous step.
[foo] [foo]
[bar] [bar]
| 1st | 2nd | 3rd | 4th |
Then it doesn't need to create any implicit track on the left.
The item should only take 1 column, the 4th one.
Reporter | ||
Comment 1•10 years ago
|
||
Comment 2•10 years ago
|
||
I believe the layout in Gecko is the correct one and that it's
the intention of the spec text you quoted above.
To spell it out in detail: the starting point for finding lines
that match is the edge of the explicit grid (in the direction
of the span, i.e. line 3 in this case). If the explicit grid
doesn't have enough matching lines then we should simply continue
in that direction (i.e. to the left of the explicit grid)
pretending that every implicit line is a match.
The interpretation you suggest leads to some really wacky results.
For example, add "grid-template-columns: 100px [bar] 100px;"
to your example above. Then the last item in your example would
span to line 2 (because the "enough lines" condition is true
in this case so we don't consider any implicit lines).
Now change the .item rule to: "grid-column: span bar 2 / 2 foo".
That would *also* span to line 2, because now there isn't enough
[explicit] lines (just 1 when we want 2) so we start over
including the implicit lines and now we match lines 4 and 2.
It doesn't make sense that "span bar / X" and "span bar 2 / X"
results in the same start line.
Furthermore, you get even wackier results with
"grid-column: span bar 2 / 5 foo". This leads to "span bar 2"
being a smaller span than "span bar"!
I'm sorry, but I think you misunderstood the intention of
the spec text here. (I don't blame you, the Grid spec sucks
when it comes to clarity IMHO.)
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Comment 3•10 years ago
|
||
FYI, this reftest covers these cases and more:
http://mxr.mozilla.org/mozilla-central/source/layout/reftests/css-grid/grid-placement-definite-implicit-002.html
with the expected layout here:
http://mxr.mozilla.org/mozilla-central/source/layout/reftests/css-grid/grid-placement-definite-implicit-002-ref.html
Reporter | ||
Comment 4•10 years ago
|
||
Thanks for the feedback!
(In reply to Mats Palmgren (:mats) from comment #2)
> To spell it out in detail: the starting point for finding lines
> that match is the edge of the explicit grid (in the direction
> of the span, i.e. line 3 in this case). If the explicit grid
> doesn't have enough matching lines then we should simply continue
> in that direction (i.e. to the left of the explicit grid)
> pretending that every implicit line is a match.
I don't find anything in the spec that defines that starting point for finding the named grid lines.
> The interpretation you suggest leads to some really wacky results.
> For example, add "grid-template-columns: 100px [bar] 100px;"
> to your example above. Then the last item in your example would
> span to line 2 (because the "enough lines" condition is true
> in this case so we don't consider any implicit lines).
> Now change the .item rule to: "grid-column: span bar 2 / 2 foo".
> That would *also* span to line 2, because now there isn't enough
> [explicit] lines (just 1 when we want 2) so we start over
> including the implicit lines and now we match lines 4 and 2.
> It doesn't make sense that "span bar / X" and "span bar 2 / X"
> results in the same start line.
> Furthermore, you get even wackier results with
> "grid-column: span bar 2 / 5 foo". This leads to "span bar 2"
> being a smaller span than "span bar"!
Yes, I realized about this weird behaviors and I was just writing a mail to www-style to check what's the expected result for these cases.
I'll include both questions (original bug report and these weird cases) in the mail now and I'll come back to this bug if the CSS WG decides something different to what's implemented in Firefox.
> I'm sorry, but I think you misunderstood the intention of
> the spec text here. (I don't blame you, the Grid spec sucks
> when it comes to clarity IMHO.)
I think with the current text in the spec my interpretation is right. But I agree that there're very weird cases which make no sense at all.
Anyway, all this stuff about unknown named grid lines using any implicit line is already pretty weird.
Comment 5•10 years ago
|
||
(In reply to Manuel Rego Casasnovas from comment #4)
> I don't find anything in the spec that defines that starting point for
> finding the named grid lines.
The "If not enough lines with that name exist, " is a condition for
the latter part "all implicit grid lines...". This implies we
should start with the explicit lines.
You need to log in
before you can comment on or make changes to this bug.
Description
•