[e] (2) notes for dashed lines

git-svn-id: http://svn.whatwg.org/webapps@813 340c8d12-0b0e-0410-8428-c7bf67bfef74

index

@@ -16231,7 +16231,25 @@ interface <dfn id=imagedata>ImageData</dfn> {
   <!-- XXX this section doesn't say what these attributes return or
   what they do on setting. not a big deal; it's pretty obvious. but if
   anyone complains, we'll have to add it -->
-  <!-- XXXv3 dashed lines have been requested -->
+  <!--
+XXXv3 dashed lines have been requested.  Philip Taylor provides these
+notes on what would need to be defined for dashed lines:
+> I don't think it's entirely trivial to add, to the detail that's
+> necessary in a specification. The common graphics APIs (at least
+> Cairo, Quartz and java.awt.Graphics, and any SVG implementation) all
+> have dashes specified by passing an array of dash lengths (alternating
+> on/off), so that should be alright as long as you define what units
+> it's measured in and what happens when you specify an odd number of
+> values and how errors are handled and what happens if you update the
+> array later. But after that, what does it do when stroking multiple
+> subpaths, in terms of offsetting the dashes? When you use strokeRect,
+> where is offset 0? Does moveTo reset the offset? How does it interact
+> with lineCap/lineJoin? All the potential issues need test cases too,
+> and the implementations need to make sure they handle any edge cases
+> that the underlying graphics library does differently. (SVG Tiny 1.2
+> appears to skip some of the problems by leaving things undefined and
+> allowing whatever behaviour the graphics library has.)
+  -->
 
   <h6 id=shadows><span class=secno>3.14.11.1.6. </span><dfn
    id=shadows0>Shadows</dfn></h6>

source

@@ -13818,7 +13818,25 @@ interface <dfn>ImageData</dfn> {
   what they do on setting. not a big deal; it's pretty obvious. but if
   anyone complains, we'll have to add it -->
 
-  <!-- XXXv3 dashed lines have been requested -->
+  <!--
+XXXv3 dashed lines have been requested.  Philip Taylor provides these
+notes on what would need to be defined for dashed lines:
+> I don't think it's entirely trivial to add, to the detail that's
+> necessary in a specification. The common graphics APIs (at least
+> Cairo, Quartz and java.awt.Graphics, and any SVG implementation) all
+> have dashes specified by passing an array of dash lengths (alternating
+> on/off), so that should be alright as long as you define what units
+> it's measured in and what happens when you specify an odd number of
+> values and how errors are handled and what happens if you update the
+> array later. But after that, what does it do when stroking multiple
+> subpaths, in terms of offsetting the dashes? When you use strokeRect,
+> where is offset 0? Does moveTo reset the offset? How does it interact
+> with lineCap/lineJoin? All the potential issues need test cases too,
+> and the implementations need to make sure they handle any edge cases
+> that the underlying graphics library does differently. (SVG Tiny 1.2
+> appears to skip some of the problems by leaving things undefined and
+> allowing whatever behaviour the graphics library has.)
+  -->
 
 
   <h6><dfn>Shadows</dfn></h6>