[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