- From: <Kerry.Taylor@csiro.au>
- Date: Wed, 25 Feb 2015 19:49:27 +0000
- To: <harth@kit.edu>, <public-sdw-wg@w3.org>
Web mapping is the obvious one -- but it is assertively out of scope!
> -----Original Message-----
> From: Andreas Harth [mailto:harth@kit.edu]
> Sent: Thursday, 26 February 2015 3:52 AM
> To: public-sdw-wg@w3.org
> Subject: Re: Geospatial decision in W3C SVG WG: Move svg:transform
> mapping to its own spec
>
> Hi,
>
> would that be something to write as a use case? If SVG with
> geo is a requirement that can be derived from a use case, we
> would ensure that SVG/geo shows up somewhere. The tricky bit
> is coming up with a use case that would require SVG/geo.
>
> Cheers,
> Andreas.
>
> On 2015-02-24 11:52, Little, Chris wrote:
> > Kerry, Ed,
> >
> > Just checking that you were aware of this activity, and perhaps we
> should ensure SVG with geo info embedded in metadata is included in a
> SDWWG deliverable at some time.
> >
> > Chris
> >
> > -----Original Message-----
> > From: SVG Working Group repository [mailto:cam+svgwgrepo@mcc.id.au]
> > Sent: Friday, February 13, 2015 4:21 AM
> > To: w3c-svg-wg@w3.org
> > Subject: [svgwg] Move svg:transform mapping to its own spec
> >
> >
> https://github.com/w3c/svgwg/commit/637ae4967c0b923a97c5c8f82ac530d4482
> 3d1a3
> > commit 637ae4967c0b923a97c5c8f82ac530d44823d1a3
> > Author: Dirk Schulze <dschulze@chromium.org>
> > Date: Fri Feb 13 15:18:27 2015 +1100
> >
> > Move svg:transform mapping to its own spec
> >
> > diff --git a/master/coords.html b/master/coords.html
> > index ecf00e8..be645c1 100644
> > --- a/master/coords.html
> > +++ b/master/coords.html
> > @@ -1574,44 +1574,6 @@ object within a containing block that is only
> constrained in one direction.</p>
> > <a
> href="https://docs.google.com/presentation/d/1POUiroOBbLmXYlQKf0pIR8zVk
> HWH9jRVN-w8A4aNsIk/">examples</a>
> > provided by David Vest.</p>
> >
> > -<h2 id="GeographicCoordinates">Geographic coordinate systems</h2>
> > -
> > -<p>In order to allow interoperability between SVG content generators
> > -and user agents dealing with maps encoded in SVG, the use of a
> common
> > -metadata definition for describing the coordinate system used to
> > -generate SVG documents is encouraged.</p>
> > -
> > -<p>Such metadata must be added under the <a>'metadata'</a> element
> of
> > -the topmost <a>'svg'</a> element describing the map, consisting of
> an
> > -RDF description of the Coordinate Reference System definition used
> to
> > -generate the SVG map [<a href='refs.html#ref-RDF-PRIMER'>RDF-
> PRIMER</a>]. Note that
> > -the presence of this metadata does not affect the rendering of the
> SVG
> > -in any way; it merely provides added semantic value for applications
> > -that make use of combined maps.</p>
> > -
> > -<p>The definition must be conformant to the XML grammar described in
> > -<a
> href="http://portal.opengeospatial.org/files/?artifact_id=20509"><cite>
> GML 3.2.1</cite></a>,
> > -an OpenGIS Standard for encoding common CRS data types in XML
> > -[<a href='refs.html#ref-GML'>GML</a>]. In order to correctly map
> > -the 2-dimensional data used by SVG, the CRS must be of subtype
> > -<strong>ProjectedCRS</strong> or <strong>Geographic2dCRS</strong>.
> The
> > -first axis of the described CRS maps the SVG <var>x</var>-axis and
> the
> > -second axis maps the SVG <var>y</var>-axis.</p>
> > -
> > -<p>The main purpose of such metadata is to indicate to the user
> agent
> > -that two or more SVG documents can be overlayed or merged into a
> single
> > -document. Obviously, if two maps reference the same Coordinate
> Reference
> > -System definition and have the same SVG <a>'transform'</a> property
> > -value then they can be overlayed without reprojecting the data. If
> > -the maps reference different Coordinate Reference Systems and/or
> have
> > -different SVG <a>'transform'</a> property values, then a specialized
> > -cartographic user agent may choose to transform the coordinate data
> to
> > -overlay the data. However, typical SVG user agents are not required
> > -to perform these types of transformations, or even recognize the
> > -metadata. It is described in this specification so that the
> connection
> > -between geographic coordinate systems and the SVG coordinate system
> is
> > -clear.</p>
> > -
> > <h2 id="DOMInterfaces">DOM interfaces</h2>
> >
> > <h3 id="InterfaceSVGPointList">Interface SVGPointList</h3>
> > @@ -2052,8 +2014,6 @@ interface <b>SVGTransform</b> {
> > <p>If <var>value</var> could not be parsed as a
> > <a><transform-function></a>, then a <a
> href="http://dvcs.w3.org/hg/domcore/raw-
> file/tip/Overview.html#syntaxerror">SyntaxError</a>
> > is thrown.</p>
> > - <p class='issue'>The CSS Transforms specification does not
> have
> > - a grammar for <a><transform-function></a> yet.</p>
> > </div>
> > </dd>
> > </dl>
> > diff --git a/specs/transform/Overview.bs
> b/specs/transform/Overview.bs
> > new file mode 100644
> > index 0000000..4c1c144
> > --- /dev/null
> > +++ b/specs/transform/Overview.bs
> > @@ -0,0 +1,325 @@
> > +<h1>svg:transform for mapping</h1>
> > +<pre class='metadata'>
> > +Level: 1
> > +Status: ED
> > +ED: http://dev.w3.org/fxtf/motion-1/
> > +Shortname: transform-mapping
> > +Group: svg
> > +Editor: Satoru Takagi, KDDI Corporation, sa-takagi@kddi.com
> > +Abstract: This specification gives guidance how the SVG transform
> attribute in the SVG namespace can be used in other context than SVG.
> > +</pre>
> > +<pre class=link-defaults>
> > +spec:svg2; type:element; text:svg
> > +spec:css-transforms-1; type:property; text:transform
> > +spec:css-transforms-1; type:type; text:<transform-list>
> > +</pre>
> > +
> > +<h2 id="GeographicCoordinates">Geographic coordinate systems</h2>
> > +
> > +In order to allow interoperability between SVG content generators
> > +and user agents dealing with maps encoded in SVG, the use of a
> common
> > +metadata definition for describing the coordinate system used to
> > +generate SVG documents is encouraged.
> > +
> > +Such metadata must be added under the <a element>metadata</a>
> element of
> > +the topmost <a element>svg</a> element describing the map,
> consisting of an
> > +RDF description of the Coordinate Reference System definition used
> to
> > +generate the SVG map [[RDF-PRIMER]]. Note that
> > +the presence of this metadata does not affect the rendering of the
> SVG
> > +in any way; it merely provides added semantic value for applications
> > +that make use of combined maps.
> > +
> > +The definition must be conformant to the XML grammar described in
> > +<a
> href="http://portal.opengeospatial.org/files/?artifact_id=20509"><cite>
> GML 3.2.1</cite></a>,
> > +an OpenGIS Standard for encoding common CRS data types in XML
> > +[<a href='refs.html#ref-GML'>GML</a>]. In order to correctly map
> > +the 2-dimensional data used by SVG, the CRS must be of subtype
> > +<strong>ProjectedCRS</strong> or <strong>Geographic2dCRS</strong>.
> The
> > +first axis of the described CRS maps the SVG <var>x</var>-axis and
> the
> > +second axis maps the SVG <var>y</var>-axis.
> > +
> > +The main purpose of such metadata is to indicate to the user agent
> > +that two or more SVG documents can be overlayed or merged into a
> single
> > +document. Obviously, if two maps reference the same Coordinate
> Reference
> > +System definition and have the same SVG 'transform' property
> > +value then they can be overlayed without reprojecting the data. If
> > +the maps reference different Coordinate Reference Systems and/or
> have
> > +different SVG 'transform' property values, then a specialized
> > +cartographic user agent may choose to transform the coordinate data
> to
> > +overlay the data. However, typical SVG user agents are not required
> > +to perform these types of transformations, or even recognize the
> > +metadata. It is described in this specification so that the
> connection
> > +between geographic coordinate systems and the SVG coordinate system
> is
> > +clear.
> > +
> > +<h2 id="SVGGlobalTransformAttribute">The <span class="attr-
> name">'svg:transform'</span> attribute</h2>
> > +
> > +<div class="adef-list">
> > + <p><em>Attribute definition:</em></p>
> > + <dl>
> > + <dt
> id="SVGGlobalTransformAttributeDefinition"><dfn>svg:transform</dfn> =
> <<transform-list>> | ''transform/none''</dt>
> > + <dd>
> > + <dl>
> > + <dt><<transform-list>></dt>
> > + <dd>
> > + <p>Specifies the affine transformation that has been
> > + applied to the map data. The syntax is identical to
> > + that described for the 'transform' property.</p>
> > + </dd>
> > +
> > + <dt><span class="attr-value">none</span></dt>
> > + <dd>
> > + <p>Specifies that no supplemental affine transformation
> has been
> > + applied to the map data. Using this value has the same
> meaning as
> > + specifying the identity matrix, which in turn is just the
> same as
> > + not specifying the <a>svg:transform</a> the attribute at
> all.</p>
> > + </dd>
> > + </dl>
> > + <p class="anim-target">Animatable: no.</p>
> > + </dd>
> > + </dl>
> > +</div>
> > +
> > +This attribute describes an optional additional affine
> > +transformation that may have been applied during this
> > +mapping. This attribute may be added to the OpenGIS
> > +<em>CoordinateReferenceSystem</em> element. Note
> > +that, unlike the 'transform' property, it does not indicate that
> > +a transformation is to <em>be applied</em> to the data within the
> file.
> > +Instead, it simply describes the transformation that <em>was already
> > +applied</em> to the data when being encoded in SVG.
> > +
> > +There are three typical uses for the <a>svg:transform</a>
> > +global attribute. These are described below and used in the
> examples.
> > +
> > +<ul>
> > + <li>Most ProjectedCRS have the north direction represented by
> > + positive values of the second axis and conversely SVG has a
> > + <var>y</var>-down coordinate system. That's why, in order to
> follow the
> > + usual way to represent a map with the north at its top, it is
> > + recommended for that kind of ProjectedCRS to use the
> > + <a>svg:transform</a>
> > + global attribute with a ''scale(1, -1)'' value as in the
> > + third example below.</li>
> > +
> > + <li>Most Geographic2dCRS have the latitude as their first
> > + axis rather than the longitude, which means that the
> > + south-north axis would be represented by the <var>x</var>-axis in
> SVG
> > + instead of the usual <var>y</var>-axis. That's why, in order to
> follow
> > + the usual way to represent a map with the north at its top,
> > + it is recommended for that kind of Geographic2dCRS to use the
> > + <a>svg:transform'</a>
> > + global attribute with a ''rotate(-90)'' value as in the
> > + first example (while also adding the ''scale(1, -1)'' as for
> > + ProjectedCRS).</li>
> > +
> > + <li>In addition, when converting for profiles which place
> > + restrictions on precision of real number values, it may be
> > + useful to add an additional scaling factor to retain good
> > + precision for a specific area. When generating an SVG
> > + document from WGS84 geographic coordinates (EPGS 4326), we
> > + recommend the use of an additional 100 times scaling factor
> > + corresponding to an <a>svg:transform</a>
> > + global attribute with a ''rotate(-90) scale(100)''
> > + value (shown in the second example).
> > + Different scaling values may be required depending on the
> > + particular CRS.</li>
> > +</ul>
> > +
> > +Below is a simple example of the coordinate metadata, which
> > +describes the coordinate system used by the document via a
> > +URI.
> > +
> > +<div class="example">
> > + <pre><code class=html>
> > +<?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>An example that references coordinate data.</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- The Coordinate Reference System is described
> > + through a URI. -->
> > + <crs:CoordinateReferenceSystem
> > + svg:transform="rotate(-90)"
> > +
> rdf:resource="http://www.example.org/srs/epsg.xml#4326"/>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- The actual map content -->
> > +</svg>
> > +</code></pre>
> > +</div>
> > +
> > +The second example uses a well-known identifier to describe
> > +the coordinate system. Note that the coordinates used in the
> > +document have had the supplied transform applied.
> > +
> > +<div class="example">
> > + <pre><code class=html>
> > +<?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>Example using a well known coordinate system.</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- In case of a well-known Coordinate Reference System
> > + an 'Identifier' is enough to describe the CRS -->
> > + <crs:CoordinateReferenceSystem svg:transform="rotate(-90)
> scale(100, 100)">
> > + <crs:Identifier>
> > + <crs:code>4326</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:CoordinateReferenceSystem>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- The actual map content -->
> > +</svg>
> > + </code></pre>
> > +</div>
> > +
> > +The third example defines the coordinate system completely
> > +within the SVG document.
> > +
> > +<div class="example">
> > + <pre><code class=html>
> > +<?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>Coordinate metadata defined within the SVG
> document</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- For other CRS it should be entirely defined -->
> > + <crs:CoordinateReferenceSystem svg:transform="scale(1,-
> 1)">
> > + <crs:NameSet>
> > + <crs:name>Mercator projection of WGS84</crs:name>
> > + </crs:NameSet>
> > + <crs:ProjectedCRS>
> > + <!-- The actual definition of the CRS -->
> > + <crs:CartesianCoordinateSystem>
> > + <crs:dimension>2</crs:dimension>
> > + <crs:CoordinateAxis>
> > + <crs:axisDirection>north</crs:axisDirection>
> > + <crs:AngularUnit>
> > + <crs:Identifier>
> > + <crs:code>9108</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:AngularUnit>
> > + </crs:CoordinateAxis>
> > + <crs:CoordinateAxis>
> > + <crs:axisDirection>east</crs:axisDirection>
> > + <crs:AngularUnit>
> > + <crs:Identifier>
> > + <crs:code>9108</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:AngularUnit>
> > + </crs:CoordinateAxis>
> > + </crs:CartesianCoordinateSystem>
> > + <crs:CoordinateReferenceSystem>
> > + <!-- the reference system of that projected system
> is
> > + WGS84 which is EPSG 4326 in EPSG codeSpace
> -->
> > + <crs:NameSet>
> > + <crs:name>WGS 84</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>4326</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:CoordinateReferenceSystem>
> > + <crs:CoordinateTransformationDefinition>
> > + <crs:sourceDimensions>2</crs:sourceDimensions>
> > + <crs:targetDimensions>2</crs:targetDimensions>
> > + <crs:ParameterizedTransformation>
> > + <crs:TransformationMethod>
> > + <!-- the projection is a Mercator projection
> which is
> > + EPSG 9805 in EPSG codeSpace -->
> > + <crs:NameSet>
> > + <crs:name>Mercator</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>9805</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:description>Mercator
> (2SP)</crs:description>
> > + </crs:TransformationMethod>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>Latitude of 1st standart
> parallel</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8823</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>Longitude of natural
> origin</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8802</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>False Easting</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8806</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>False Northing</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8807</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + </crs:ParameterizedTransformation>
> > + </crs:CoordinateTransformationDefinition>
> > + </crs:ProjectedCRS>
> > + </crs:CoordinateReferenceSystem>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- the actual map content -->
> > +</svg>
> > + </code></pre>
> > +</div>
> > \ No newline at end of file
> > diff --git a/specs/transform/Overview.html
> b/specs/transform/Overview.html
> > new file mode 100644
> > index 0000000..2510f34
> > --- /dev/null
> > +++ b/specs/transform/Overview.html
> > @@ -0,0 +1,681 @@
> > +<!doctype html>
> > +<html lang="en">
> > + <head>
> > +
> > + <meta content="text/html; charset=utf-8" http-equiv="Content-
> Type">
> > +
> > +
> > + <title>svg:transform for mapping</title>
> > +
> > +
> > + <link href="../default.css" rel="stylesheet" type="text/css">
> > +
> > +
> > + <link href="https://www.w3.org/StyleSheets/TR/W3C-ED"
> rel="stylesheet" type="text/css">
> > +
> > +
> > + <meta content="Bikeshed 1.0.0" name="generator">
> > + </head>
> > +
> > +
> > + <body class="h-entry">
> > +
> > + <div class="head">
> > +
> > + <p data-fill-with="logo"></p>
> > +
> > + <h1 class="p-name no-ref" id="title">svg:transform for
> mapping</h1>
> > +
> > + <h2 class="no-num no-toc no-ref heading settled"
> id="subtitle"><span class="content">Editor’s Draft,
> > + <time class="dt-updated" datetime="2015-02-13">13 February
> 2015</time></span></h2>
> > +
> > + <div data-fill-with="spec-metadata">
> > + <dl>
> > + <dt>This version:
> > + <dd><a class="u-url" href="http://dev.w3.org/fxtf/motion-
> 1/">http://dev.w3.org/fxtf/motion-1/</a>
> > + <dt>Feedback:
> > + <dd><span><a href="mailto:www-svg@w3.org?subject=%5Btransform-
> mapping%5D%20feedback">www-svg@w3.org</a> with subject line
> “<kbd>[transform-mapping] <var>… message topic …</var></kbd>â€
> (<a href="http://lists.w3.org/Archives/Public/www-svg/"
> rel="discussion">archives</a>)</span>
> > + <dt class="editor">Editor:
> > + <dd class="editor">
> > + <div class="p-author h-card vcard"><a class="p-name fn u-email
> email" href="mailto:sa-takagi@kddi.com">Satoru Takagi</a> (<span
> class="p-org org">KDDI Corporation</span>)</div>
> > + </dl>
> > + </div>
> > +
> > + <div data-fill-with="warning"></div>
> > +
> > + <p class="copyright" data-fill-with="copyright"><a
> href="http://www.w3.org/Consortium/Legal/ipr-
> notice#Copyright">Copyright</a> © 2015 <a
> href="http://www.w3.org/"><abbr title="World Wide Web
> Consortium">W3C</abbr></a><sup>®</sup> (<a
> href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute
> of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr
> title="European Research Consortium for Informatics and
> Mathematics">ERCIM</abbr></a>, <a
> href="http://www.keio.ac.jp/">Keio</a>, <a
> href="http://ev.buaa.edu.cn/">Beihang</a>). W3C <a
> href="http://www.w3.org/Consortium/Legal/ipr-
> notice#Legal_Disclaimer">liability</a>, <a
> href="http://www.w3.org/Consortium/Legal/ipr-
> notice#W3C_Trademarks">trademark</a> and <a
> href="http://www.w3.org/Consortium/Legal/copyright-documents">document
> use</a> rules apply.
> > +</p>
> > +
> > + <hr title="Separator for header">
> > +</div>
> > +
> > +
> > + <h2 class="no-num no-toc no-ref heading settled"
> id="abstract"><span class="content">Abstract</span></h2>
> > +
> > + <div class="p-summary" data-fill-with="abstract">
> > + <p>This specification gives guidance how the SVG transform
> attribute in the SVG namespace can be used in other context than
> SVG.</p>
> > +
> > +</div>
> > +
> > +
> > + <h2 class="no-num no-toc no-ref heading settled" id="status"><span
> class="content">Status of this document</span></h2>
> > +
> > + <div data-fill-with="status">
> > + <p>
> > + <em>This section describes the status of this document at the
> time of
> > + its publication. Other documents may supersede this document.
> A list of
> > + current W3C publications and the latest revision of this
> technical report
> > + can be found in the <a href="http://www.w3.org/TR/">W3C
> technical reports
> > + index at http://www.w3.org/TR/.</a></em>
> > +
> > +</p>
> > + <p>
> > + This document is the 13 February 2015 <strong>Editor’s
> Draft</strong> of svg:transform for mapping.
> > +
> > +</p>
> > + <p>
> > + Comments on this Editor’s Draft are welcome. Comments can
> be sent to
> > + <a href="mailto:www-svg@w3.org?Subject=%5Btransform-
> mapping%5D%20PUT%20SUBJECT%20HERE">www-svg@w3.org</a>,
> > + the public email list for issues related to vector graphics
> on the Web. This list is
> > + <a href="http://lists.w3.org/Archives/Public/www-
> svg/">archived</a> and senders must agree to have their message
> > + publicly archived from their first posting. To subscribe send
> an email to
> > + <a href="mailto:www-svg-
> request@w3.org?Subject=subscribe">www-svg-request@w3.org</a> with the
> word <code>subscribe</code>
> > + in the subject line.
> > +
> > +</p>
> > + <p>
> > + This document has been produced by the <a
> href="http://www.w3.org/Graphics/SVG/WG">SVG Working Group</a> as part
> of the
> > + <a href="http://www.w3.org/Graphics/Activity">Graphics
> Activity</a> within the
> > + <a href="http://www.w3.org/Interaction/">W3C Interaction
> Domain</a>. The goals of the W3C SVG Working Group are discussed in the
> > + <a href="http://www.w3.org/2007/11/SVG_rechartering/SVG-WG-
> charter.html">W3C SVG Charter</a>. The W3C SVG Working Group maintains
> a
> > + public Web page, <a
> href="http://www.w3.org/Graphics/SVG/">http://www.w3.org/Graphics/SVG/<
> /a>, that contains further
> > + background information. The authors of this document are the
> SVG Working Group participants.
> > +
> > +</p>
> > + <p>
> > + This document was produced by a group operating under
> > + the <a href="http://www.w3.org/Consortium/Patent-Policy-
> 20040205/">5 February 2004 W3C Patent Policy</a>.
> > + W3C maintains a <a href="http://www.w3.org/2004/01/pp-
> impl/19480/status" rel="disclosure">public list of any patent
> disclosures</a>
> > + made in connection with the deliverables of each group;
> > + these pages also includes instructions for disclosing a
> patent.
> > + An individual who has actual knowledge of a patent which the
> individual believes contains
> > + <a href="http://www.w3.org/Consortium/Patent-Policy-
> 20040205/#def-essential">Essential Claim(s)</a>
> > + must disclose the information in accordance with <a
> href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-
> Disclosure">section 6 of the W3C Patent Policy</a>.
> > +
> > +</p>
> > + <p>
> > + A list of current W3C Recommendations and other technical
> documents can be found at
> > + <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.
> W3C publications may be updated, replaced, or
> > + obsoleted by other documents at any time.
> > +</p></div>
> > +
> > + <div data-fill-with="at-risk"></div>
> > +
> > +
> > + <h2 class="no-num no-toc no-ref heading settled"
> id="contents"><span class="content">Table of contents</span></h2>
> > +
> > + <div data-fill-with="table-of-contents" role="navigation">
> > + <ul class="toc" role="directory">
> > + <li><a href="#GeographicCoordinates"><span
> class="secno">1</span> <span class="content">Geographic coordinate
> systems</span></a>
> > + <li><a href="#SVGGlobalTransformAttribute"><span
> class="secno">2</span> <span class="content">The <span class="attr-
> name">'svg:transform'</span> attribute</span></a>
> > + <li><a href="#conformance"><span class="secno"></span> <span
> class="content">
> > +Conformance</span></a>
> > + <ul class="toc">
> > + <li><a href="#conventions"><span class="secno"></span> <span
> class="content">
> > +Document conventions</span></a>
> > + <li><a href="#conformance-classes"><span class="secno"></span>
> <span class="content">
> > +Conformance classes</span></a>
> > + <li><a href="#partial"><span class="secno"></span> <span
> class="content">
> > +Partial implementations</span></a>
> > + <li><a href="#experimental"><span class="secno"></span> <span
> class="content">
> > +Experimental implementations</span></a>
> > + <li><a href="#testing"><span class="secno"></span> <span
> class="content">
> > +Non-experimental implementations</span></a>
> > + </ul>
> > + <li><a href="#references"><span class="secno"></span> <span
> class="content">References</span></a>
> > + <ul class="toc">
> > + <li><a href="#normative"><span class="secno"></span> <span
> class="content">Normative References</span></a>
> > + <li><a href="#informative"><span class="secno"></span> <span
> class="content">Informative References</span></a>
> > + </ul>
> > + <li><a href="#index"><span class="secno"></span> <span
> class="content">Index</span></a>
> > + </ul></div>
> > +
> > + <main>
> > +
> > +
> > +
> > +
> > +
> > + <h2 class="heading settled" data-level="1"
> id="GeographicCoordinates"><span class="secno">1. </span><span
> class="content">Geographic coordinate systems</span><a class="self-
> link" href="#GeographicCoordinates"></a></h2>
> > +
> > +
> > + <p>In order to allow interoperability between SVG content
> generators
> > +and user agents dealing with maps encoded in SVG, the use of a
> common
> > +metadata definition for describing the coordinate system used to
> > +generate SVG documents is encouraged.</p>
> > +
> > +
> > + <p>Such metadata must be added under the <a data-link-
> type="element" href="https://svgwg.org/svg2-
> draft/metadata.html#elementdef-metadata">metadata</a> element of
> > +the topmost <a data-link-type="element"
> href="https://svgwg.org/svg2-draft/struct.html#NewDocument">svg</a>
> element describing the map, consisting of an
> > +RDF description of the Coordinate Reference System definition used
> to
> > +generate the SVG map <a data-link-type="biblio" href="#biblio-rdf-
> primer">[RDF-PRIMER]</a>. Note that
> > +the presence of this metadata does not affect the rendering of the
> SVG
> > +in any way; it merely provides added semantic value for applications
> > +that make use of combined maps.</p>
> > +
> > +
> > + <p>The definition must be conformant to the XML grammar described
> in
> > +<a
> href="http://portal.opengeospatial.org/files/?artifact_id=20509"><cite>
> GML 3.2.1</cite></a>,
> > +an OpenGIS Standard for encoding common CRS data types in XML
> > +[<a href="refs.html#ref-GML">GML</a>]. In order to correctly map
> > +the 2-dimensional data used by SVG, the CRS must be of subtype
> > +<strong>ProjectedCRS</strong> or <strong>Geographic2dCRS</strong>.
> The
> > +first axis of the described CRS maps the SVG <var>x</var>-axis and
> the
> > +second axis maps the SVG <var>y</var>-axis.</p>
> > +
> > +
> > + <p>The main purpose of such metadata is to indicate to the user
> agent
> > +that two or more SVG documents can be overlayed or merged into a
> single
> > +document. Obviously, if two maps reference the same Coordinate
> Reference
> > +System definition and have the same SVG <a class="property" data-
> link-type="propdesc" href="http://dev.w3.org/csswg/css-transforms-
> 1/#propdef-transform">transform</a> property
> > +value then they can be overlayed without reprojecting the data. If
> > +the maps reference different Coordinate Reference Systems and/or
> have
> > +different SVG <a class="property" data-link-type="propdesc"
> href="http://dev.w3.org/csswg/css-transforms-1/#propdef-
> transform">transform</a> property values, then a specialized
> > +cartographic user agent may choose to transform the coordinate data
> to
> > +overlay the data. However, typical SVG user agents are not required
> > +to perform these types of transformations, or even recognize the
> > +metadata. It is described in this specification so that the
> connection
> > +between geographic coordinate systems and the SVG coordinate system
> is
> > +clear.</p>
> > +
> > +
> > + <h2 class="heading settled" data-level="2"
> id="SVGGlobalTransformAttribute"><span class="secno">2. </span><span
> class="content">The <span class="attr-name">'svg:transform'</span>
> attribute</span><a class="self-link"
> href="#SVGGlobalTransformAttribute"></a></h2>
> > +
> > +
> > + <div class="adef-list">
> > +
> > + <p><em>Attribute definition:</em></p>
> > +
> > + <dl>
> > +
> > + <dt id="SVGGlobalTransformAttributeDefinition"><a class="self-
> link" href="#SVGGlobalTransformAttributeDefinition"></a><dfn data-dfn-
> type="dfn" data-noexport="" id="svgtransform">svg:transform<a
> class="self-link" href="#svgtransform"></a></dfn> = <a
> class="production css" data-link-type="type"
> href="http://dev.w3.org/csswg/css-transforms-1/#typedef-transform-
> list"><transform-list></a> | <span class="css">none</span>
> > +
> > +
> > + <dd>
> > +
> > + <dl>
> > +
> > + <dt><a class="production css" data-link-type="type"
> href="http://dev.w3.org/csswg/css-transforms-1/#typedef-transform-
> list"><transform-list></a>
> > +
> > +
> > + <dd>
> > +
> > + <p>Specifies the affine transformation that has been
> > + applied to the map data. The syntax is identical to
> > + that described for the <a class="property" data-link-
> type="propdesc" href="http://dev.w3.org/csswg/css-transforms-
> 1/#propdef-transform">transform</a> property.</p>
> > +
> > +
> > +
> > +
> > +
> > + <dt><span class="attr-value">none</span>
> > +
> > +
> > + <dd>
> > +
> > + <p>Specifies that no supplemental affine transformation has
> been
> > + applied to the map data. Using this value has the same
> meaning as
> > + specifying the identity matrix, which in turn is just the
> same as
> > + not specifying the <a data-link-type="dfn"
> href="#svgtransform">svg:transform</a> the attribute at all.</p>
> > +
> > +
> > +
> > +
> > + </dl>
> > +
> > +
> > + <p class="anim-target">Animatable: no.</p>
> > +
> > +
> > +
> > +
> > + </dl>
> > +</div>
> > +
> > +
> > + <p>This attribute describes an optional additional affine
> > +transformation that may have been applied during this
> > +mapping. This attribute may be added to the OpenGIS
> > +<em>CoordinateReferenceSystem</em> element. Note
> > +that, unlike the <a class="property" data-link-type="propdesc"
> href="http://dev.w3.org/csswg/css-transforms-1/#propdef-
> transform">transform</a> property, it does not indicate that
> > +a transformation is to <em>be applied</em> to the data within the
> file.
> > +Instead, it simply describes the transformation that <em>was already
> > +applied</em> to the data when being encoded in SVG.</p>
> > +
> > +
> > + <p>There are three typical uses for the <a data-link-type="dfn"
> href="#svgtransform">svg:transform</a>
> > +global attribute. These are described below and used in the
> examples.</p>
> > +
> > +
> > + <ul>
> > +
> > + <li>Most ProjectedCRS have the north direction represented by
> > + positive values of the second axis and conversely SVG has a
> > + <var>y</var>-down coordinate system. That’s why, in order to
> follow the
> > + usual way to represent a map with the north at its top, it is
> > + recommended for that kind of ProjectedCRS to use the
> > + <a data-link-type="dfn" href="#svgtransform">svg:transform</a>
> > + global attribute with a <span class="css">scale(1, -1)</span>
> value as in the
> > + third example below.
> > +
> > +
> > + <li>Most Geographic2dCRS have the latitude as their first
> > + axis rather than the longitude, which means that the
> > + south-north axis would be represented by the <var>x</var>-axis in
> SVG
> > + instead of the usual <var>y</var>-axis. That’s why, in order to
> follow
> > + the usual way to represent a map with the north at its top,
> > + it is recommended for that kind of Geographic2dCRS to use the
> > + <a data-link-type="dfn" href="#svgtransform">svg:transform'</a>
> > + global attribute with a <span class="css">rotate(-90)</span> value
> as in the
> > + first example (while also adding the <span class="css">scale(1, -
> 1)</span> as for
> > + ProjectedCRS).
> > +
> > +
> > + <li>In addition, when converting for profiles which place
> > + restrictions on precision of real number values, it may be
> > + useful to add an additional scaling factor to retain good
> > + precision for a specific area. When generating an SVG
> > + document from WGS84 geographic coordinates (EPGS 4326), we
> > + recommend the use of an additional 100 times scaling factor
> > + corresponding to an <a data-link-type="dfn"
> href="#svgtransform">svg:transform</a>
> > + global attribute with a <span class="css">rotate(-90)
> scale(100)</span>
> > + value (shown in the second example).
> > + Different scaling values may be required depending on the
> > + particular CRS.
> > +</ul>
> > +
> > +
> > + <p>Below is a simple example of the coordinate metadata, which
> > +describes the coordinate system used by the document via a
> > +URI.</p>
> > +
> > +
> > + <div class="example">
> > +
> > + <pre><code class="html"><?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>An example that references coordinate data.</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- The Coordinate Reference System is described
> > + through a URI. -->
> > + <crs:CoordinateReferenceSystem
> > + svg:transform="rotate(-90)"
> > +
> rdf:resource="http://www.example.org/srs/epsg.xml#4326"/>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- The actual map content -->
> > +</svg>
> > +</code></pre>
> > +</div>
> > +
> > +
> > + <p>The second example uses a well-known identifier to describe
> > +the coordinate system. Note that the coordinates used in the
> > +document have had the supplied transform applied.</p>
> > +
> > +
> > + <div class="example">
> > +
> > + <pre><code class="html"><?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>Example using a well known coordinate system.</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- In case of a well-known Coordinate Reference System
> > + an 'Identifier' is enough to describe the CRS -->
> > + <crs:CoordinateReferenceSystem svg:transform="rotate(-90)
> scale(100, 100)">
> > + <crs:Identifier>
> > + <crs:code>4326</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:CoordinateReferenceSystem>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- The actual map content -->
> > +</svg>
> > +</code></pre>
> > +</div>
> > +
> > +
> > + <p>The third example defines the coordinate system completely
> > +within the SVG document.</p>
> > +
> > +
> > + <div class="example">
> > +
> > + <pre><code class="html"><?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>Coordinate metadata defined within the SVG
> document</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- For other CRS it should be entirely defined -->
> > + <crs:CoordinateReferenceSystem svg:transform="scale(1,-
> 1)">
> > + <crs:NameSet>
> > + <crs:name>Mercator projection of WGS84</crs:name>
> > + </crs:NameSet>
> > + <crs:ProjectedCRS>
> > + <!-- The actual definition of the CRS -->
> > + <crs:CartesianCoordinateSystem>
> > + <crs:dimension>2</crs:dimension>
> > + <crs:CoordinateAxis>
> > + <crs:axisDirection>north</crs:axisDirection>
> > + <crs:AngularUnit>
> > + <crs:Identifier>
> > + <crs:code>9108</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:AngularUnit>
> > + </crs:CoordinateAxis>
> > + <crs:CoordinateAxis>
> > + <crs:axisDirection>east</crs:axisDirection>
> > + <crs:AngularUnit>
> > + <crs:Identifier>
> > + <crs:code>9108</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:AngularUnit>
> > + </crs:CoordinateAxis>
> > + </crs:CartesianCoordinateSystem>
> > + <crs:CoordinateReferenceSystem>
> > + <!-- the reference system of that projected system
> is
> > + WGS84 which is EPSG 4326 in EPSG codeSpace
> -->
> > + <crs:NameSet>
> > + <crs:name>WGS 84</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>4326</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:CoordinateReferenceSystem>
> > + <crs:CoordinateTransformationDefinition>
> > + <crs:sourceDimensions>2</crs:sourceDimensions>
> > + <crs:targetDimensions>2</crs:targetDimensions>
> > + <crs:ParameterizedTransformation>
> > + <crs:TransformationMethod>
> > + <!-- the projection is a Mercator projection
> which is
> > + EPSG 9805 in EPSG codeSpace -->
> > + <crs:NameSet>
> > + <crs:name>Mercator</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>9805</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:description>Mercator
> (2SP)</crs:description>
> > + </crs:TransformationMethod>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>Latitude of 1st standart
> parallel</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8823</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>Longitude of natural
> origin</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8802</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>False Easting</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8806</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>False Northing</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8807</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + </crs:ParameterizedTransformation>
> > + </crs:CoordinateTransformationDefinition>
> > + </crs:ProjectedCRS>
> > + </crs:CoordinateReferenceSystem>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- the actual map content -->
> > +</svg>
> > +</code></pre>
> > +</div>
> > +</main>
> > +
> > + <h2 class="no-ref no-num heading settled" id="conformance"><span
> class="content">
> > +Conformance</span><a class="self-link" href="#conformance"></a></h2>
> > +
> > +
> > + <h3 class="no-ref heading settled" id="conventions"><span
> class="content">
> > +Document conventions</span><a class="self-link"
> href="#conventions"></a></h3>
> > +
> > +
> > + <p>Conformance requirements are expressed with a combination of
> > + descriptive assertions and RFC 2119 terminology. The key words
> "MUST",
> > + "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
> NOT",
> > + "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of
> this
> > + document are to be interpreted as described in RFC 2119.
> > + However, for readability, these words do not appear in all
> uppercase
> > + letters in this specification.
> > +
> > + </p>
> > + <p>All of the text of this specification is normative except
> sections
> > + explicitly marked as non-normative, examples, and notes. <a
> data-link-type="biblio" href="#biblio-rfc2119">[RFC2119]</a></p>
> > +
> > +
> > + <p>Examples in this specification are introduced with the words
> "for example"
> > + or are set apart from the normative text with
> <code>class="example"</code>,
> > + like this:
> > +
> > + </p>
> > + <div class="example">
> > +
> > + <p>This is an example of an informative example.</p>
> > +
> > +
> > + </div>
> > +
> > +
> > + <p>Informative notes begin with the word "Note" and are set apart
> from the
> > + normative text with <code>class="note"</code>, like this:
> > +
> > + </p>
> > + <p class="note" role="note">Note, this is an informative note.</p>
> > +
> > +
> > + <p>Advisements are normative sections styled to evoke special
> attention and are
> > + set apart from other normative text with <code><strong
> class="advisement"></code>, like
> > + this:
> > +
> > + <strong class="advisement">
> > + UAs MUST provide an accessible alternative.
> > + </strong>
> > +
> > +</p>
> > + <h3 class="no-ref heading settled" id="conformance-classes"><span
> class="content">
> > +Conformance classes</span><a class="self-link" href="#conformance-
> classes"></a></h3>
> > +
> > +
> > + <p>Conformance to this specification
> > + is defined for three conformance classes:
> > + </p>
> > + <dl>
> > +
> > + <dt>style sheet
> > +
> > + <dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#style-
> sheet">CSS
> > + style sheet</a>.
> > +
> > + <dt>renderer
> > +
> > + <dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#user-
> agent">UA</a>
> > + that interprets the semantics of a style sheet and
> renders
> > + documents that use them.
> > +
> > + <dt>authoring tool
> > +
> > + <dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#user-
> agent">UA</a>
> > + that writes a style sheet.
> > +
> > + </dl>
> > +
> > +
> > + <p>A style sheet is conformant to this specification
> > + if all of its statements that use syntax defined in this module
> are valid
> > + according to the generic CSS grammar and the individual grammars
> of each
> > + feature defined in this module.
> > +
> > + </p>
> > + <p>A renderer is conformant to this specification
> > + if, in addition to interpreting the style sheet as defined by
> the
> > + appropriate specifications, it supports all the features defined
> > + by this specification by parsing them correctly
> > + and rendering the document accordingly. However, the inability
> of a
> > + UA to correctly render a document due to limitations of the
> device
> > + does not make the UA non-conformant. (For example, a UA is not
> > + required to render color on a monochrome monitor.)
> > +
> > + </p>
> > + <p>An authoring tool is conformant to this specification
> > + if it writes style sheets that are syntactically correct
> according to the
> > + generic CSS grammar and the individual grammars of each feature
> in
> > + this module, and meet all other conformance requirements of
> style sheets
> > + as described in this module.
> > +
> > +</p>
> > + <h3 class="no-ref heading settled" id="partial"><span
> class="content">
> > +Partial implementations</span><a class="self-link"
> href="#partial"></a></h3>
> > +
> > +
> > + <p>So that authors can exploit the forward-compatible parsing
> rules to
> > + assign fallback values, CSS renderers <strong>must</strong>
> > + treat as invalid (and <a
> href="http://www.w3.org/TR/CSS21/conform.html#ignore">ignore
> > + as appropriate</a>) any at-rules, properties, property values,
> keywords,
> > + and other syntactic constructs for which they have no usable
> level of
> > + support. In particular, user agents <strong>must not</strong>
> selectively
> > + ignore unsupported component values and honor supported values
> in a single
> > + multi-value property declaration: if any value is considered
> invalid
> > + (as unsupported values must be), CSS requires that the entire
> declaration
> > + be ignored.</p>
> > +
> > +
> > + <h3 class="no-ref heading settled" id="experimental"><span
> class="content">
> > +Experimental implementations</span><a class="self-link"
> href="#experimental"></a></h3>
> > +
> > +
> > + <p>To avoid clashes with future CSS features, the CSS2.1
> specification
> > + reserves a <a
> href="http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords">prefixed
> > + syntax</a> for proprietary and experimental extensions to CSS.
> > +
> > + </p>
> > + <p>Prior to a specification reaching the Candidate Recommendation
> stage
> > + in the W3C process, all implementations of a CSS feature are
> considered
> > + experimental. The CSS Working Group recommends that
> implementations
> > + use a vendor-prefixed syntax for such features, including those
> in
> > + W3C Working Drafts. This avoids incompatibilities with future
> changes
> > + in the draft.
> > + </p>
> > +
> > +
> > + <h3 class="no-ref heading settled" id="testing"><span
> class="content">
> > +Non-experimental implementations</span><a class="self-link"
> href="#testing"></a></h3>
> > +
> > +
> > + <p>Once a specification reaches the Candidate Recommendation
> stage,
> > + non-experimental implementations are possible, and implementors
> should
> > + release an unprefixed implementation of any CR-level feature
> they
> > + can demonstrate to be correctly implemented according to spec.
> > +
> > + </p>
> > + <p>To establish and maintain the interoperability of CSS across
> > + implementations, the CSS Working Group requests that non-
> experimental
> > + CSS renderers submit an implementation report (and, if
> necessary, the
> > + testcases used for that implementation report) to the W3C before
> > + releasing an unprefixed implementation of any CSS features.
> Testcases
> > + submitted to W3C are subject to review and correction by the CSS
> > + Working Group.
> > +
> > + </p>
> > + <p>Further information on submitting testcases and implementation
> reports
> > + can be found from on the CSS Working Group’s website at
> > + <a
> href="http://www.w3.org/Style/CSS/Test/">http://www.w3.org/Style/CSS/Te
> st/</a>.
> > + Questions should be directed to the
> > + <a href="http://lists.w3.org/Archives/Public/public-css-
> testsuite">public-css-testsuite@w3.org</a>
> > + mailing list.
> > +
> > +
> > +
> > +</p>
> > + <h2 class="no-num heading settled" id="references"><span
> class="content">References</span><a class="self-link"
> href="#references"></a></h2>
> > + <h3 class="no-num heading settled" id="normative"><span
> class="content">Normative References</span><a class="self-link"
> href="#normative"></a></h3>
> > + <dl>
> > + <dt id="biblio-rfc2119"><a class="self-link" href="#biblio-
> rfc2119"></a>[rfc2119]
> > + <dd>S. Bradner. <a href="https://tools.ietf.org/html/rfc2119">Key
> words for use in RFCs to Indicate Requirement Levels</a>. March 1997.
> Best Current Practice. URL: <a
> href="https://tools.ietf.org/html/rfc2119">https://tools.ietf.org/html/
> rfc2119</a>
> > + </dl>
> > + <h3 class="no-num heading settled" id="informative"><span
> class="content">Informative References</span><a class="self-link"
> href="#informative"></a></h3>
> > + <dl>
> > + <dt id="biblio-rdf-primer"><a class="self-link" href="#biblio-
> rdf-primer"></a>[rdf-primer]
> > + <dd>Frank Manola; Eric Miller. <a href="http://www.w3.org/TR/rdf-
> primer/">RDF Primer</a>. 10 February 2004. REC. URL: <a
> href="http://www.w3.org/TR/rdf-primer/">http://www.w3.org/TR/rdf-
> primer/</a>
> > + </dl>
> > + <h2 class="no-num heading settled" id="index"><span
> class="content">Index</span><a class="self-link"
> href="#index"></a></h2>
> > + <ul class="indexlist">
> > + <li>svg:transform, <a href="#svgtransform">2</a>
> > + </ul></body>
> > +</html>
> > \ No newline at end of file
> >
> >
> > ============================================================
> > /home/svgwg/bin/node
> "/home/svgwg/svgwg.org/git/svgwg/tools/publish/publish.js" --list-toc-
> pages
> > /home/svgwg/bin/node
> "/home/svgwg/svgwg.org/git/svgwg/tools/publish/publish.js" --list-
> nontoc-pages
> > /home/svgwg/bin/node
> "/home/svgwg/svgwg.org/git/svgwg/tools/publish/publish.js" --build
> Overview toc coords
> > /home/svgwg/bin/node
> "/home/svgwg/svgwg.org/git/svgwg/tools/publish/publish.js" --build-
> single-page
> >
>
Received on Wednesday, 25 February 2015 19:50:15 UTC