This document is intended to be used as a guideline for the testing activities related to the CSS Grid Layout Level 1 spec [[!css3-grid-layout]]. Its main goal is to provide an overview of the general testing areas, possible caveats and testing aspects not immediately apparent from the spec. Also, it provides a means of tracking the progress of the CSS Grid Layout spec testing.

This document is not meant to replace the spec in determining the normative and non-normative assertions to be tested, but rather complement it.


As CSS moved away from the monolithic development of CSS 2.1 to the modular development of CSS 3, the number of proposed new features and the complexity of the layout landscape have increased dramatically. While this directly translates to increased flexibility and agility in adopting and implementing new CSS features, it also increases the complexity of testing CSS features and the need for coordinating the testing efforts. Also, the need for testing coordination increases as crowd-sourcing efforts like Test the Web Forward present people less familiar with the processes and policies of the W3C with the opportunity to contribute new tests.

Except when defining new behaviors or redefining old behaviors, the implicit assumption for new CSS modules is that they play nicely with other modules or properties defined in CSS 2.1 [[!CSS21]]. As CSS Grid Layout is a spec that touches many aspects of layout, styling and CSSOM, it's not unreasonable to want to test the spec against these implicit assumptions, too.

This testing strategy document is meant to complement the CSS Grid Layout spec and the existing test suite by providing an overview of the testing areas (especially the less apparent ones) and tracking the progress of the testing activities against these test areas.


To ensure a comprehensive test suite with useful, high quality tests, a number of goals are proposed. They range from process goals (how to conduct testing) to implementation goals (how to write good tests).

Enabling easy test contribution

An important vector in successfully testing CSS Grid Layout is to enable easy test contributions, both from W3C partners and from non-W3C members that wish to contribute. This is achieved by clearly marking and explaining the areas that need testing, linking to existing tests, and general testing progress.

Providing guidance on testing

In order to increase the quality of the test contributions, this document offers a set of guidelines for conducting testing (see ) and a testing progress tracker to increase the surface coverage of tests (see ).

Creating automation-friendly tests

In terms of actual tests produced for the CSS Grid Layout specification, the main goal is to ensure that most tests are automatable (i.e. they're either reftests or use testharness.js). Even where manual tests are absolutely necessary they should be written so that they can be easily automated – as there are ongoing efforts to make WebDriver [[webdriver]] automated tests a first class citizen in W3C testing. This means that even if a manual test requires user interaction, the validation or PASS/FAIL conditions should still be clear enough as to allow automatic validation if said interaction is later automated.


As spec testing cannot be realistically separated from testing a particular implementation (except for the very simple cases), the approach proposed for testing is one that tries to first cover as many areas as possible, instead of deep diving on a certain feature or aspect of the spec first. A side benefit of this approach is that the spec tests can be used at any time to gauge the level of support of a certain implementation.

Having this breadth-first approach in mind, tests will be created for the testing areas listed in . Testing will be done in multiple passes, each aimed at covering more specific edge-cases.

Testing areas

Explicit testing areas

These are testing areas normatively defined by the spec. They cover things explicitly or implicitly defined in the CSS Grid Layout spec. Please note that while detailed, this list is not necessarily exhaustive and normative behaviors may not be contained in it. When in doubt, consult the CSS Grid Layout spec or ask a question on the mailing list adding [css-grid] to the subject.

Grid Containers (grid-model)

  • grid and inline-grid values for display property [#627].
  • Grid container’s margins do not collapse with the margins of its contents [#661].
  • column-* properties have no effect on a grid container [#628].
  • float and clear have no effect on a grid item [#629].
  • float affects to the computed value of display on grid items [#630].
  • vertical-align has no effect on a grid item [#631].
  • first-line and first-letter do not apply to grid containers [#632].
  • Sizing grid containers [#638].

Grid Items (grid-items)

  • Each child of a grid container becomes a grid item [#639].
  • Each contiguous run of text that is directly contained inside grid container is wrapped in an anonymous grid item [#640].
  • visibility property.
    Still undefined in the spec.
  • order property [#641].
  • Static position [#642 & #643].
  • Z-axis ordering:
    • z-index property [#677].
  • Minimum size of grid items [#799].

The Explicit Grid (grid-definition)

  • Track sizing:
    • grid-template-columns and grid-template-rows properties [#644].
    • <track-size>: length, percentage, max-content, min-content, minmax(min, max), auto.
    • Named grid lines (<custom-ident>) [#645].
    • repeat() notation [#646].
    • Flexible lengths: fr unit [#647].
    • subgrid keyword.
      Subgrid feature is currently at-risk.
    • Resolved values [#648].
  • Named areas:
    • grid-template-areas property [#649].
    • Implicit named grid lines [#650].
    • Implicit named areas [#651].
  • Explicit grid shorthand:
    • grid-template property [#652].

The Implicit Grid (implicit-grids)

  • grid-auto-rows and grid-auto-columns properties [#662].
  • grid-auto-flow property [#663].

Grid Definition Shorthand (grid-shorthand)

  • grid property [#664].

Placing Grid Items (placement)

  • Common patterns:
    • Named areas [#665].
    • Numeric indexes and spans [#666].
    • Named lines and spans [#667].
    • Auto placement [#668].
    • Auto sizing siblings.
      Subgrid feature is currently at-risk.
  • Line-based placement:
    • grid-row-start, grid-column-start, grid-row-end and grid-column-end properties [#669].
    • Grid placement conflict handling [#670].
  • Placement shorthands:
    • grid-column, grid-row and grid-area properties [#671].
  • Absolutely-positioned grid items [#672].
  • Grid item placement algorithm [#683].

Alignment (alignment)

  • Aligning with auto margins [#673].
  • Row-axis alignment:
    • justify-self and justify-items properties. [#674].
  • Column-axis alignment:
    • align-self and align-items properties [#675].
  • Aligning the grid:
    • justify-content and align-content properties [#676].
  • Grid baselines [#678].

Track Sizing Algorithm (layout-algorithm)

  • Content-based track sizing [#679].
  • Grow tracks using free space [#680].
  • Flexible tracks [#681].

Fragmenting Grid Layout (pagination)

  • Fragmentation algorithm [#682].

Specification examples

The spec examples should become tests (maybe some of them need to be defined as manual tests). This will allow to increase the coverage with more tests, but also to check the spec itself.

Implicit testing areas

These are testing areas either normatively defined in other specs that explicitly refer to the CSS Grid Layout spec or simply not explicitly defined, but implied by various aspects of the spec. Please note that while detailed, this list is not necessarily exhaustive and normative behaviors may not be contained in it. When in doubt, consult the CSS Grid Layout spec or ask a question on the mailing list adding [css-grid] to the subject.

Below is the list of implicit testing areas:

People and responsibilities

Below is a list of people you should reach out to if you have any questions related to this document or testing CSS Grid Layout in general:

Test progress tracking

Currently test progress tracking is done via GitHub milestones and issues.