PROPOSED Scalable Vector Graphics (SVG) Working Group Charter

The mission of the Scalable Vector Graphics (SVG) Working Group is to maintain SVG.

Join the Scalable Vector Graphics (SVG) Working Group.

This proposed charter is available on GitHub. Feel free to raise issues.

Charter Status See the group status page and detailed change history.
Start date 1 July 2024
End date 30 June 2026
Chairs TBC
Team Contacts Carine Bournez (0.05 FTE)
Meeting Schedule Teleconferences: topic-specific calls may be held as needed.
Face-to-face: we may meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants.

Motivation and Background

Scalable Vector Graphics (SVG) describes graphics in a way that is scalable to different device resolutions in a manner that is accessible, stylable, and scriptable.

Scope

The SVG WG maintains the deliverables listed in this charter. They consist of the following technologies, all of which are in scope for the SVG Working Group:

  • A syntax for retained-model structured graphics. Both XML and HTML syntaxes are supported and CSS is used for styling.
  • A rendering model which describes how SVG elements are rendered.
  • An object model and set of APIs, to support scripting and user interaction.

The SVG WG's focus in this charter period is on maintenance and interoperability testing of the core SVG specification, to ensure specification quality, test quality and completeness for the existing features.

Changes to the specification will be made as necessary, to improve integration with CSS and HTML for animations, styling, layout and semantics.

However, the Working Group will not introduce new features and will not incubate new proposals. Other fora like the SVG CG or WICG are natural places for incubation, experimenting and testing new features.

Out of Scope

The following features are out of scope, and will not be addressed by this Working group.

  • changes to the HTML parsing algorithm.

Deliverables

Updated document status is available on the group publication status page.

Draft state indicates the state of the deliverable at the time of the charter approval. The Working Group intends to publish the latest state of their work as Candidate Recommendation (with Snapshots). SVG2 progress to further stages on the Recommendation track is dependent on increased participation level in the group.

Normative Specifications

The SVG Working Group will deliver the following W3C normative specifications:

Scalable Vector Graphics (SVG) 2

This specification defines the features and syntax for Scalable Vector Graphics (SVG) Version 2. SVG is a language based on XML for describing two-dimensional vector and mixed vector/raster graphics. SVG content is stylable, scalable to different display resolutions, and can be viewed stand-alone, mixed with HTML content, or embedded using XML namespaces within other XML languages. SVG also supports dynamic changes; script can be used to create interactive documents, and animations can be performed using declarative animation features or by using script.

Draft state: Candidate Recommendation

Expected completion: undetermined
Adopted Working Draft: Scalable Vector Graphics (SVG) 2, 04 October 2018.
Reference Draft: Scalable Vector Graphics (SVG) 2, 04 October 2018. Exclusion period began 04 October 2018; Exclusion period ended 03 December 2018.
Exclusion Draft Charter: SVG WG, 2017-18.

SVG Accessibility API Mappings

This specification allows SVG authors to create accessible rich internet applications, including charts, graphs, and other drawings by extending the "Core Accessibility API Mappings 1.2" and the "Accessible Name and Description: Computation and API Mappings 1.2" specifications. This specification will be developed in collaboration with the Accessible Rich Internet Applications Working Group.

Draft state: Working Draft

Expected completion: undetermined
Adopted Working Draft: SVG Accessibility API Mappings, 10 May 2018.
Reference Draft: SVG Accessibility API Mappings, 26 February 2015. Exclusion period began 26 February 2015; Exclusion period ended 26 July 2015.
Exclusion Draft Charter: SVG WG, 2017-18.

Other Deliverables

Other non-normative documents may be created such as:

  • Use case and requirement documents;
  • Test suite and implementation report for the specification;
  • Primer or Best Practice documents to support web developers when designing applications.

Success Criteria

Each module is expected to have at least two independent implementations of each of the features it defines, and to provide evidence for this claim based on tests. The Working Group is therefore expected to proactively work on writing, reviewing, and maintaining tests. Doing so concurrently with its work on specification text is recommended; among other benefits, it helps minimize accidental divergence between implementations and specifications, test results may also inform discussions on specifications, and failing test may stimulate implementers to update their implementations accordingly. Testing efforts should be conducted via the Web Platform Tests project.

Each specification should contain a section detailing all known security and privacy implications for implementers, Web authors, and end users.

Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification 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.

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

The SVG Working Group expects to follow the TAG Web Platform Design Principles.

Coordination

For all specifications, the SVG Working Group will seek horizontal review for accessibility, internationalization, 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 SVG Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The SVG 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 specification following a review.

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

W3C Groups

CSS Working Group
Coordinate on integration of CSS features and properties into SVG, and vice versa.
Accessible Rich Internet Applications (ARIA) Working Group
Coordinate on SVG and graphics-related ARIA deliverables. In particular, members of the SVG WG are strongly encouraged to also join the ARIA WG to enable timely progress on the following ARIA deliverables related to SVG:
WAI-ARIA Graphics Module
This specification defines semantic roles specific to web graphics, for use with WAI-ARIA.
Graphics Accessibility API Mappings
This specification defines the mapping between the WAI-ARIA Graphics Module and OS platform accessibility application programming interfaces.
Accessible Platform Architectures Working Group
Coordinate on accessible SVG.
Web Application Security Working Group
Coordinate on security of SVG.
SVG Community Group
This group provides a lightweight venue for proposing, incubating and discussing new SVG features.

External Organizations

WHATWG
Coordinate on integration of SVG and HTML, and on compatibility with the Canvas API specifications.
ISO/IEC SC29 WG11
For coordination on Core SVG, which originated with the OFF SVG table.

Participation

The Working Group is expected to have a Chair and participating contributors acting as maintainers for the specifications. The Chair is expected to guide contributors on how to make changes to the specifications, and, where appropriate, to make sure fixes to the specification have an accompanying web platform test.

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 Conduct.

Communication

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 specifications will be developed in public repositories 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 SVG Working Group home page.

Teleconferences are not expected, but can be conducted on an as-needed basis.

This group primarily conducts its technical work on GitHub issues. The public is invited to review, discuss and contribute to this work.

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 5.2.1, Consensus). 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.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

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.

This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) 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.

Licensing

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, Advisory Committee Review of a Charter):

Charter Period Start Date End Date Changes
Initial Charter 1998-07-24 2001-05-31 none
Rechartered 2001-06-10 2003-06-30 none
Rechartered 2003-10-07 2004-03-31 Switched to W3C Current Patent Practice
Rechartered 2004-12-20 2006-09-30 Switched to W3C Patent Policy
Charter Extension 2006-09-21 2007-10-01
Charter Extension 2007-11-26 2008-01-31
Rechartered 2008-04-16 2010-04-30 continue to develop SVG 1.2 and to maintain SVG 1.1
Charter Extension 2010-04-28 2010-07-30
Charter Extension 2010-10-04 2011-01-31
Charter Extension 2011-06-01 2011-07-31
Rechartered 2012-03-20 2014-03-31 Contains new deliverables...
Rechartered 2014-10-23 2016-10-31 zoom media feature, Motion Path, Accessibility and Web Performance joint work. removes the Graphics API and Tiles and Layering
Charter Extension 2016-11-02 2017-01-31
Rechartered 2017-08-02 2018-06-30 Restricted to Core SVG 2 and SVG Accessibility API Mappings. New features only after.
Charter Extension 2018-07-01 2018-11-30
Rechartered 2019-03-22 2021-03-31 Add Native SVG deliverable, focus on SVG2 testing and consider incubated new features.
Charter Extension 2021-03-31 2022-01-31
Rechartered 3 March 2022 29 February 2024 Switch to Patent Policy 2020. Allow pure maintenance.
Charter Extension 2024-03-01 2024-06-30
Rechartered (this charter) 2024-07-01 2026-06-30

Change log

Changes to this document are documented in this section.