[html5] r813 - /

whatwg at whatwg.org whatwg at whatwg.org
Tue May 15 16:01:09 PDT 2007


Author: ianh
Date: 2007-05-15 16:01:05 -0700 (Tue, 15 May 2007)
New Revision: 813

Modified:
   index
   source
Log:
[e] (2) notes for dashed lines

Modified: index
===================================================================
--- index	2007-05-15 22:54:10 UTC (rev 812)
+++ index	2007-05-15 23:01:05 UTC (rev 813)
@@ -16231,7 +16231,25 @@
   <!-- 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>

Modified: source
===================================================================
--- source	2007-05-15 22:54:10 UTC (rev 812)
+++ source	2007-05-15 23:01:05 UTC (rev 813)
@@ -13818,7 +13818,25 @@
   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>




More information about the Commit-Watchers mailing list