CSS Working Group Charter

The mission of the Cascading Style Sheets (CSS) Working Group is to develop and maintain CSS.

Join the CSS Working Group.

Start date 12 January 2023
End date 12 January 2025
Charter extension See Change History.
Chairs Alan Stearns (Adobe), Rossen Atanassov (Microsoft)
Team Contacts Chris Lilley (0.50 FTE);
Fuqiao Xue (0.10 FTE)
Meeting Schedule Teleconferences: 1-hour calls will be held weekly.
Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year.


Cascading Style Sheets (CSS) is a style sheet language that allows authors and users to attach style (e.g., from fonts and spacing to filter effects and style animations) to structured documents and Web applications. By separating the presentation style from the content, CSS simplifies Web authoring and site maintenance. It supports media-specific style so that authors may tailor the presentation to different devices and capabilities.

The CSS WG develops a single deliverable, the CSS specification. It consists of the following, somewhat independent technologies, all of which are in scope for the CSS Working Group:

The CSS WG not only develops CSS, but also checks that properties needed by other working groups and which could occur in a style sheet together with CSS properties, are compatible with CSS in general and consistent in their naming schemes. This affects properties such as those of SVG and Device Independence (such as media features).

Part of the work of the working group is also to develop test suites for the various modules it publishes.

Another part is to maintain errata and, when needed, publish revised versions of the various modules.


There is a single deliverable, the CSS specification. The CSS specification is large, and is divided into a series of modules.

More detailed milestones and updated publication schedules are available on the group publication status page.

Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation within this charter period. Deliverables without expected completion dates are not projected to become Recommendation within this charter period.

This list of modules is not exclusive: The WG may also create new CSS modules, within its scope. Also, it may split or merge CSS modules. If no participant in the group believes a proposed module is out of scope, and the group has consensus to add it, the group may add a new module. If the participants who object sustain their objection after discussion, a re-charter to clarify the scope may be needed.

Normative Modules

The Working Group will deliver the following W3C normative modules:

Other Deliverables


This document collects together into one definition all the specs that together form the current state of Cascading Style Sheets (CSS) as of 2022. The primary audience is CSS implementers, not CSS authors, as this definition includes modules by stability, not Web browser adoption rate.

Draft state: No draft, published annually.

Expected completion: Q4 2022


This document collects together into one definition all the specs that together form the current state of Cascading Style Sheets (CSS) as of 2023. The primary audience is CSS implementers, not CSS authors, as this definition includes modules by stability, not Web browser adoption rate.

Draft state: No draft, published annually.

Expected completion: Q4 2023


This document collects together into one definition all the specs that together form the current state of Cascading Style Sheets (CSS) as of 2024. The primary audience is CSS implementers, not CSS authors, as this definition includes modules by stability, not Web browser adoption rate.

Draft state: No draft, published annually.

Expected completion: Q4 2024


  • Q2 2023: REC for CSS Values and Units Module Level 3
  • Q2 2023: REC for CSS Custom Properties for Cascading Variables Module Level 1
  • Q2 2023: REC for CSS Flexible Box Layout Module Level 1
  • Q3 2024: REC for Compositing and Blending Level 1
  • Q4 2024: REC for CSS Conditional Rules Module Level 3
  • Q2 2025: REC for CSS Backgrounds and Borders Module Level 3
  • Q1 2025: REC for CSS Cascading and Inheritance Level 4
  • Q2 2025: REC for CSS Image Values and Replaced Content Module Level 3
  • Q2 2026: REC for Media Queries Level 4

Success Criteria

The CSS Working Group's work is considered a success if there are multiple, independent, interoperable implementations of its modules that are widely used.

In order to advance to Proposed Recommendation, each module is expected to have at least two independent implementations of every feature defined in the module.

There should be testing plans for each module, starting from the earliest drafts.

To promote interoperability, all changes made to modules in Candidate Recommendation or to features that have deployed implementations should have tests. Testing efforts should be conducted via the Web Platform Tests project.

Each module should contain sections detailing all known security and privacy implications for implementers, Web authors, and end users.

Each module should contain a section on accessibility that describes the benefits and impacts, including ways module features can be used to address them, and recommendations for maximising accessibility in implementations.

Modules that reach W3C Recommendation, are considered successful when all of the following are present:

  • Production of stable documents addressing the work items listed in the Deliverables section.
  • Test suites for each module with conformance criteria.
  • Availability of multiple, independent, interoperable implementations of each feature with conformance criteria in each deliverable; as demonstrated by an implementation report (summarizing implementation status against the relevant test suite) for each testable class of product, including user agents.
  • Deployment on multiple types of platform (traditional computers, phones, tablets, accessibility aids, print formatters, and so on).
  • User community and industry adoption of the group deliverables.


For all modules, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each module. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a module following a review.

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

In addition to the above catch-all reference to horizontal review which includes accessibility review, this Working Group will work with the Accessible Platform Architectures Working Group to work on accessible navigation which needs to be addressed coherently across multiple modules, address accessibility issues related to the features of individual modules, and develop new CSS modules to address accessibility use cases where appropriate.

W3C Groups

WebFonts Working Group
The Group coordinates with the WebFonts WG to enable high quality Web typography with downloadable fonts, in particular WOFF and WOFF2.
EPUB 3 Working Group
The group coordinates closely with the EPUB 3 WG on requirements for various aspects of CSS in all types of digital publishing.
Web Platform Incubator Community Group
The CSS WG may adopt promising CSS work incubated in the WICG, provided that RF patent commitments are in place for such work. WICG participants working on CSS-related proposals are expected to coordinate with the CSS WG to ensure timely reviews of their work. Note: No restriction of the CSS WG's ability to adopt proposals developed elsewhere is implied.
Technical Architecture Group
The group coordinates with the TAG on architectural review of CSS modules and to develop an extensible CSS architecture. The Houdini task force is the primary venue for this work, and those modules are published jointly.

External Organizations

The group coordinates with the WHATWG to ensure that HTML only contains constructs that can be rendered with CSS.
The CSS WG is aware of normative references to CSS modules from HTML and will endeavor to maintain their stability, for example by avoiding breaking changes to the referenced portions.


To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this module, and active Editors and Test Leads for each module. The Chairs, module Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.

The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics and Professional Conduct.


Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of modules will be developed on a public repository and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.

Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the CSS Working Group home page.

Most CSS Working Group teleconferences will focus on discussion of particular modules, and will be conducted on an as-needed basis.

This group primarily conducts its technical work via the GitHub issues list, with more general discussion on the public mailing list www-style@w3.org (archive). The public is invited to review and discuss issues, and to post messages to this list.

The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.

Decision Policy

This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.

Decisions are made by consensus of the Working Group. In addition to decisions made on teleconferences or face to face meetings, decisions may also be made by a call for consensus on the public mailing list; consensus to be determined by the chairs after some reasonable interval for objections.

All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director.

This charter is written in accordance with the W3C Process Document (Section 3.4, Votes) and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Web Specifications that can be implemented, according to this policy, on a Royalty-Free basis. For more information about disclosure obligations for this group, please see the licensing information.


This Working Group will use the W3C Software and Document license for all its deliverables.

About this Charter

This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Charter History

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3):

Charter Period Start Date End Date Changes
Initial Charter 28 February 1997 28 February 1999
Rechartered 22 March 1999 31 March 2000
Rechartered 31 July 2001 31 July 2002
Rechartered 15 October 2002 31 August 2004
Charter Extension 22 September 2004 31 March 2005
Rechartered 28 June 2006 31 July 2008
Charter Extension 26 September 2008 31 December 2008
Rechartered 12 December 2008 30 November 2010
Charter Extension 19 November 2010 31 March 2011
Charter Extension 12 July 2011 30 August 2011
Rechartered 14 December 2011 30 September 2013
Rechartered 01 July 2014 15 June 2016
Charter Extension 11 July 2016 30 September 2016
Rechartered 16 September 2016 14 September 2019
Rechartered 3 October 2019 30 September 2022
Rechartered 15 December 2020 30 September 2022 New Patent Policy
Charter Extension 30 September 2022 31 December 2022
This charter 12 January 2023 12 January 2025 Update to latest charter template.