- From: SVG Working Group repository <cam@mcc.id.au>
- Date: Fri, 14 Sep 2012 03:09:18 -0700
- To: public-svg-wg@w3.org
details: https://svgwg.org/hg/svg2/rev/8768ba6b67e2
branches:
changeset: 366:8768ba6b67e2
user: Cameron McCormack <cam@mcc.id.au>
date: Fri Sep 14 20:03:58 2012 +1000
description:
Tweak style sheet to show maturity background colours properly in the single page version of the spec.
details: https://svgwg.org/hg/svg2/rev/1b6855728789
branches:
changeset: 367:1b6855728789
user: Cameron McCormack <cam@mcc.id.au>
date: Fri Sep 14 20:03:58 2012 +1000
description:
Add some random issues to the spec.
details: https://svgwg.org/hg/svg2/rev/13274fa208d7
branches:
changeset: 368:13274fa208d7
user: Cameron McCormack <cam@mcc.id.au>
date: Fri Sep 14 20:03:58 2012 +1000
description:
Note that Gecko now supports objectFill, objectStroke and objectStrokeWidth.
diffstat:
master/concepts.html | 6 +
master/coords.html | 44 ++++++++++++-
master/intro.html | 16 ++++
master/painting.html | 7 ++
master/paths.html | 23 ++++++
master/pservers.html | 2 +
master/shapes.html | 6 +
master/struct.html | 145 +++++++++++++++++++++++++++++++++++++++++-
master/style/default_svg.css | 8 +-
master/styling.html | 39 +++++++++++
master/types.html | 3 +
11 files changed, 290 insertions(+), 9 deletions(-)
diffs (1402 lines):
diff --git a/master/concepts.html b/master/concepts.html
--- a/master/concepts.html
+++ b/master/concepts.html
@@ -11,16 +11,19 @@
<link rel="alternate stylesheet" title="SVG 1.1" type="text/css" media="screen" href="style/svg-style.css"/>
-->
<!-- W3C style sheet will be added here during processing. -->
</head>
<body>
<h1>Concepts</h1>
+<p class="issue">This chapter is a bit waffley. How much of this
+do we really need to say?</p>
+
<h2 id="Intro">Explaining the name: SVG</h2>
<p class="explain">SVG stands for <a
href="#Scalable">S</a>calable <a href="#Vector">V</a>ector <a
href="#Graphics">G</a>raphics, an <a href="#XML">XML</a>
grammar for <a href="#Stylable">stylable</a> graphics, usable
as an <a href="#Namespace">XML namespace</a>.</p>
@@ -189,16 +192,19 @@ the document, but scripts are difficult
between authoring tools is harder. Again in response to
feedback from the design community, SVG includes declarative
animation elements which were designed collaboratively by the
SVG and SYMM Working Groups. This allows the animated effects
common in existing Web graphics to be expressed in SVG.</p>
<h2 id="UsageOptions">Options for using SVG in Web pages</h2>
+<p class="issue">We should reference the SVG Integration
+specification here, once that has been published.</p>
+
<p>There are a variety of ways in which SVG content can be
included within a Web page. Here are some of the options:</p>
<dl>
<dt>A stand-alone SVG Web page</dt>
<dd>In this case, an SVG document (i.e., a Web resource whose
MIME type is "<code>image/svg+xml</code>") is loaded directly
into a user agent such as a Web browser. The SVG document is
diff --git a/master/coords.html b/master/coords.html
--- a/master/coords.html
+++ b/master/coords.html
@@ -43,16 +43,19 @@ the SVG user agent is provided the follo
<li>(highly desirable but not required) a real number value
that indicates the size in real world units, such as
millimeters, of a "pixel" (i.e., a <em>px</em> unit
<a href='http://www.w3.org/TR/2011/REC-CSS2-20110607/syndata.html#length-units'>as defined in CSS 2.1</a>
([<a href="refs.html#ref-CSS21">CSS21</a>], section 4.3.2)</li>
</ul>
+<p class="issue">Why are real world units relevant? Shouldn't we
+just be relying on CSS' fixed ratio of mm to px units?</p>
+
<p id="SVGInitialUserCoordinateSystem">Using the above information, the SVG user agent determines
the <a>viewport</a>, an initial <a>viewport coordinate system</a> and an
initial <a>user coordinate system</a>
such that the two coordinates systems are identical. Both
coordinates systems are established such that the origin
matches the origin of the viewport (for the root viewport, the
viewport origin is at the top/left corner), and one unit in the
initial coordinate system equals one "pixel" in the viewport.
@@ -91,31 +94,39 @@ viewport</a>, you can redefine the meani
and provide a new reference rectangle for "fitting" a graphic
into a particular rectangular area. ("Fit" means that a given
graphic is transformed in such a way that its bounding box in
user space aligns exactly with the edges of a given
viewport.)</p>
<h2 id="ViewportSpace">The initial viewport</h2>
+<p class="issue">Do we need to port over some more up-to-date
+definitions of sizing from SVG Tiny 1.2?</p>
+
<p id="SVGViewport">The SVG user agent negotiates with its parent user agent to
determine the viewport into which the SVG user agent can render
the document. In some circumstances, SVG content will be
embedded (<a href="concepts.html#UsageOptions">by reference or
inline</a>) within a containing document. This containing
document might include attributes, properties and/or other
parameters (explicit or implicit) which specify or provide
hints about the dimensions of the viewport for the SVG content.
SVG content itself optionally can provide information about the
appropriate viewport region for the content via the <a>'svg/width'</a>
and <a>'svg/height'</a> XML attributes on the <a>outermost svg element</a>.
The negotiation process uses any information provided by the
containing document and the SVG content itself to choose the
viewport location and size.</p>
+<p class="issue">Talking about a "parent user agent" really makes
+this sound like we have a separate plugin SVG implementation
+communicating with a browser hosting the plugin. These days,
+it's going to be the same user agent.</p>
+
<p>The <a>'svg/width'</a> attribute on the
<a>outermost svg element</a>
establishes the viewport's width, unless the following
conditions are met:</p>
<ul>
<li>the SVG content is a separately stored resource that is
embedded by reference (such as the <span
@@ -230,17 +241,17 @@ unit equal to the parent (implicit or ex
"pixel".</p>
<edit:example href='images/coords/InitialCoords.svg' name='InitialCoords' description="SVG's initial coordinate system" image='yes' link='yes'/>
<h2 id="EstablishingANewUserSpace">Coordinate system transformations</h2>
<p>A new user space (i.e., a new current coordinate system) can
be established by specifying <a>transformations</a> in the form of a <a>'transform'</a>
-attribute on a container element or graphics element or a
+property on a container element or graphics element or a
<a>'viewBox'</a> attribute on an
<a>'svg'</a>,
<a>'symbol'</a>,
<a>'marker element'</a>,
<a>'pattern'</a> and the
<a>'view'</a> element.
The <a>'transform'</a> property and <a>'viewBox'</a> attribute transform user
space coordinates and lengths on sibling attributes on the
@@ -348,16 +359,24 @@ alt="Matrix concatenation" width="512" h
<td><dfn>transform</dfn></td>
</tr>
<tr>
<th><a>Animatable</a>:</th>
<td>yes</td>
</tr>
</table>
+<p class="issue">Do we need this blue box, and if so, should we expand it to
+include all of the property definition information? Some sections (such as
+for <span class="property">'color'</span>) do not have the blue box.
+Others, like the one for <a>'white-space'</a>, have all the information from
+the CSS specification it comes from. Regardless, I think we don't need
+to mention whether the property is animatable since all properties are
+animatable.</p>
+
<p id="TransformList">The term <var><transform-list></var> used by this specification is equivalent to a list of <var><transform-functions></var>, the value of the <a>'transform'</a>
property.</p>
<div class="note">See the CSS3 Transforms spec for the description of the <a>'transform'</a> property and the value of <var><transform-functions></var> [<a href="refs.html#ref-CSS3TRANSFORMS">CSS3TRANSFORMS</a>].</div>
<h2 id="ViewBoxAttribute">The <span class="attr-name">'viewBox'</span> attribute</h2>
<p>It is often desirable to specify that a given set of
@@ -923,16 +942,28 @@ different viewing environments since the
to a different number of user units on different systems; thus,
absolute units identifiers are only recommended for the
<a>'svg/width'</a> and the <a>'svg/height'</a> on
<a>outermost svg elements</a> and situations
where the content contains no transformations and it is
desirable to specify values relative to the device pixel grid
or to a particular real world unit size.</p>
+<p class="issue">That's wrong. 1px always corresponds to
+one user unit, and the "absolute" units must be interpreted
+as CSS says to, i.e. as fixed multiples of the CSS px, and
+not anything to do with the display's resolution. The
+recommendation to use the absolute units (apart from px)
+only for <a>'svg/width'</a> and <a>'svg/height'</a> on
+root <a>'svg'</a> is a good one, however. Defining
+the size of a document in mm and then using mm units
+for shapes within it is going to give counterintuitive
+results, since they'll be converted to user units to resolve
+against the view box.</p>
+
<p>For percentage values that are defined to be relative to the
size of viewport:</p>
<ul>
<li>For any x-coordinate value or width value expressed as a
percentage of the viewport, the value to use is the specified
percentage of the <em>actual-width</em> in user units for the
nearest containing viewport, where <em>actual-width</em> is
@@ -963,16 +994,19 @@ inch = 96 pixels). Therefore, the topmos
specified in inches, is exactly the same size as the middle
rectangle, which is specified in user units such that there are
96 user units for each corresponding inch in the topmost
rectangle. (Note: on systems with different screen resolutions,
the top and middle rectangles will likely be rendered at
different sizes.) The bottom rectangle of the group illustrates
what happens when values specified in inches are scaled.</p>
+<p class="issue">The example needs to be changed in light of
+the issue above about absolute units.</p>
+
<p>The three rectangles in the middle demonstrate the use of
one of the relative unit identifiers, the "em" unit. Because
the <a>'font-size'</a> property has been set
to <span class="prop-value">150</span> on the outermost <a>'g'</a> element, each "em" unit is
equal to 150 user units. The topmost rectangle, which is
specified in "em" units, is exactly the same size as the middle
rectangle, which is specified in user units such that there are
150 user units for each corresponding "em" unit in the topmost
@@ -998,16 +1032,18 @@ values specified in percentage units are
<h2 id="ObjectBoundingBoxUnits">Object bounding box units</h2>
<p id="ObjectBoundingBox">The following elements offer the option of expressing
coordinate values and lengths as fractions (and, in some cases,
percentages) of the <a>bounding box</a>,
by setting a specified attribute to <span class="attr-value">'objectBoundingBox'</span>
on the given element:</p>
+<p class="issue">Need a line for <a>'meshGradient'</a>.</p>
+
<table class='vert'>
<tr>
<th>Element</th>
<th>Attribute</th>
<th>Effect</th>
</tr>
<tr>
<edit:with element='linearGradient'>
@@ -1309,16 +1345,19 @@ cartographic user agent may choose to tr
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="SVGGlobalTransformAttribute">The <span class="attr-name">'svg:transform'</span> attribute</h2>
+<p class="issue">Do we need this section? Should we instead have a guide on
+how other specifications should re-use specific attributes or elements?</p>
+
<div class="adef-list">
<p><em>Attribute definition:</em></p>
<dl>
<dt id="SVGGlobalTransformAttributeDefinition"><span class="adef">svg:transform</span> = <span class="attr-value">"<a href="#TransformProperty"><transform></a>" | "none"</span></dt>
<dd>
<dl>
<dt><span class="attr-value"><a href="#TransformProperty"><transform></a></span></dt>
<dd>
@@ -2679,16 +2718,19 @@ Sets the transform type to SVG_TRANSFORM
</dd>
</dl>
</dd>
</dl>
<h3 id="InterfaceSVGTransformList">Interface SVGTransformList</h3>
+<p class="issue">This section needs to be updated to describe
+how it reflects the value of the <a>'transform'</a> property,
+or just defer to css3-tranforms if everything is defined there.</p>
<p>This interface defines a list of SVGTransform objects.</p>
<p>The <a>SVGTransformList</a> and <a>SVGTransform</a> interfaces correspond
to the various attributes which specify a set of transformations, such as
the <a>'transform'</a> property which is available for many of SVG's elements.
diff --git a/master/intro.html b/master/intro.html
--- a/master/intro.html
+++ b/master/intro.html
@@ -69,37 +69,46 @@ registration of this MIME type is in pro
<p>It is recommended that SVG files have the extension
<code>".svg"</code> (all lowercase) on all platforms. It is
recommended that <a href="http://www.ietf.org/rfc/rfc1952.txt">gzip-compressed</a>
[<a href="refs.html#ref-RFC1952">RFC1952</a>]
SVG files have the extension <code>".svgz"</code> (all
lowercase) on all platforms.</p>
+<p class="issue">Should we mention <code>.svg.gz</code>?</p>
+
<p>It is recommended that SVG files stored on Macintosh HFS
file systems be given a file type of <code>"svg "</code>
(all lowercase, with a space character as the fourth letter).
It is recommended that gzip-compressed
SVG files stored on Macintosh HFS file systems be given a file
type of <code>"svgz"</code> (all lowercase).</p>
+<p class="issue">HFS file types are probably not relevant any more.</p>
+
<div class="ready-for-wider-review">
<h2 id="Namespace">SVG namespace and DTD</h2>
<p>The SVG 2 namespace is <code>http://www.w3.org/2000/svg</code>,
which is the same as for earlier versions of SVG.</p>
<p>A DTD is not provided in this specification, as the use of DTDs for
validating XML documents is known to be problematic. In particular, DTDs
do not handle namespaces gracefully. It is recommended that authors
do not include a DOCTYPE declaration in SVG documents.</p>
</div>
<h2 id="W3CCompatibility">Compatibility with other standards efforts</h2>
+<p class="issue">This section doesn't sound like it serves any real
+purpose other than self promotion for how well it utilizes other
+specifications and frameworks. I think it can be dropped, or at least
+condensed into a couple of sentences.</p>
+
<p>SVG leverages and integrates with other W3C specifications
and standards efforts. By leveraging and conforming to other
standards, SVG becomes more powerful and makes it easier for
users to learn how to incorporate SVG into their Web sites.</p>
<p>The following describes some of the ways in which SVG
maintains compatibility with, leverages and integrates with
other W3C efforts:</p>
@@ -213,16 +222,23 @@ uppercase letters in this specification.
authors and user agents. These recommendations are not
normative and conformance with this specification does not
depend on their realization. These recommendations contain the
expression "We recommend ...", "This specification recommends
...", or some similar wording.</p>
<h2 id="Definitions">Definitions</h2>
+<p class="issue">Does it make sense to have a glossary here? How
+useful is it compared to defining terms where they make most
+sense in the body of the specification?</p>
+
+<p class="issue">There should be a separate section that lists
+element and attribute categories and their members.</p>
+
<dl class='definitions'>
<dt id="TermAnimationElement">animation element</dt>
<dd>An animation element is an element that can be used to animate
the attribute or property value of another element. The following elements
are animation elements: <edit:elementcategory name='animation'/>.</dd>
<dt id="TermAnimationEventAttribute">animation event attribute</dt>
<dd>An animation event attribute is an <a>event attribute</a> that specifies
diff --git a/master/painting.html b/master/painting.html
--- a/master/painting.html
+++ b/master/painting.html
@@ -79,16 +79,19 @@ paint servers.</p>
</tr>
<tr>
<th>Owner:</th>
<td>Chris (<a href="http://www.w3.org/Graphics/SVG/WG/track/actions/3094">ACTION-3094</a>)</td>
</tr>
</table>
</div>
+<p class="issue">Gecko supports values with slightly different names – -moz-objectFill, -moz-objectFillOpacity,
+-moz-objectValue (for stroke width), etc. – so we might want to use those names instead.</p>
+
<p>Properties <a>'fill'</a> and <a>'stroke'</a> take on a value of type
<span class="prop-value"><paint></span>, which is specified as follows:</p>
<table>
<tr>
<td><span
class="property"><paint></span>: </td>
<td><span class="prop-value">none |<br />
@@ -1065,16 +1068,20 @@ description of positions along a path th
</tr>
<tr>
<th>Owner:</th>
<td>Cameron (no action)</td>
</tr>
</table>
</div>
+<p class="issue">Something in this section needs to reference
+<a>'path/pathLength'</a> so that dash lengths are in the author's
+path length space.</p>
+
<p>The following algorithm describes what the shape of a
<a>'path'</a> or <a>basic shape</a>'s stroke is, taking into account the
stroking properties above:</p>
<p class="issue">This should include text elements too, but should we
keep stroke dashing on text?</p>
<ol>
diff --git a/master/paths.html b/master/paths.html
--- a/master/paths.html
+++ b/master/paths.html
@@ -21,16 +21,19 @@
<h2 id="Introduction">Introduction</h2>
<p>Paths represent the outline of a shape which can be filled,
stroked, used as a clipping path, or any combination of the
three. (See <a href="painting.html">Filling, Stroking and Paint
Servers</a> and <a href="masking.html">Clipping, Masking and
Compositing</a>.)</p>
+<p class="issue">Also they can be used by <a>'mpath'</a> and
+<a>'textPath'</a>.</p>
+
<p>A path is described using the concept of a current point. In
an analogy with drawing on paper, the current point can be
thought of as the location of the pen. The position of the pen
can be changed, and the outline of a shape (open or closed) can
be traced by dragging the pen in either straight lines or
curves.</p>
<p>Paths represent the geometry of the outline of an object,
@@ -167,16 +170,36 @@ specifies a path in the shape of a trian
<p>Path data can contain newline characters and thus can be
broken up into multiple lines to improve readability. Because
of line length limitations with certain related tools, it is
recommended that SVG generators split long path data strings
across multiple lines, with each line not exceeding 255
characters. Also note that newline characters are only allowed
at certain places within path data.</p>
+<div class="issue">
+<p>The path data is defined to allow newline
+characters, but it should be noted that newlines inside
+attributes in markup will be normalized to space characters
+while parsing. If you wanted to, you could write</p>
+
+<pre><path d="M 100,100&#10;L 200,150"/></pre>
+
+<p>but it's not likely that you'd want to.</p>
+</div>
+
+<p class="issue">Are there tools that have line limits nowadays?
+Do we still need to recommend generators to split up path data
+at 255 characters?</p>
+
+<p class="issue">The sentence about newline characters being
+allowed only at certain places makes it sound like these places
+are different from where white space more generally is allowed,
+but that's not the case.</p>
+
<p>The syntax of path data is concise in order to allow for
minimal file size and efficient downloads, since many SVG files
will be dominated by their path data. Some of the ways that SVG
attempts to minimize the size of path data are as follows:</p>
<ul>
<li>All instructions are expressed as one character (e.g., a
<em>moveto</em> is expressed as an <strong>M</strong>).</li>
diff --git a/master/pservers.html b/master/pservers.html
--- a/master/pservers.html
+++ b/master/pservers.html
@@ -1774,16 +1774,18 @@ to the bounds of the pattern tile.</p>
<h2 id="DOMInterfaces">DOM interfaces</h2>
<h3 id="InterfaceSVGSolidColorElement">Interface SVGSolidColorElement</h3>
<edit:with element='solidColor'>
<pre class="idl"></pre>
+<p class="issue">IDL needs to be added for SVGSolidColorElement.</p>
+
</edit:with>
<h3 id="InterfaceSVGGradientElement">Interface SVGGradientElement</h3>
The <a>SVGGradientElement</a> interface is a base interface used by
<a>SVGLinearGradientElement</a> and <a>SVGRadialGradientElement</a>.
<pre class="idl">interface <b>SVGGradientElement</b> : <a>SVGDefinitionElement</a> {
diff --git a/master/shapes.html b/master/shapes.html
--- a/master/shapes.html
+++ b/master/shapes.html
@@ -343,16 +343,22 @@ radius.</p>
</dl>
</div>
<p>The arc of a <a>'circle'</a> element begins at the "3 o'clock" point
on the radius and progresses towards the "9 o'clock" point. The starting
point and direction of the arc are affected by the user space transform
in the same manner as the geometry of the element.</p>
+<p class="issue">Saying that it progresses towards the "9 o'clock point"
+is slightly unclear, since it doesn't say whether it goes clockwise
+or anti-clockwise. Maybe "progresses" implies clockwise, but it should
+say either way. (There is similar wording in the <a>'ellipse'</a> section
+too.)</p>
+
<p id="ExampleCircle01"><span class="example-ref">Example
circle01</span> consists of a <a>'circle'</a> element that is filled
with red and stroked with blue.</p>
<edit:example href='images/shapes/circle01.svg' name='circle01' description='circle filled with red and stroked with blue' link='yes' image='yes'/>
</edit:with>
diff --git a/master/struct.html b/master/struct.html
--- a/master/struct.html
+++ b/master/struct.html
@@ -95,16 +95,20 @@ explicit namespace prefix must be assign
</svg:svg>
]]></pre>
<p>Namespace prefixes can be specified on ancestor elements (illustrated
in the <a href="#EmbeddedSVGExample">above example</a>). For more
information, refer to the <a href="http://www.w3.org/TR/2006/REC-xml-names-20060816/"><cite>Namespaces in XML</cite></a> Recommendation
[<a href="refs.html#ref-XML-NS">XML-NS</a>].</p>
+<p class="issue">This section should talk about how a document's behavior
+is defined in terms of the DOM, and also explain how the HTML parser can
+create SVG fragments.</p>
+
<h3 id="SVGElement">The <span class='element-name'>'svg'</span> element</h3>
<!--
<table class="propdef eltdef">
<tr>
<th>Name:</th>
<td><span class="element-name" style="font-size: inherit">svg</span></td>
</tr>
@@ -213,17 +217,17 @@ information, refer to the <a href="http:
<div class="annotation svg2-requirement">
<table>
<tr>
<th>SVG 2 Requirement:</th>
<td>Support transforming <a>'svg'</a> elements.</td>
</tr>
<tr>
<th>Resolution:</th>
- <td><a href="http://www.w3.org/2011/10/28-svg-irc#T00-23-44">We will allow <span class='attr-name'>'transform'</span> on <span class='attr-name'>'svg'</span> in SVG 2.</a></td>
+ <td><a href="http://www.w3.org/2011/10/28-svg-irc#T00-23-44">We will allow <span class='attr-name'>'transform'</span> on <span class='element-name'>'svg'</span> in SVG 2.</a></td>
</tr>
<tr>
<th>Purpose:</th>
<td>To allow transforms on nested <a>'svg'</a> elements, in line with author expectations.</td>
</tr>
<tr>
<th>Owner:</th>
<td>Dirk (no action)</td>
@@ -241,33 +245,39 @@ information, refer to the <a href="http:
<dd>Indicates the SVG language version to which this
document fragment conforms.<br />
In <a href='http://www.w3.org/TR/2001/REC-SVG-20010904/'>SVG 1.0</a> [<a href='refs.html#ref-SVG10'>SVG10</a>],
this attribute was fixed to the value <span class='attr-value'>'1.0'</span>.
For SVG 1.1, the attribute should have the value
<span class='attr-value'>'1.1'</span>.<br />
<span class="anim-target"><a
href="animate.html#Animatable">Animatable</a>:
- no.</span></dd>
+ no.</span>
+ <p class="issue">What are we doing with the <a>'version'</a>
+ attribute? It's not clear whether it is useful to keep.</p>
+ </dd>
<dt id="SVGElementBaseProfileAttribute"><span
class="adef">baseProfile</span> = profile-name</dt>
<dd>Describes the minimum SVG language profile that the
author believes is necessary to correctly render the
content. The attribute does not specify any processing
restrictions; It can be considered metadata. For example,
the value of the attribute could be used by an authoring
tool to warn the user when they are modifying the document
beyond the scope of the specified base profile. Each SVG
profile should define the text that is appropriate for this
attribute.<br />
If the attribute is not specified, the effect is as if a
value of <span class='attr-value'>'none'</span> were specified.<br />
<span class="anim-target"><a
href="animate.html#Animatable">Animatable</a>:
- no.</span></dd>
+ no.</span>
+ <p class="issue">It's unlikely SVG 2 will have profiles as
+ 1.0 and 1.1 did. Do we keep the attribute in case others
+ wish to profile SVG? (Or should we be discouraging that?)</p></dd>
<dt id="SVGElementXAttribute"><span
class="adef">x</span> = "<span class="attr-value"><a
href="types.html#DataTypeCoordinate"><coordinate></a></span>"</dt>
<dd>(Has no meaning or effect on <a>outermost svg
elements</a>.)<br />
The x-axis coordinate of one corner of the rectangular
region into which an embedded <a>'svg'</a> element is placed.<br />
If the attribute is not specified, the effect is as if a
@@ -453,47 +463,63 @@ information, refer to the <a href="http:
</dd>
<dt><span class="attr-value">'onStart'</span></dt>
<dd>
The document's timeline starts at the moment the
<a>rootmost 'svg' element</a>'s
<em>start-tag</em>
<a href="http://www.w3.org/TR/2006/REC-xml-20060816/#sec-starttags">as defined in XML 1.0</a>
([<a href="refs.html#ref-XML10">XML10</a>], section 3.1) is fully parsed and processed.
+ <p class="issue">What about when the SVG document fragment is within
+ an XHTML document? Is there a single timeline for the whole document, and if so,
+ does it start at the parse time for the first <code><svg></code> start tag?
+ What about when using the HTML parser?</p>
</dd>
</dl>
<p>
The <a>lacuna value</a> is <span class="attr-value">'onLoad'</span>.
</p>
<p class="anim-target"><a href="animate.html#Animatable">Animatable</a>: no.</p>
</dd>
</dl>
</div>
<p>If an SVG document is likely to be referenced as a component
of another document, the author will often want to include a
<a>'viewBox'</a> attribute on the <a>outermost svg element</a> of the
referenced document. This attribute provides a convenient way to design
SVG documents to scale-to-fit into an arbitrary viewport.</p>
+<p class="issue">This paragraph feels out of place just after the list
+of attributes specific to <a>'svg'</a>.</p>
+
</edit:with>
<h2 id="Groups">Grouping: the <span class='element-name'>'g'</span> element</h2>
<h3 id="GroupsOverview">Overview</h3>
<p>The <a>'g'</a> element is a <a>container element</a> for grouping together
related <a>graphics elements</a>.</p>
<p>Grouping constructs, when used in conjunction with the <a>'desc'</a>
and <a>'title'</a> elements, provide information about document
structure and semantics. Documents that are rich in structure may be
rendered graphically, as speech, or as braille, and thus promote
<a href="access.html">accessibility</a>.</p>
+<p class="issue">That generously structured content with <a>'title'</a> and
+<a>'desc'</a> is more accessible isn't necessarily true. It also seems
+like a stretch to claim that documents "rich in structure" can be
+rendered as speech or braille, without specific references to how
+that can be achieved. More fundamental uses of grouping that should
+be mentioned are (a) for specifying common styling of inherited
+properties, and (b) for selecting elements to apply a group effect
+like filters and group opacity.</p>
+
<p>A group of elements, as well as individual objects, can be given
a name using the <a>'id'</a> attribute. Named groups are needed for
several purposes such as animation and re-usable objects.</p>
<p>An example:</p>
<edit:example href='images/struct/grouping01.svg' image='no' link='yes'/>
@@ -509,16 +535,18 @@ within it, to an arbitrary depth. Thus,
<g>
<g>
</g>
</g>
</g>
</svg>
]]></pre>
+<p class="issue">This is not a particularly useful example.</p>
+
<div class="annotation svg2-requirement">
<table>
<tr>
<th>SVG 2 Requirement:</th>
<td>Have unknown elements treated as <a>'g'</a> for the purpose of rendering.</td>
</tr>
<tr>
<th>Resolution:</th>
@@ -534,16 +562,21 @@ within it, to an arbitrary depth. Thus,
</tr>
</table>
</div>
<p>Any element that is not contained within a <a>'g'</a> is treated (at
least conceptually) as if it were in its own group.</p>
+<p class="issue">It is unclear what this sentence actually means.
+Does it mean that all operations that apply to groups (such as group
+opacity, filter effects, etc.) can apply to single elements too?
+If so, then it should say that.</p>
+
<h3 id="GElement">The <span class='element-name'>'g'</span> element</h3>
<edit:elementsummary name='g'/>
<h2 id="Head">Defining content for reuse, and the <span class='element-name'>'defs'</span> element</h2>
<h3 id="Overview">Overview</h3>
@@ -570,16 +603,21 @@ define a <a>'linearGradient'</a> element
inside of a <a>'defs'</a> element. Among the elements that are always
referenced: <a>'altGlyphDef'</a>, <a>'clipPath'</a>, <a>'cursor element'</a>,
<a>'filter element'</a>, <a>'linearGradient'</a>, <a>'marker element'</a>,
<a>'mask element'</a>, <a>'pattern'</a>, <a>'radialGradient'</a> and
<a>'symbol'</a>. Defining these elements inside of a <a>'defs'</a> element
promotes understandability of the SVG content and thus promotes
accessibility.</p>
+<p class="issue">Again this claim about accessibility is dubious.</p>
+
+<p class="issue">We should have a term for definition elements (since we
+now have a corresponding IDL interface) and reference it here.</p>
+
<h3 id="DefsElement">The <span class='element-name'>'defs'</span> element</h3>
<edit:elementsummary name='defs'/>
<p>The <a>'defs'</a> element is a container element for
<a href="struct.html#Head">referenced elements</a>. For understandability and
<a href="access.html">accessibility</a> reasons, it is recommended
that, whenever possible, referenced elements be defined inside
@@ -601,26 +639,35 @@ prevent those elements from being refere
<p>To provide some SVG user agents with an opportunity to
implement efficient implementations in streaming environments,
creators of SVG content are encouraged to place all elements
which are targets of local IRI references within a <a>'defs'</a>
element which is a direct child of one of the ancestors of the
referencing element. For example:</p>
+<p class="issue">Is this really about efficiency of implementations?
+If anything, it looks like it is ensuring progressively rendered
+documents don't make forward references that would otherwise
+cause an incorrect rendering before the referenced element is loaded.</p>
+
<edit:example href='images/struct/defs01.svg' link='yes'/>
<p>In the document above, the linear gradient is defined within
a <a>'defs'</a> element which is the direct child of the <a>'svg'</a>
element, which in turn is an ancestor of the <a>'rect'</a> element which
references the linear gradient. Thus, the above document conforms to the
guideline.</p>
<h2 id="DiscardElement">The <span class='element-name'>'discard'</span> element</h2>
+<p class="issue">Would this element be better as part of the Animation chapter?
+It also needs to be a member of the element categories that other animation elements
+are, and an IDL interface needs to be written for it.</p>
+
<edit:with element='discard'>
<div class="annotation svg2-requirement">
<table>
<tr>
<th>SVG 2 Requirement:</th>
<td>Have the <a>'discard'</a> element to declaratively discard elements from the document tree.</td>
</tr>
@@ -725,17 +772,17 @@ guideline.</p>
parameter. [<a href="refs.html#ref-DOM4">DOM4</a>] The <a>SVG user agent</a>
must remove the target node as well as all of its attributes and descendants.
</p>
<p>
After removal of the <a href="animate.html#TargetElement">target element</a>,
the <a href="#DiscardElement"><span class="element-name">'discard'</span></a>
element is no longer useful. It must also be discarded following the
target element removal. If the
- <a href="struct.html#DiscardElementHrefAttribute"><span class="attr-name">'xlink:href'</span></a>
+ <a href="struct.html#DiscardElementHrefAttribute"><span class="attr-name">'href'</span></a>
attribute has an <a>invalid</a> IRI reference
(the target element did not exist, for example),
the <a href="#DiscardElement"><span class="element-name">'discard'</span></a>
element itself must still be removed following activation.
</p>
<p>
<a href="http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-timing.html#Timing-HyperlinksAndTiming">Seeking backwards</a>
in the timeline ([<a href="refs.html#ref-SMIL">SMIL</a>], section 5.4.5)
@@ -807,35 +854,45 @@ and <span class='element-name'>'title'</
<div id='DescElement'>
<edit:elementsummary name='desc'/>
</div>
<div id='TitleElement'>
<edit:elementsummary name='title'/>
</div>
+<p class="issue">Is there any updated wording from SVG Tiny 1.2 that we
+should be using wrt tooltips?</p>
+
<p>Each <a>container element</a> or <a>graphics element</a> in an SVG drawing
can supply a <a>'desc'</a> and/or a <a>'title'</a> description string where
the description is text-only. When the current SVG document fragment is
rendered as SVG on visual media, <a>'desc'</a> and <a>'title'</a> elements are
not rendered as part of the graphics. User agents may, however, for example,
display the <a>'title'</a> element as a tooltip, as the pointing device moves
over particular elements. Alternate presentations are possible, both visual and
aural, which display the <a>'desc'</a> and <a>'title'</a> elements but do not
display <a>'path'</a> elements or other <a>graphics elements</a>. This is
readily achieved by using a different (perhaps user) style sheet. For deep
hierarchies, and for following <a>'use'</a> element references, it is
sometimes desirable to allow the user to control how deep they drill down into
descriptive text.</p>
+<p class="issue">I don't think it is easy to use a style sheet to cause
+an element's <a>'title'</a> to be rendered in place of its graphics.</p>
+
<p>In conforming SVG document fragments, any <a>'title'</a> element should be
the first child element of its parent. Note that those implementations that do
use <a>'title'</a> to display a tooltip often will only do so if the
<a>'title'</a> is indeed the first child element of its parent.</p>
+<p class="issue">Is it a SHOULD or a MUST that the <a>'title'</a> is the first
+element child? We should check if the statement about implementations looking
+at the first child for a tooltip is still accurate.</p>
+
<p>The following is an example. In typical operation, the SVG user agent would
not render the <a>'desc'</a> and <a>'title'</a> elements but would render the
remaining contents of the <a>'g'</a> element.</p>
<pre><![CDATA[
<?xml version="1.0" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg"
version="1.1" width="4in" height="3in">
@@ -863,16 +920,21 @@ from other namespaces. Here is an exampl
<mydoc:emph>mydoc</mydoc:emph> namespace.</mydoc:para>
</desc>
<g>
<!-- the picture goes here -->
</g>
</svg>
]]></pre>
+<p class="issue">We should say what purpose including other-namespaced
+markup in <a>'title'</a> and <a>'desc'</a> has. If it is just that
+these are basically metadata extension points for other profiles or
+uses of SVG, then we should say that.</p>
+
<p>Authors should always provide a <a>'title'</a> child element to the
<a>outermost svg element</a> within a stand-alone SVG document. The
<a>'title'</a> child element to an <a>'svg'</a> element serves the
purposes of identifying the content of the given SVG document
fragment. Since users often consult documents out of context,
authors should provide context-rich titles. Thus, instead of a
title such as "Introduction", which doesn't provide much
contextual background, authors should supply a title such as
@@ -896,28 +958,51 @@ mixed content rules. It is strongly reco
one <a>'desc'</a> and at most one <a>'title'</a> element appear as a
child of any particular element, and that these elements appear
before any other child elements (except possibly
<a>'metadata'</a> elements) or character data content. If user agents need to
choose among multiple <a>'desc'</a> or <a>'title'</a> elements for processing
(e.g., to decide which string to use for a tooltip), the user
agent shall choose the first one.</p>
+<p class="issue">We are no longer using DTDs. Are we happy to have
+a prose restriction for conforming SVG documents to have at most one
+<a>'title'</a> and <a>'desc'</a> child, and their positions?</p>
+
+<p class="issue">We have this sentence here about tooltips using the
+first element, which is stronger than the earlier note that some
+implementations do this. We should look at how HTML describes
+the <span class="attr-name">'title'</span> attribute and whether
+a tooltip is required, suggested, etc., and follow that.</p>
+
+<p class="issue">Once we have said how ARIA attributes can be used
+in SVG, we might want to define <a>'title'</a> and <a>'desc'</a>
+in a manner consistent with them, so that it is clear what it means
+for example for an element to have both a <a>'desc'</a> element
+child and an <span class="attr-name">'aria-describedby'</span>
+attribute.</p>
+
<h2 id="SymbolElement">The <span class='element-name'>'symbol'</span> element</h2>
<edit:elementsummary name='symbol'/>
<p>The <a>'symbol'</a> element is used to define graphical template objects
which can be instantiated by a <a>'use'</a> element.</p>
<p>The use of <a>'symbol'</a> elements for graphics that are used multiple
times in the same document adds structure and semantics. Documents that are rich
in structure may be rendered graphically, as speech, or as
braille, and thus promote <a href="access.html">accessibility</a>.</p>
+<p class="issue">Again this mention of accessibility through the use of
+structure (this time with <a>'symbol'</a> elements). We should include
+an example here or in the Accessibility appendix that shows how this
+is the case and what the actual effects of structuring content with
+<a>'symbol'</a> are.</p>
+
<p>The key distinctions between a <a>'symbol'</a> and a <a>'g'</a> are:</p>
<ul>
<li>A <a>'symbol'</a> element itself is not rendered. Only instances of a
<a>'symbol'</a> element (i.e., a reference to a <a>'symbol'</a> by
a <a>'use'</a> element) are rendered.</li>
<li>A <a>'symbol'</a> element has attributes <a>'viewBox'</a> and
@@ -949,16 +1034,20 @@ ancestors is set to <span class="prop-va
other <a>'use'</a> is potentially a
template object that can be re-used (i.e., "instanced") in the
SVG document via a <a>'use'</a>
element. The <a>'use'</a> element
references another element and indicates that the graphical
contents of that element is included/drawn at that given point
in the document.</p>
+<p class="issue"><a>'use'</a> is described as referencing template
+objects, but the parameters of the template are limited – just
+different inherited property values.</p>
+
<p>Unlike <a>'image'</a>, the <a>'use'</a> element cannot reference
entire files.</p>
<p>The <a>'use'</a> element has
optional attributes <a>'use/x'</a>, <a>'use/y'</a>, <a>'use/width'</a> and <a>'use/height'</a> which are used to map the
graphical contents of the referenced element onto a rectangular
region within the current coordinate system.</p>
@@ -968,41 +1057,52 @@ deeply cloned into a separate non-expose
the <a>'use'</a> element as its
parent and all of the <a>'use'</a>
element's ancestors as its higher-level ancestors. Because the
cloned DOM tree is non-exposed, the SVG Document Object Model
(DOM) only contains the <a>'use'</a>
element and its attributes. The SVG DOM does not show the
referenced element's contents as children of <a>'use'</a> element.</p>
+<p class="issue">We should define the behavior of <a>'use'</a>
+in terms of Web Components.</p>
+
<p>For user agents that support <a
href="styling.html#StylingWithCSS">Styling with CSS</a>, the
conceptual deep cloning of the referenced element into a
non-exposed DOM tree also copies any property values resulting
from <a href="http://www.w3.org/TR/2011/REC-CSS2-20110607/cascade.html">the CSS cascade</a>
([<a href="refs.html#ref-CSS21">CSS21</a>], chapter 6)
on the referenced element and its contents. CSS2 selectors can
be applied to the original (i.e., referenced) elements because
they are part of the formal document structure. CSS2 selectors
cannot be applied to the (conceptually) cloned DOM tree because
its contents are not part of the formal document structure.</p>
+<p class="issue">We should be requiring CSS styling in SVG 2.
+Also, hopefully, how styles can apply or not to elements in the
+shadow tree (and how event handling works, below) should be specified by how
+we define <a>'use'</a> to work in terms of Web Components.</p>
+
<p>Property inheritance, however, works as if the referenced
element had been textually included as a deeply cloned child of
the <a>'use'</a> element. The
referenced element inherits properties from the <a>'use'</a> element and the <a>'use'</a> element's ancestors. An
instance of a referenced element does not inherit properties
from the referenced element's original parents.</p>
<p>If event attributes are assigned to referenced elements,
then the actual target for the event will be the
<a>SVGElementInstance</a> object
within the "instance tree" corresponding to the given
referenced element.</p>
+<p class="issue">Once we define <a>'use'</a> in terms of
+Web Components, will we drop instance trees?</p>
+
<p>The event handling for the non-exposed tree works as if the
referenced element had been textually included as a deeply
cloned child of the <a>'use'</a>
element, except that events are dispatched to the <a>SVGElementInstance</a> objects. The
event's target and currentTarget attributes are set to the
<a>SVGElementInstance</a> that
corresponds to the target and current target elements in the
referenced subtree. An event propagates through the exposed and
@@ -1029,23 +1129,29 @@ it references specifies <span
class="prop-value">'visibility:hidden'</span> or <span
class="prop-value">'visibility:inherit'</span>, then that one
element will be hidden. However, if the referenced element
instead specifies <span
class="prop-value">'visibility:visible'</span>, then that
element will be visible even if the <a>'use'</a> element specifies <span
class="prop-value">'visibility:hidden'</span>.</p>
+<p class="issue">Why is <a>'visibility'</a> called out speciically? It might
+be better just to include an example that shows this.</p>
+
<p>Animations on a referenced element will cause the instances
to also be animated.</p>
<p>A <a>'use'</a> element has the
same visual effect as if the <a>'use'</a> element were replaced by the
following generated content:</p>
+<p class="issue">Except that the replaced content shouldn't affect
+how styles are matched.</p>
+
<ul>
<li>
<p><strong>If the <a>'use'</a> element references a <a>'symbol'</a> element</strong>:</p>
<p>In the generated content, the <a>'use'</a> will be replaced by <a>'g'</a>, where all attributes
from the <a>'use'</a> element
except for <a>'use/x'</a>, <a>'use/y'</a>, <a>'use/width'</a>, <a>'use/height'</a> and <a>'use/xlink:href'</a> are transferred to
the generated <a>'g'</a> element. An additional
@@ -1275,30 +1381,36 @@ the referenced SVG image are ignored (in
the <a>'preserveAspectRatio'</a> attribute on the root element in
the referenced SVG image is also ignored (see <a>'preserveAspectRatio'</a>
for details). Instead, the <a>'preserveAspectRatio'</a> attribute on
the referencing <a>'image'</a>
element defines how the SVG image content is fitted into the
viewport and the <a>'clip'</a> and <a>'overflow'</a> properties on the <a>'image'</a> element define how the SVG
image content is clipped (or not) relative to the viewport.</p>
+<p class="issue">Why does it make sense to override <a>'clip'</a>
+but not <a>'clip-path'</a>?</p>
+
<p>The value of the <a>'viewBox'</a> attribute to use when
evaluating the <a>'preserveAspectRatio'</a> attribute is
defined by the referenced content. For content that clearly
identifies a viewBox (e.g. an SVG file with the <a>'viewBox'</a> attribute on the
<a>outermost svg element</a>) that value should be used. For most
raster content (PNG, JPEG) the bounds of the image should be
used (i.e. the <a>'image'</a>
element has an implicit <a>'viewBox'</a> of <span class='attr-value'>'0 0 raster-image-width
raster-image-height'</span>). Where no value is readily available
(e.g. an SVG file with no <a>'viewBox'</a> attribute on the
<a>outermost svg element</a>) the <a>'preserveAspectRatio'</a> attribute is
ignored, and only the translation due to the <a>'x'</a> & <a>'y'</a> attributes of the viewport is
used to display the content.</p>
+<p class="issue">We should say how the use of an <code>#xywh</code>
+media fragment interacts with the the above.</p>
+
<p>For example, if the image element referenced a PNG or JPEG
and <span class="attr-value">preserveAspectRatio="xMinYMin
meet"</span>, then the aspect ratio of the raster would be
preserved (which means that the scale factor from image's
coordinates to current user space coordinates would be the same
for both X and Y), the raster would be sized as large as
possible while ensuring that the entire raster fits within the
viewport, and the top/left of the raster would be aligned with
@@ -1475,16 +1587,18 @@ ability to specify alternate viewing dep
capabilities of a given user agent or the user's language.</p>
<p>Attributes <a>'requiredFeatures'</a>, <a>'requiredExtensions'</a> and <a>'systemLanguage'</a> act as tests and
return either true or false results. The <a>'switch'</a> renders the first of
its children for which all of these attributes test true. If
the given attribute is not specified, then a true value is
assumed.</p>
+<p class="issue">It sounds strange to talk about attributes "returning" a value.</p>
+
<p>Similar to the <a>'display'</a> property, conditional processing
attributes only affect the direct rendering of elements and do
not prevent elements from being successfully referenced by
other elements (such as via a <a>'use'</a>).</p>
<p>In consequence:</p>
<ul>
@@ -1684,16 +1798,19 @@ situations, then it represents a simple
element whether to render the element or not.</p>
<h3 id="ApplicabilityOfTestAttributes">Applicability of test attributes</h3>
<p>The following list describes the applicability of the test
attributes to the elements that do not directly produce
rendering.</p>
+<p class="issue">This was already mentioned in the "Conditional processing overview"
+section. We should just describe this once.</p>
+
<ul>
<li>the test attributes do not effect the
<a>'mask element'</a>, <a>'clipPath'</a>, <a>'linearGradient'</a>,
<a>'radialGradient'</a> and <a>'pattern'</a> elements. The
test attributes on a referenced element do not affect the
rendering of the referencing element.</li>
<li>the test attributes do not effect the <a>'defs'</a>, and <a>'cursor element'</a> elements as they are not
@@ -1728,16 +1845,21 @@ rendering.</p>
document or external entity. Refer to the <a href="http://www.w3.org/TR/2009/REC-xmlbase-20090128/"><cite>XML Base</cite></a>
specification [<a href="refs.html#ref-XML-BASE">XML-BASE</a>].<br />
<span class="anim-target"><a
href="animate.html#Animatable">Animatable</a>:
no.</span></dd>
</dl>
</div>
+<p class="issue">Are we happy to keep promoting the use of <span class="attr-name">'xml:base'</span>?
+Is it a use case worth trying to include a more HTML-like syntax for – the <span class="element-name">'base'</span>
+element? We anyway need to define somewhere what effect the HTML <span class="element-name">'base'</span>
+element has on any SVG document fragments.</p>
+
<h3 id="LangSpaceAttrs">The <span class='attr-name'>'xml:lang'</span> and
<span class='attr-name'>'xml:space'</span> attributes</h3>
<p>Elements that might contain character data content have
attributes <a>'xml:lang'</a> and <a>'xml:space'</a>.</p>
<div class="annotation svg2-requirement">
<table>
@@ -1756,16 +1878,19 @@ attributes <a>'xml:lang'</a> and <a>'xml
<tr>
<th>Owner:</th>
<td>Chris (<a href="http://www.w3.org/Graphics/SVG/WG/track/actions/3004">ACTION-3004</a> and
<a href="http://www.w3.org/Graphics/SVG/WG/track/actions/3005">ACTION-3005</a>, done)</td>
</tr>
</table>
</div>
+<p class="issue">Should we be moving <span class="attr-name">'lang'</span> instead
+of <span class="attr-name">'xlink:lang'</span>?</p>
+
<div class="adef-list">
<p><em>Attribute definitions:</em></p>
<dl>
<dt id="XMLLangAttribute"><span
class="adef">xml:lang</span> = "<span
class="attr-value">languageID</span>"</dt>
<dd>Standard XML attribute to specify the language (e.g.,
English) used in the contents and attribute values of
@@ -2038,16 +2163,19 @@ this attribute.
<div>
Size of a pixel units (as defined by CSS2) along the x-axis of
the viewport, which represents a unit somewhere in the range
of 70dpi to 120dpi, and, on systems that support this, might
actually match the characteristics of the target medium. On
systems where it is impossible to know the size of a pixel, a
suitable default pixel size is provided.
+<p class="issue">Should this and the next three IDL attributes be removed?
+Are they implemented?</p>
+
</div>
</dd>
<dt id="__svg__SVGSVGElement__pixelUnitToMillimeterY" class="attribute"><b>pixelUnitToMillimeterY</b><span class="idl-type-parenthetical"> (readonly float)</span></dt>
<dd class="attribute">
<div>
Corresponding size of a pixel unit along the y-axis of the viewport.
@@ -2315,16 +2443,20 @@ effect on redrawing.
<dt id="__svg__SVGSVGElement__forceRedraw" class="operation">void <b>forceRedraw</b>()
</dt>
<dd class="operation">
<div>
In rendering environments supporting interactivity, forces the user agent
to immediately redraw all regions of the viewport that require updating.
+<p class="issue">Should this method be neutered as suspendRedraw and friends
+have been? Do implementations actually support painting in the middle of
+a running script by calling this method?</p>
+
</div>
</dd>
<dt id="__svg__SVGSVGElement__pauseAnimations" class="operation">void <b>pauseAnimations</b>()
</dt>
<dd class="operation">
<div>
Suspends (i.e., pauses) all currently running animations that are defined
@@ -2605,16 +2737,18 @@ by the supplied rectangle.
<dt id="__svg__SVGSVGElement__deselectAll" class="operation">void <b>deselectAll</b>()
</dt>
<dd class="operation">
<div>
Unselects any selected objects, including any selections of text strings
and type-in bars.
+<p class="issue">What is a type-in bar? Do we need <code>deselectAll</code> given
+we have DOM Selection?</p>
</div>
</dd>
<dt id="__svg__SVGSVGElement__createSVGNumber" class="operation"><a class="idlinterface" href="types.html#InterfaceSVGNumber">SVGNumber</a> <b>createSVGNumber</b>()
</dt>
<dd class="operation">
<div>
Creates an <a>SVGNumber</a> object outside of any document trees. The
@@ -2790,16 +2924,19 @@ are copied, the <var>matrix</var> parame
<dd class="operation">
<div>
Searches this SVG document fragment (i.e., the search is restricted to a
subset of the document tree) for an Element whose id is given by
<var>elementId</var>. If an Element is found, that Element is returned. If
no such element exists, returns null. Behavior is not defined if more
than one element has this id.
+<p class="issue">Do we need this? If so, can we define it in terms of
+calling Document.getElementById and checking whether the returned
+element is within the subtree?</p>
</div>
<dl class="operation">
<dt class="parameters-header">Parameters</dt>
<dd>
<ol class="parameters">
<li class="parameter first-child">
<div>DOMString <var>elementId</var></div>
diff --git a/master/style/default_svg.css b/master/style/default_svg.css
--- a/master/style/default_svg.css
+++ b/master/style/default_svg.css
@@ -274,20 +274,20 @@ h3.ready-for-wg-review,
.ready-for-wg-review {
background-color: #FBFBB6 ! important;
margin-left: -16px;
margin-right: -16px;
padding-left: 16px;
padding-right: 16px;
}
-body.chapter-index,
-body.chapter-index h1,
-body.chapter-index h2,
-body.chapter-index h3,
+.chapter-index,
+.chapter-index h1,
+.chapter-index h2,
+.chapter-index h3,
body.ready-for-wider-review,
h1.ready-for-wider-review,
h2.ready-for-wider-review,
h3.ready-for-wider-review,
.ready-for-wider-review > h1,
.ready-for-wider-review > h2,
.ready-for-wider-review > h3,
.ready-for-wider-review {
diff --git a/master/styling.html b/master/styling.html
--- a/master/styling.html
+++ b/master/styling.html
@@ -44,16 +44,19 @@ additional SVG-specific rules explicitly
specification, the normative definition of properties that are
shared with CSS and XSL is the definition of the property from
<a href="http://www.w3.org/TR/2011/REC-CSS2-20110607/">the CSS 2.1 specification</a>
[<a href="refs.html#ref-CSS21">CSS21</a>].</p>
<p id='PropertiesFromCSS2'>The following properties are shared between CSS 2.1 and SVG.
Most of these properties are also defined in XSL:</p>
+<p class="issues">This list needs to be updated. We should list all the properties
+we normative require support for, and which specification they are defined in.</p>
+
<ul>
<li>
<a href="text.html#FontPropertiesUsedBySVG">Font
properties</a>:
<ul>
<li><a>'font property'</a></li>
<li><a>'font-family'</a></li>
<li><a>'font-size'</a></li>
@@ -178,16 +181,18 @@ this specification:</p>
</li>
</ul>
<p>A table that lists and summarizes the styling properties can
be found in the <a href="propidx.html">Property Index</a>.</p>
<h2 id='StylingScenarios'>Usage scenarios for styling</h2>
+<p class="issues">Does this section add anything?</p>
+
<p>SVG has many usage scenarios, each with different needs.
Here are three common usage scenarios:</p>
<ol>
<li>
<p><strong>SVG content used as an exchange format (style
sheet language-independent)</strong>:</p>
@@ -290,16 +295,19 @@ presentation attribute with the same nam
class="attr-name">'fill'</span>) that can be used to specify a
value for the <a>'fill'</a> property on a given
element.</p>
<p class='issue'>We should state that for each property defined in
this specification, plus for each in a list here for properties in other
specifications, there exists a presentation attribute.</p>
+<p class="issue">Do we plan to grow a presentation attribute for each
+new CSS property that we support?</p>
+
<p>The following example shows how the <a>'fill'</a> and
<a>'stroke'</a> properties can be specified on a <a>'rect'</a> using the
<span class="attr-name">'fill'</span> and
<span class="attr-name">'stroke'</span> presentation attributes. The
rectangle will be filled with red and outlined with blue:</p>
<edit:example href='images/styling/PresentationAttributes.svg' image='no' link='yes'/>
@@ -408,16 +416,21 @@ animating the corresponding property. Th
occurs from animating the presentation attribute with
<span class='attr-value'>attributeType="XML"</span>
as occurs with animating the corresponding property with
<span class='attr-value'>attributeType="CSS"</span> (see
<a>'set/attributeType'</a>).</p>
<h2 id='StylingWithXSL'>Styling with XSL</h2>
+<p class="issue">How much do we really need to mention XSLT?
+Probably the only thing worth mentioning is that <code><?xml-stylesheet?></code>
+can be used in an XML serialized SVG document (not that we
+require support for this, though).</p>
+
<p>XSL style sheets [<a href="refs.html#ref-XSLT">XSLT</a>] [<a href="refs.html#ref-XSLT2">XSLT2</a>] define how to
transform XML content into something else, usually other XML.
When XSLT is used in conjunction with SVG, sometimes SVG
content will serve as both input and output for XSL style
sheets. Other times, XSL style sheets will take non-SVG content
as input and generate SVG content as output.</p>
<p>The following example uses an external XSL style sheet to
@@ -721,16 +734,25 @@ rules.</p>
</ul>
<h2 id='ReferencingExternalStyleSheets'>Referencing external style sheets</h2>
<p>External style sheets are referenced using the mechanism
documented in <a href="http://www.w3.org/1999/06/REC-xml-stylesheet-19990629/"><cite>Associating Style Sheets with XML documents Version 1.0</cite></a>
[<a href="refs.html#ref-XML-SS">XML-SS</a>].</p>
+<p class="issue">We should suggest <code>@import</code> as a means for
+referencing external CSS style sheets that will also work in an HTML5
+document.</p>
+
+<p class="issue">Where is it defined that an HTML <span class="element-name">'link'</span>
+element can cause a style sheet to be loaded and applied to SVG content? Should
+we allow (an SVG or HTML namespace) <span class="element-name">'link'</span> element
+in an SVG document fragment?</p>
+
<h2 id='StyleElement'>The <span class="element-name">'style'</span> element</h2>
<div class="annotation svg2-requirement">
<table>
<tr>
<th>SVG 2 Requirement:</th>
<td>Add HTML5 <span class='element-name'>'style'</span> element attributes to SVG's <a>'style element'</a> element.</td>
</tr>
@@ -991,16 +1013,20 @@ descendants.</p>
or style attributes, or in external style sheets linked with
the style sheet processing instruction) apply across the
entire document, including those parts of it in the SVG
namespace. To get different styling for the SVG part, use the
<a>'style attribute'</a> attribute, or put an <a>'id'</a> on the <a>'svg'</a> element and use
contextual CSS selectors, or use XSL selectors.</dd>
</dl>
+<p class="issue">As part of unifying HTML's and SVG's
+<span class="element-name">'style'</span> element, we should
+allow and mention scoped style sheets here.</p>
+
<h2 id='UAStyleSheet'>User agent style sheet</h2>
<p>The user agent shall maintain a
<a href='http://www.w3.org/TR/2011/REC-CSS2-20110607/cascade.html#cascade'>user agent style sheet</a>
([<a href='refs.html#ref-CSS21'>CSS21</a>], section 6.4)
for elements in the SVG namespace for
<a href='http://www.w3.org/TR/2011/REC-CSS2-20110607/media.html#visual-media-group'>visual media</a>
([<a href="refs.html#ref-CSS21">CSS21</a>], section 7.3.1).
@@ -1009,16 +1035,24 @@ using CSS syntax; however, user agents a
the behavior that corresponds to this default style sheet even
if CSS style sheets are not supported in the user agent:</p>
<pre>
svg, symbol, image, marker, pattern, foreignObject { overflow: hidden }
svg { width:attr(width); height:attr(height) }
</pre>
+<p class="issue">This needs to be reviewed. It should at least
+use <code>@namespace</code> to cause the rules to match only
+SVG elements. <code>attr(width)</code> won't do the right
+thing if the <span class="attr-name">'width'</span> attribute does
+not use a unit. And what about when the attributes are being
+animated? Presumably <code>attr()</code> doesn't look at animated
+values.</p>
+
<p>The first line of the above user agent style sheet will
cause the <a href="masking.html#InitialClippingPath">initial
clipping path</a> to be established at the bounds of the <a
href="coords.html#ViewportSpace">initial viewport</a>.
Furthermore, it will cause new clipping paths to be established
at the bounds of the listed elements, all of which are <a
href="coords.html#ElementsThatEstablishViewports">elements that
establish a new viewport</a>. (Refer to the description of
@@ -1049,16 +1083,21 @@ that can contain character data content,
<a>'title'</a>
<a>'tspan'</a>,
<a>'tref'</a>,
<a>'altGlyph'</a> and
<a>'textPath'</a>.
On user agents that support aural style sheets, the following CSS 2.1
properties can be applied:</p>
+<p class="issue">The above list misses <a>'a'</a>, which can be
+within a <a>'text'</a> element. Is there a conformance class in CSS
+we can link to for "user agents that support aural style sheets"?
+Are aural properties still relevant?</p>
+
<table class='vert'>
<tr>
<th>Aural property</th>
<th>Definition in [<a href='refs.html#ref-CSS21'>CSS21</a>]</th>
</tr>
<tr>
<td id="AzimuthProperty"><span class="attr-name">'azimuth'</span></td>
<td><a href="http://www.w3.org/TR/2011/REC-CSS2-20110607/aural.html#propdef-azimuth">Section A.8</a></td>
diff --git a/master/types.html b/master/types.html
--- a/master/types.html
+++ b/master/types.html
@@ -1495,16 +1495,19 @@ href="types.html#DataTypeColor"><colo
</div>
<h3 id="InterfaceSVGElement">Interface SVGElement</h3>
<p>All of the SVG DOM interfaces that correspond directly to elements in the
SVG language (such as the <a>SVGPathElement</a> interface for the
<a>'path'</a> element) derive from the <a>SVGElement</a> interface.</p>
+<p class="issue">SVGElement needs to gain IDL attributes for all of the
+event listener attributes that are supported.</p>
+
<pre class="idl">interface <b>SVGElement</b> : <a class="idlinterface" href="http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-745549614">Element</a> {
attribute DOMString <a href="types.html#__svg__SVGElement__id">id</a>;
attribute DOMString <a href="types.html#__svg__SVGElement__xmlbase">xmlbase</a>;
readonly attribute <a class="idlinterface" href="types.html#InterfaceSVGAnimatedString">SVGAnimatedString</a> <a href="types.html#__svg__SVGElement__className">className</a>;
readonly attribute <a class="idlinterface" href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSSStyleDeclaration">CSSStyleDeclaration</a> <a href="types.html#__svg__SVGElement__style">style</a>;
<a class="idlinterface" href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSSValue">CSSValue</a> <a href="types.html#__svg__SVGElement__getPresentationAttribute">getPresentationAttribute</a>(DOMString name);
Received on Friday, 14 September 2012 10:10:29 UTC