The mission of the SVG Working Group, part of the Graphics Activity, is to continue the evolution of Scalable Vector Graphics as a format and a platform, and enhance the adoption and usability of SVG in combination with other technologies.
|End date||30 April 2010|
|Confidentiality||Proceedings are public|
|Initial Chairs||Erik Dahlström (Opera Software ASA),
Andrew Emmons (W3C Invited Experts)
(FTE %: 30)
|Doug Schepers (W3C/Keio)|
|Usual Meeting Schedule||Teleconferences: Twice Weekly
Face-to-face: 3-4 per year
This group will produce incremental, market-driven revisions to the SVG format, suitable for both desktop and mobile systems, and will maintain and clarify existing SVG specifications.
Native implementation of SVG in desktop browsers has increased dramatically, with substantial support in Opera, Mozilla Firefox, and WebKit/Safari, as well as browser plug-ins by smaller vendors. With this increased interest, the SVG specifications have had greater scrutiny and more critical feedback regarding features and consistency. Response to market pressures and the need to cover gaps in underlying technologies resulted in a broad feature set for SVG 1.2 Tiny, which drew criticism. In response, the SVG Working Group has factored out reusable functionality to the WebAPI Working Group for use in other specifications, and will continue to improve its activities in the following ways:
In order to meet the goal of more timely specifications, work will continue on modularization of feature sets. Additional goals of modularization are to ease incremental implementation and specification review, to allow greater reuse of existing features in other specifications (e.g. CSS or HTML), and to address requirements identified in the SVG 1.2 timeframe that could not be fully realized in the SVG 1.2 Tiny specification. Several modules are planned for publication, including:
In particular, SVG will consider the applicability of enhancements to the core language to both desktop and resource-limited devices, such as mobile devices and printers.
To allow more advanced design features and efficient decorative effects, there will be attention paid to new stroking and filling options, including pseudo-3D (2.5D) effects by means of new gradients, filters, and non-affine transformations, with authoring tips for their use.
The work on SVG will move toward more widespread implementation and greater interoperability, in multiple browsers across multiple platforms, and created by multiple authoring or generation tools. See the activity statement for the overall goals and rationale of this activity area.
In order to ensure that the language meets the needs of the community, including designers and casual authors in addition to developers, the SVG WG will engage with the SVG Interest Group, which will have a lower barrier of entry and fewer responsibilities than the SVG WG itself. This charter will accomodate the creation of new specification modules in order to address the needs raised by the reports of the SVG IG and workshops.
The scope of this charter will include the creation of a new version of the SVG specification that improves on the core SVG language, upon which the individual module extensions may be attached. The details of this new version will depend upon the input of SVG WG members and the needs outlined by the SVG Interest Group.
There are several technologies closely related to SVG, but which are under the purview of other activities within W3C, and are detailed under Dependencies and Liaisons.
Additionally, several features that originated in the SVG specification, but which are not of exclusive use to SVG have been moved to other Working Groups, or been superseded by other work in W3C. Evaluation of the status of this work will continue, to make best use of W3C resources. Consequently, this charter will drop items from the SVG Working Group's previous charter, including (but not limited to):
The working group will deliver at least the following:
Specification transition estimates and other milestones.
|Note: The group will document significant changes from this initial schedule on the group home page.|
|Compositing||February 2008||July 2008||August 2008||February 2009||May 2009|
|Filters||May 2007||March 2008||May 2008||October 2008||February 2009|
|Gradients||June 2008||November 2008||January 2009||February 2009||June 2009|
|Layout Requirements and Use Cases||May 2008||September 2008||-||-||-|
|Layout||December 2008||July 2009||September 2009||November 2009||February 2010|
|Masking and Clipping||July 2008||December 2008||February 2009||May 2009||July 2009|
|Media Access Events||October 2006||January 2008||March 2008||October 2008||December 2008|
|Paint Servers||June 2008||November 2008||January 2009||February 2009||June 2009|
|May 2007||January 2008||March 2008||October 2008||December 2008|
|Transformations||June 2008||November 2008||January 2009||February 2009||June 2009|
|Vector Effects||September 2008||January 2009||March 2009||October 2009||December 2009|
|WebFonts||June 2008||December 2008||February 2009||May 2009||July 2009|
|SVG 1.1 Full 2nd Edition||-||-||-||-||March 2008|
|SVG 1.2 Tiny||December 2003||March 2006||August 2006||May 2008||October 2008|
|SVG 1.2 Full Modular||November 2008||April 2009||July 2009||December 2009||June 2010|
Furthermore, SVG Working Group expects to follow these W3C Recommendations:
To be successful, the SVG Working Group is expected to have 10 or more active participants for its duration. Effective participation to SVG Working Group is expected to consume one work day per week for each participant; two days per week for editors. The SVG Working Group will allocate also the necessary resources for building Test Suites for each specification (some effort for which may also come from members of the SVG Interest Group Test Suite Task Force) and maintaining existing specifications (including publication of errata).
Each organization may have up to two participants in the SVG Working Group for purposes of technical discussion, issue resolution, voting, and other issues of process, but may additionally allocate any number of participants for dedicated tasks, such as creating or maintaining the test suites, or providing tutorial materials, subject to member review and approval.
Participants are reminded of the Good Standing requirements of the W3C Process.
Feedback to this group may be sent to the public mailing list firstname.lastname@example.org (archive), or submitted to the public issue tracking system available from the feedback page. This group will post minutes to, and primarily conduct its technical work on, the mailing list email@example.com (public archive).
Information about the group, including news and links to specifications and membership, is available from the SVG WG Public page. Member-only information (contact details for face-to-face meetings, teleconferences, etc.) is available from the SVG WG Member page, and on the Member-only mailing list firstname.lastname@example.org (member archive).
As explained in the Process Document (section 3.3), this group will seek to make decisions when there is consensus. When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should record a decision (possibly after a formal vote) and any objections, and move on.
This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.
This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations 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 W3C Patent Policy Implementation.
This charter for the SVG Working Group has been created according to section 6.2 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.
Please also see the previous charter for this group.
$Date: 2008/04/16 20:49:23 $