SVG Filter Requirements

W3C Working Draft

This version:
Latest version:
Erik Dahlström <ed@opera.com>


This document lists the design principles and requirements for the creation of a SVG specification related to filters.

Status of this Document

This is a W3C Working Draft for review by W3C Members and other interested parties. It is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C Recommendations and other technical documents, including Working Drafts and Notes, can be found at http://www.w3.org/TR/

This is the first release of the SVG Filter Requirements. It is expected that this document will progress through a number of working drafts, including "Last Call", before being published in final form.

This document was developed by the Scalable Vector Graphics (SVG) working group as part of the W3C Graphics Activity. The authors of this document are the SVG Working Group members.

Feedback on this document should be sent to the email list public-svg-filters@w3.org. This is an archived public list specific to the issues of SVG Filters. Public discussion of issues related to vector graphics on the Web and SVG in particular takes place on the the public mailing list of the SVG Working Group (list archives). To subscribe send an email to www-svg-request@w3.org with the word subscribe in the subject line.

The latest information regarding patent disclosures related to this document is available on the Web. As of this publication, the SVG Working Group are not aware of any royalty-bearing patents they believe to be essential to SVG.

This section represents the status of this document at the time this version was published. It will become outdated if and when a new version is published. The latest status is maintained at the W3C.


The SVG specificationis a W3C recommendation that describes two-dimensional graphics in XML.


The following key words and phrases used throughout this document are defined here for clarity. The terms Must, Should, and May are used to specify the extent to which an item is a requirement for the SVG working group in defining SVGP. These recommendations should not be mistaken as a guide to implementors.

  1. 'Must' means that the item is an absolute requirement.
  2. 'Should' means that there may exist valid reasons in particular circumstances to ignore the item, but the full implications must be understood and carefully weighed before choosing a different course.
  3. 'May' means that item will be considered, but further examination is needed to determine if the item should be treated as a requirement.
  4. 'SVG' refers to SVG in general without reference to any version or profile.
  5. 'SVG 1.0' refers to the original SVG specification.
  6. 'SVG 1.1' refers to the modularized version of SVG 1.0.
  7. 'SVG 1.2' refers to the next release of SVG and is planned to reference this specification.
  8. 'SVGF' refers to SVG Filter, an SVG specification for filtering.

Usage Scenarios

The following usage scenarios illustrate some of the ways in which SVG Filters might be used for various applications.

Making drop shadows Filtering the input (e.g. text or bitmaps) to produce drop shadows.

Changing color tone Filtering the input to become e.g. sepia-toned or black and white.

Special Filter Considerations

Memory and processor requirements A filter effect may require significant memory or processing resources.


  1. General Requirements
    1. Any valid SVG 1.1 filter must be a valid SVGF filter.
    2. Conformance criteria for SVGF must be produced. The criteria should be separated into sections relevant to particular application types (eg. SVG files/document fragments, SVG generators, SVG viewers, SVG printers, etc.)
    3. Software or documents must pass the relevant criteria to be able to claim conformance to the particular application type.
    4. A conformance test suite must be developed for SVGF. The test suite must be made publicly available. Conformance test suites for other uses of SVGF (e.g. prepress guidelines) may be developed.
    5. A specification referencing SVGF may declare that 'enableBackground' is not supported when used in conjunction with that specification. If so, then support for 'backgroundAlpha' and 'backgroundImage' must be excluded as well.
    6. A specification referencing SVGF must declare if animations applies when a 'filter' chain is in its scope.
  2. Scripting
    1. A dynamic SVGF viewer must support the SVGF scripting feature set.
  3. Animation
    1. A dynamic SVGF viewer must support animation of all properties listed as animatable.


SVG 1.1
Scalable Vector Graphics (SVG) 1.1 Specification, Jon Ferraiolo, Jun Fujisawa, Dean Jackson, editors, W3C, 14 January 2003 (Recommendation). See http://www.w3.org/TR/SVG11/
SVG 1.1/1.2/2.0 Requirements
SVG 1.1/1.2/2.0 Requirements Document, Dean Jackson, editor, W3C, 22 April 2002. See http://www.w3.org/TR/SVG2Reqs/
Mobile SVG Profiles
Mobile SVG Profiles: SVG Tiny and SVG Basic, Tolga Capin, editor, W3C, 14 January 2003 (Recommendation). See http://www.w3.org/TR/SVGMobile

Author List

The authors of this specification are the participants of the W3C SVG Working Group.