Move normative parts of implnote.html to chapters

Section "Error Processing": - moved to the end of the "Document Conformance Classes" (in conform.html) - passive-voiced "shall" commands rewritten as requirements on user agents - the example of a general error rewritten to refer to the document conformance requirements - it's made explicit that these general error processing rules can be overridden by more specific rules elsewhere in the spec. Section "Clamping values which are restricted to a particular range": - moved to types.html (Basic Data Types and Interfaces chapter) - paragraphs re color and opacity removed, since clamping behavior of those properties is defined in CSS Color - remaining paragraph generalized, with clarifications that * it only applies if more specific rules aren't given elsewhere * it applies to clamping for device capabilities as well as per spec Section "Elliptical Arc Implementation Notes": - the normative section on out-of-range parameters is moved to the Paths chapter implementation notes. - the syntax is updated to use parameter names defined in the chapter, not the mathematical notation defined in the appendix - the remaining sections on arc parameterization and conversion are tidied up to stand alone in the appendix - Equation numbering is made independent of Appendix/section numbering (which was no longer correct). The rest of the "Implementation Notes" section is paths.html is reorganized into logical sections. The contradictory statement that "A non-positive radius value is an error." is removed. (Elsewhere, the spec says to use the absolute value of negative radii, and most browser implementations match; see #324.) Section "Text selection implementation notes": - moved to the end of the "Text selection and clipboard operations" section (in text.html) Section "Printing implementation notes": - moved to the end of "Conforming SVG Viewers" section (in conform.html) Cross-references to these sections have also been updated. Changes appendix entries have been made. Links to PR will need to be updated once a PR is generated.
w3c · svgeesus · Sep 23, 2018 · Sep 18, 2018 · Sep 19, 2018 · Sep 20, 2018
commit f3a7d1e3196275f1ed99fab0db72f75b89ececf1
diff --git a/master/changes.html b/master/changes.html
@@ -123,7 +123,7 @@ <h3 id="conform">Conformance Criteria chapter (Appendix in SVG 1.1)</h3>
     move the corresponding definitions from the Document structure chapter to here.
   </li>
   <li>Move the non-normative section on suggested methods for generating
-    high-precision graphics to the Implementation Requirements appendix.
+    high-precision graphics to the Implementation Notes appendix.
   </li>
 </ul>
 
@@ -525,6 +525,11 @@ <h3 id="paths">Paths chapter</h3>
   <li>Clarified that percentage distances are not affected by zero <a>'pathLength'</a>.
     <a href="https://github.com/w3c/svgwg/issues/383">Issue discussion</a>
     <a href="https://github.com/w3c/svgwg/pull/485">Edits</a></li>
+  <li>Reorganized the Implementation Notes section into logical subsections
+  (including the section on out-of-bounds arc parameters,
+  which was formerly in the Implementation Notes appendix).
+    <a href="https://github.com/w3c/svgwg/pull/">Edits</a>
+  </li>
 </ul>
 </div>
 
@@ -1001,13 +1006,37 @@ <h3 id="escript">ECMAScript Language Binding appendix (SVG 1.1 only)</h3>
   Web IDL.</li>
 </ul>
 
-<h3 id="impreqs"> Implementation Requirements appendix</h3>
+<h3 id="impreqs">Implementation Notes appendix (was Implementation Requirements in SVG 1.1)</h3>
 
+<div class="changed-since-cr1">
 <ul>
-  <li class="'changed-since-cr1'">Removed un-implemented out-of-range flag values note.
+  <li>Removed un-implemented out-of-range flag values note.
     <a href="https://github.com/w3c/svgwg/issues/324">Issue discussion</a>
     <a href="https://github.com/w3c/svgwg/pull/516">Edits</a></li>
 </ul>
+</div>
+
+<div class="changed-since-cr1 cr2">
+  <ul>
+    <li>Moved normative sections into chapters,
+        and renamed appendix to Implementation Notes:
+      <ul>
+        <li>Error Processing is now in Conformance Criteria.</li>
+        <li>Clamping Values is now in Data Types and Interfaces,
+        and sections re colors and opacity have been removed
+        (clamping behavior of these properties is defined in CSS Color).
+        </li>
+        <li>The normative parts of the Elliptical Arc Implementation Notes
+        are now in the Paths chapter, with other implementation requirements for paths</li>
+        <li>Text selection implementation notes is now in Text,
+        with the main section on Text Selection.</li>
+        <li>Printing Implementation Notes is now in Conformance Criteria.</li>
+      </ul>
+      <a href="https://github.com/w3c/svgwg/issues/520">Issue discussion</a>
+      <a href="https://github.com/w3c/svgwg/pull/">Edits</a>
+    </li>
+  </ul>
+</div>
 
 <h3 id="access">Accessibility Support appendix</h3>
 

diff --git a/master/conform.html b/master/conform.html
@@ -698,6 +698,50 @@ <h3 id="ConformingSVGStandAloneFiles">Conforming SVG Stand-Alone Files</h3>
   </li>
 </ul>
 
+<h3 id="ErrorProcessing">Error processing</h3>
+
+<p>There are various scenarios where an SVG document fragment
+is technically <em>in error</em>:</p>
+
+<ul>
+  <li>The document or DOM subtree is not-conforming for its document type,
+  as described in the previous sections.
+  </li>
+
+  <li>Other situations that are described as being <em>in error</em> in this
+  specification, such as incorrect attribute values.</li>
+</ul>
+
+<p>A dynamic document can go in and out of error over time. For
+example, document changes from the <a href="svgdom.html">SVG DOM</a>
+or from <a href="https://svgwg.org/specs/animations/">animation</a> can cause
+a document to become <em>in error</em> and a further change can
+cause the document to become correct again.</p>
+
+<p>User agents must use the following error processing rules whenever a document
+is in error,
+unless other sections of this specification define more specific rules for handling the particular error type:</p>
+
+<ul>
+  <li>
+    The document rendering shall continue after encountering element which has an error. The element or its part that is in error won't be rendered.
+  </li>
+
+  <li>If the user agent has access to an error reporting
+  capability such as status bar or console, it is recommended that the
+  user agent provide whatever additional detail it can to
+  enable the user or developer to quickly find the source of
+  the error. For example, the user agent might provide an error
+  message along with a line number and character number at
+  which the error was encountered.</li>
+</ul>
+
+<p>Because of situations where a block of scripting changes
+might cause a given SVG document fragment to go into and out of
+error, the user agent should only apply error processing at times when document
+presentation (e.g., rendering to the display device) is
+updated.</p>
+
 <h2 id="SoftwareConformanceClasses">Software Conformance Classes</h2>
 
 <p>For software, the requirements for conformance depend
@@ -1031,7 +1075,7 @@ <h3 id="ConformingSVGViewers">Conforming SVG Viewers</h3>
   headers are missing or specify a value that does not match the
   compression method that has been applied to the content, then
   the SVG viewer must not render the content and must treat the
-  document as being <a href="implnote.html#ErrorProcessing">in error</a>.</li>
+  document as being <a href="#ErrorProcessing">in error</a>.</li>
 
   <li>The viewer must use at least single-precision floating point for intermediate calculations on any numerical operations for conversion of coordinates. However, in order to prevent the rounding error on coordinate transformation, at least double-precision floating point computation must be used on <a>CTM</a> generation processing. Such minimum typical computation way is expressed with following formulas.
 
@@ -1356,6 +1400,34 @@ <h3 id="ConformingSVGViewers">Conforming SVG Viewers</h3>
 properties that can refer to raster image resources (e.g.,
 <span class="property">'background-image'</span>).</p>
 
+<h4 id="PrintingImplementationNotes">Printing implementation notes</h4>
+
+<p>For user agents which support both zooming on display
+devices and printing, it is recommended that the default
+printing option produce printed output that reflects the
+display device's current view of the current SVG document
+fragment (assuming there is no media-specific styling), taking
+into account any zooming and panning done by the user, the
+current state of animation, and any document changes due to DOM
+and scripting.</p>
+
+<p>Thus, if the user zooms into a particular area
+of a map on the display device and then requests a hardcopy,
+the hardcopy should show the same view of the map as appears on
+the display device. If a user pauses an animation and prints,
+the hardcopy should show the same graphics as the currently
+paused picture on the display device. If scripting has added or
+removed elements from the document, then the hardcopy should
+reflect the same changes that would be reflected on the
+display.</p>
+
+<p>When an SVG document is rendered on a static-only device
+such as a printer which does not support SVG's animation and
+scripting and facilities, then the user agent shall ignore any
+animation and scripting elements in the document and render the
+remaining graphics elements according to the rules in this
+specification.</p>
+
 <h3 id="ConformingHighQualitySVGViewers">Conforming High-Quality SVG Viewer</h3>
 
 <p>In order for a <a>conforming SVG viewer</a> to be considered