--- a/master/concepts.html Fri Sep 14 20:03:58 2012 +1000
+++ b/master/concepts.html Fri Sep 14 20:03:58 2012 +1000
@@ -16,6 +16,9 @@
<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
@@ -194,6 +197,9 @@
<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>
--- a/master/coords.html Fri Sep 14 20:03:58 2012 +1000
+++ b/master/coords.html Fri Sep 14 20:03:58 2012 +1000
@@ -48,6 +48,9 @@
([<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>
@@ -96,6 +99,9 @@
<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
@@ -111,6 +117,11 @@
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
@@ -235,7 +246,7 @@
<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>,
@@ -353,6 +364,14 @@
</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>
@@ -928,6 +947,18 @@
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>
@@ -968,6 +999,9 @@
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
@@ -1003,6 +1037,8 @@
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>
@@ -1314,6 +1350,9 @@
<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>
@@ -2684,6 +2723,9 @@
<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>
--- a/master/intro.html Fri Sep 14 20:03:58 2012 +1000
+++ b/master/intro.html Fri Sep 14 20:03:58 2012 +1000
@@ -74,6 +74,8 @@
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).
@@ -81,6 +83,8 @@
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>
@@ -95,6 +99,11 @@
<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
@@ -218,6 +227,13 @@
<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
--- a/master/painting.html Fri Sep 14 20:03:58 2012 +1000
+++ b/master/painting.html Fri Sep 14 20:03:58 2012 +1000
@@ -1070,6 +1070,10 @@
</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>
--- a/master/paths.html Fri Sep 14 20:03:58 2012 +1000
+++ b/master/paths.html Fri Sep 14 20:03:58 2012 +1000
@@ -26,6 +26,9 @@
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
@@ -172,6 +175,26 @@
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
--- a/master/pservers.html Fri Sep 14 20:03:58 2012 +1000
+++ b/master/pservers.html Fri Sep 14 20:03:58 2012 +1000
@@ -1779,6 +1779,8 @@
<pre class="idl"></pre>
+<p class="issue">IDL needs to be added for SVGSolidColorElement.</p>
+
</edit:with>
<h3 id="InterfaceSVGGradientElement">Interface SVGGradientElement</h3>
--- a/master/shapes.html Fri Sep 14 20:03:58 2012 +1000
+++ b/master/shapes.html Fri Sep 14 20:03:58 2012 +1000
@@ -348,6 +348,12 @@
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>
--- a/master/struct.html Fri Sep 14 20:03:58 2012 +1000
+++ b/master/struct.html Fri Sep 14 20:03:58 2012 +1000
@@ -100,6 +100,10 @@
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>
<!--
@@ -218,7 +222,7 @@
</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>
@@ -246,7 +250,10 @@
<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
@@ -262,7 +269,10 @@
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>
@@ -458,6 +468,10 @@
<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>
@@ -474,6 +488,9 @@
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>
@@ -489,6 +506,15 @@
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>
@@ -514,6 +540,8 @@
</svg>
]]></pre>
+<p class="issue">This is not a particularly useful example.</p>
+
<div class="annotation svg2-requirement">
<table>
<tr>
@@ -539,6 +567,11 @@
<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'/>
@@ -575,6 +608,11 @@
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'/>
@@ -606,6 +644,11 @@
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
@@ -616,6 +659,10 @@
<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">
@@ -730,7 +777,7 @@
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>
@@ -812,6 +859,9 @@
<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
@@ -826,11 +876,18 @@
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>
@@ -868,6 +925,11 @@
</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
@@ -901,6 +963,23 @@
(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'/>
@@ -913,6 +992,12 @@
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>
@@ -954,6 +1039,10 @@
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>
@@ -973,6 +1062,9 @@
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
@@ -985,6 +1077,11 @@
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
@@ -998,6 +1095,9 @@
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>
@@ -1034,6 +1134,9 @@
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>
@@ -1041,6 +1144,9 @@
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>
@@ -1280,6 +1386,9 @@
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
@@ -1294,6 +1403,9 @@
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
@@ -1480,6 +1592,8 @@
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
@@ -1689,6 +1803,9 @@
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>,
@@ -1733,6 +1850,11 @@
</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>
@@ -1761,6 +1883,9 @@
</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>
@@ -2043,6 +2168,9 @@
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>
@@ -2320,6 +2448,10 @@
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>
@@ -2610,6 +2742,8 @@
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>
@@ -2795,6 +2929,9 @@
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">
--- a/master/styling.html Fri Sep 14 20:03:58 2012 +1000
+++ b/master/styling.html Fri Sep 14 20:03:58 2012 +1000
@@ -49,6 +49,9 @@
<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
@@ -183,6 +186,8 @@
<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>
@@ -295,6 +300,9 @@
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
@@ -413,6 +421,11 @@
<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
@@ -726,6 +739,15 @@
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">
@@ -996,6 +1018,10 @@
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
@@ -1014,6 +1040,14 @@
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
@@ -1054,6 +1088,11 @@
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>
--- a/master/types.html Fri Sep 14 20:03:58 2012 +1000
+++ b/master/types.html Fri Sep 14 20:03:58 2012 +1000
@@ -1500,6 +1500,9 @@
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>;