W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2012

svg2: 3 new changesets

From: SVG Working Group repository <cam@mcc.id.au>
Date: Fri, 14 Sep 2012 03:09:18 -0700
Message-Id: <hg.8768ba6b67e2.1347617358.3034738116371802840@ps58493.dreamhostps.com>
To: public-svg-wg@w3.org
details:   https://svgwg.org/hg/svg2/rev/8768ba6b67e2
changeset: 366:8768ba6b67e2
user:      Cameron McCormack <cam@mcc.id.au>
date:      Fri Sep 14 20:03:58 2012 +1000
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
changeset: 367:1b6855728789
user:      Cameron McCormack <cam@mcc.id.au>
date:      Fri Sep 14 20:03:58 2012 +1000
Add some random issues to the spec.

details:   https://svgwg.org/hg/svg2/rev/13274fa208d7
changeset: 368:13274fa208d7
user:      Cameron McCormack <cam@mcc.id.au>
date:      Fri Sep 14 20:03:58 2012 +1000
Note that Gecko now supports objectFill, objectStroke and objectStrokeWidth.


 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. -->
+<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>
   <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>
+<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
 <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>
   <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
 <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>'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
+<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
 <p id="TransformList">The term <var>&lt;transform-list&gt;</var> used by this specification is equivalent to a list of <var>&lt;transform-functions&gt;</var>, the value of the <a>'transform'</a>
 <div class="note">See the CSS3 Transforms spec for the description of the <a>'transform'</a> property and the value of <var>&lt;transform-functions&gt;</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>
   <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'>
     <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
 <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>
     <dt id="SVGGlobalTransformAttributeDefinition"><span class="adef">svg:transform</span> = <span class="attr-value">"<a href="#TransformProperty">&lt;transform&gt;</a>" | "none"</span></dt>
         <dt><span class="attr-value"><a href="#TransformProperty">&lt;transform&gt;</a></span></dt>
@@ -2679,16 +2718,19 @@ Sets the transform type to SVG_TRANSFORM
 <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&#xA0;"</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>
 <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>
       <td>Chris (<a href="http://www.w3.org/Graphics/SVG/WG/track/actions/3094">ACTION-3094</a>)</td>
+<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">&lt;paint&gt;</span>, which is specified as follows:</p>
         <td><span class="prop-value">none |<br />
@@ -1065,16 +1068,20 @@ description of positions along a path th
       <td>Cameron (no action)</td>
+<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>
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
+<p class="issue">Also they can be used by <a>'mpath'</a> and
 <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
 <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>&lt;path d="M 100,100&amp;#10;L 200,150"/&gt;</pre>
+<p>but it's not likely that you'd want to.</p>
+<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>
   <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>
 <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>
 <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
 <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'/>
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
 <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">
     <td><span class="element-name" style="font-size: inherit">svg</span></td>
@@ -213,17 +217,17 @@ information, refer to the <a href="http:
 <div class="annotation svg2-requirement">
       <th>SVG 2 Requirement:</th>
       <td>Support transforming <a>'svg'</a> elements.</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='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>
       <td>To allow transforms on nested <a>'svg'</a> elements, in line with author expectations.</td>
       <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
-    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
-    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
     <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:
         <dt><span class="attr-value">'onStart'</span></dt>
           The document's timeline starts at the moment the
           <a>rootmost 'svg' element</a>'s
           <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>&lt;svg&gt;</code> start tag?
+	  What about when using the HTML parser?</p>
         The <a>lacuna value</a> is <span class="attr-value">'onLoad'</span>.
       <p class="anim-target"><a href="animate.html#Animatable">Animatable</a>: no.</p>
 <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>
 <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, 
+<p class="issue">This is not a particularly useful example.</p>
 <div class="annotation svg2-requirement">
       <th>SVG 2 Requirement:</th>
       <td>Have unknown elements treated as <a>'g'</a> for the purpose of rendering.</td>
@@ -534,16 +562,21 @@ within it, to an arbitrary depth. Thus, 
 <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
+<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
 <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">
       <th>SVG 2 Requirement:</th>
       <td>Have the <a>'discard'</a> element to declaratively discard elements from the document tree.</td>
@@ -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.
   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.
   <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 id='TitleElement'>
 <edit:elementsummary name='title'/>
+<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>
 <?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>
     <!-- the picture goes here -->
+<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>
 <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>
   <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
+<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>
     <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> &amp; <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
+<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>
@@ -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
+<p class="issue">This was already mentioned in the "Conditional processing overview"
+section.  We should just describe this once.</p>
   <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
+<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">
@@ -1756,16 +1878,19 @@ attributes <a>'xml:lang'</a> and <a>'xml
       <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>
+<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>
         <dt id="XMLLangAttribute"><span
         class="adef">xml:lang</span> = "<span
         <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.
 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>
 <dt id="__svg__SVGSVGElement__pixelUnitToMillimeterY" class="attribute"><b>pixelUnitToMillimeterY</b><span class="idl-type-parenthetical"> (readonly float)</span></dt>
 <dd class="attribute">
 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>()
 <dd class="operation">
 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>
 <dt id="__svg__SVGSVGElement__pauseAnimations" class="operation">void <b>pauseAnimations</b>()
 <dd class="operation">
 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>()
 <dd class="operation">
 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>
 <dt id="__svg__SVGSVGElement__createSVGNumber" class="operation"><a class="idlinterface" href="types.html#InterfaceSVGNumber">SVGNumber</a> <b>createSVGNumber</b>()
 <dd class="operation">
 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">
 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>
 <dl class="operation">
 <dt class="parameters-header">Parameters</dt>
 <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 h1,
-body.chapter-index h2,
-body.chapter-index h3,
+.chapter-index h1,
+.chapter-index h2,
+.chapter-index h3,
 .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>
     <a href="text.html#FontPropertiesUsedBySVG">Font
       <li><a>'font property'</a></li>
@@ -178,16 +181,18 @@ this specification:</p>
 <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>
     <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
 <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
 <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>&lt;?xml-stylesheet?&gt;</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>
 <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
+<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">
       <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>
@@ -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>
+<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>
 svg, symbol, image, marker, pattern, foreignObject { overflow: hidden }
 svg { width:attr(width); height:attr(height) }
+<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
 <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>'altGlyph'</a> and
 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'>
         <th>Aural property</th>
         <th>Definition in [<a href='refs.html#ref-CSS21'>CSS21</a>]</th>
         <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">&lt;colo
 <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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 September 2012 10:10:29 GMT