This document is intended to be used as a guideline for the testing activities related to the CSS Regions spec [[!css3-regions]]. 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 Regions 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 Regions 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 Regions 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 Regions 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, linked 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 Regions, 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 on-going efforts to make WebDriver [[webdriver]] automated tests a first class citized 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.

Risks and mitigation

There are a number of risks associated with creating a high-quality test suite for CSS Regions. The most important ones are listed below.

Implicit interactions with a lot of other specs (and commonly accepted browser behavior)

The CSS Region spec introduces a significant change in the way layout can be done and as a consequence, many of the assumptions that hold in the context of CSS 2.1 must be re-validated in the context of CSS Regions. In the meanwhile, a lot of new layout modules have been proposed, with various degrees of implementor support and maturity. Also, non-CSS specific specs introduced concepts that affect how style is propagated (e.g. Shadow DOM [[shadow-dom]]) or how elements are rendered and interact with their containing documents (e.g. <iframe seamless> in HTML 5 [[HTML5]]).

All the above factors increase the testing surface and the number of the possible cases that might need an explicitly specified behavior in order to ensure intuitive and predictable results as well as stable interaction with widely used browser features (that might not be yet so strictly specified).

In terms of specifying the expected behavior, the current approach is to try and specify it for specs that are final or nearly-final and to just make a note of the possible interactions and unspecified behaviors in the case of specs that are still in flux. In exceptional cases, a new spec might be created to cater for the needs of multiple specs (e.g. the CSS Fragmentation spec [[css3-break]]).

Big number of tests required

Add here the estimation of tests required produced by W3C test coverage tool. If possible, provide a better informed guess on the number of tests.

Given the complexity of the spec, a big number of tests will need to be created to produce a test suite that can ensure interoperability between implementations.

In this context, the main purpose of this document is to provide useful informations for creating and contributing tests in an effective manner in terms of coverage and test quality.


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 Regions 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 Regions spec or ask a question on the mailing list.

Below is the list of explicit testing areas:

  1. Proper parsing of the CSS properties and rules, rendering according to the spec.
    • flow-into and flow-from; flow-into should be tested both with and without the content switch
    • region-fragment
    • fragmentation additions: region-avoid, region-always – see [[!css3-break]] for details
  2. Nested named flows and cycle detection
  3. Multi-column regions
  4. Regions' pseudo-elements
  5. Region auto-sizing (regions visual formatting details)
  6. CSSOM - interfaces implemented, behavior according to the spec
    regionfragmentchange might be removed from this level of the spec. Adjust the contents of the list below accordingly.
    • NamedFlow interface
    • Region interface
    • regionoversetchange event
    • regionfragmentchange event
  7. DOM additions
    • getClientRects() and getBoundingClientRects()
    • offsetTop, offsetBottom, offsetLeft, offsetRight and offsetParent

Region styling has been removed from the spec waiting for it to be defined in the page styling spec. This is a reminder for adding section here related to page/region styling once this gets specified.

Implicit testing areas

These are testing areas either normatively defined in other specs that explicitly refer to the CSS Regions spec (e.g. [[!css3-break]]) or simply not explicitly defined, but implied by various aspects of the spec (e.g. processing model, CSS 2.1 compliance, etc.). 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 Regions spec or ask a question on the mailing list.

Below is the list of implicit testing areas:

  1. CSS Regions and layout modules:
    • Floats
    • Positioned elements
    • Intrinsic and extrinsic sizing [[css3-sizing]] and auto-sized regions
    • CSS Flexbox [[css3-flexbox]]
    • CSS Multicolumn [[css3-multicol]] content in named flows
    • CSS Shapes [[css-shapes-1]]
    • CSS Grid Layout [[css3-grid-layout]]
  2. CSS Regions and different types of elements
    • List items
    • <iframe>
      • fragmentation of <iframe> and <iframe seamless>
    • <video>
    • <canvas>
    • <table>
  3. Stacking contexts
  4. Fragmentation
    • Named flow content fragmentation
    • Regions fragmentation
  5. Dynamic content
    • Changing the content of the named flows or of the region chain at runtime
    • Interactive content: contentEditable, designMode and input elements
  6. User input events (e.g. mouse, touch, keyboard); this includes event propagation
  7. User action pseudo-classes (e.g. :active, :hover)
  8. Writing modes
  9. Transforms
  10. Transitions and animations
  11. Shadow DOM
    • Regions inside shadow trees
    • Flowing content from shadow trees
  12. Content clipping and overflowing
  13. Pseudo-elements in named flow contents

Region styling has been removed from the spec waiting for it to be defined in the page styling spec. This is a reminder for adding section here related to page/region styling interacting with <style scoped> once this gets specified.

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 Regions in general:

Test progress tracking

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