[CSS Grid Layout] computed grid track sizes should be pixel values

• Component: CSS
• Status: RESOLVED DUPLICATE

[Julien Chaffraix]

Per section 6.5.2:

"The computed size of all Grid Tracks as returned for the grid-rows and grid-columns properties are normalized to used pixel values."

I missed this part when implementing -webkit-grid-rows and -webkit-grid-columns so we currently don't always return the pixel values.

[Xan Lopez]

(In reply to comment #0)
> Per section 6.5.2:
> 
> "The computed size of all Grid Tracks as returned for the grid-rows and grid-columns properties are normalized to used pixel values."
> 
> I missed this part when implementing -webkit-grid-rows and -webkit-grid-columns so we currently don't always return the pixel values.

(Note, I think the right section is 4.5.2)

Dumping my brain here, since I think this might be doable. Correct me if I'm wrong but my understanding is that what we'd need to hack around here would be CSSComputedStyleDeclaration::valueForGridTrackBreadth, right? In that case:

- With the patch from bug #103335 the computed size for fixed and viewport percentage sizes is correctly returned as pixels.
- Percentage is not, mostly because I'm not sure of what value to use as the "max size" in the valueForLength call. AFAIK we really need that value for things to work correctly.

So maybe we can land bug #103335, then I can work in this bug to fix percentage. After that I'd move on to figure out the whole calc() scenario (see bug #103761), and I think we'd be mostly set.

[Julien Chaffraix]

This bug was filed because I didn't understand the different between "computed value" and "serialized value". What getComputedStyle returns is the "serialized value" and those are not covered by the grid spec.

I don't know what IE 10 returns but from a talk with Tab, it seems that what we do is right (ie if the value can be trivially serialized to an absolute value we do it, if not, return the value as applied).

[Tab Atkins]

(In reply to comment #2)
> This bug was filed because I didn't understand the different between "computed value" and "serialized value". What getComputedStyle returns is the "serialized value" and those are not covered by the grid spec.
> 
> I don't know what IE 10 returns but from a talk with Tab, it seems that what we do is right (ie if the value can be trivially serialized to an absolute value we do it, if not, return the value as applied).

Almost right.  ^_^

getComputedStyle returns the "resolved value", which is a term we invented to describe what "computed style" meant back in CSS 2.0.  The resolved value === the computed value for all properties, except for a handful of CSS 2.1 properties for which it equals the used value.

Another important distinction, though, is between the computed value and the serialization of the computed value.  For example, the computed value of background-position is two (keyword,length) pairs, but the serialization of the computed value is often just one or two lengths.  "Computed value" is an abstraction that the spec uses, but authors only have access to the serialization.

Finally, for this bug itself, the current Grid spec shows significant confusion over what a computed value is in some properties.  I'll fix this up before the end of the month in a rewrite, but for now I've just given Julien private advice on how to treat these properties.

[Sergio Villar Senin]

I fixed this in Blink. We should merge this:

    [CSSGridLayout] getComputedStyle is wrong for grid-template-{rows|columns}

    Specs mandate to return the used value instead of the specified value which
    was the one we were using. This requires to force a layout to compute the
    used values. The properties grid-auto-{rows|columns} are not affected by
    this change as the same specified value might result in different used
    values for two different auto-generated tracks.

    Tests have been accordingly updated. Fixed size grids are now being used to
    produce consistent results. Some new test cases were added to check that we
    behave correctly with/without grid sizes and with/without grid items (for
    content-based track sizes).

    https://src.chromium.org/viewvc/blink?revision=161247&view=revision

[Manuel Rego Casasnovas]

*** This bug has been marked as a duplicate of bug 127033 ***