W3C home > Mailing lists > Public > www-svg@w3.org > April 2011

oddities with dasharray, markers and use

From: David Dailey <ddailey@zoominternet.net>
Date: Sun, 3 Apr 2011 17:04:02 -0400
To: <www-svg@w3.org>
Cc: <yan.li@sru.edu>
Message-ID: <001501cbf242$a8e6c350$fab449f0$@net>
Hi folks,


(I'm not sure what about this is browser bugs and what is spec bugs)


Take a look at the examples at
http://granite.sru.edu/~ddailey/svg/tracks.svg .


1.       In IE9 and ASV, the markers cannot be applied to a <use> even
though stroke-dasharray can.

2.       In Chrome (and ASV and IE9 when no use is involved), the markers
inherit the dash array of the stroke. Not elsewhere though.

3.       In Firefox (but nowhere else), if you click on the brown lines of
the dasharray or on the silver line underneath, (just the top uses and not
the second reuse), the event bubbles through to the defined path.  (this
idiosyncracy of <use> in the larger case, and whether or not the event finds
the original is rather startling to many authors, who expect the <use> to
behave more as if it is a clone when it comes to event handling - perhaps
this relates to a recent call for input concerning <use>

4.       The transform applied to the two <use>s of T1 in the lower example,
interestingly, does not translate the dasharray. This might come as a bit of
a shock to some.

5.       It would be awfully nice for cartographic purposes to be able to
apply markers at regular intervals along a path, rather than just at the
vertices (as per SVG 1.1, at least). Sure, one can do this with script, but
then the slope of the curve has to be calculated and so forth. It would
allow for a much broader class of path decorations appropriate to such
things as trails, rails, highways, borders, lake boundaries etc.


My guesses above:

1.       Is a bug in IE and ASV

2.       Is a bug in Chrome, ASV and IE

3.       Is a bug in Firefox (though I think I prefer it to how Opera,
WebKit, IE and ASV handle it)

4.       Is how the spec is written, but perhaps shouldn't be

5.       Is how the spec is written, but perhaps shouldn't be.

I'll be interested to hear others' opinions.








Received on Sunday, 3 April 2011 21:04:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:24 UTC