RE: oddities with dasharray, markers and use

To comment quickly on #2, for IE9 all you need to do is add stroke-dasharray="none" to the path in the marker. The idea of going with the design we did is that it is more flexible and fully supports both your scenario and the scenario of using a single marker on many different types of lines/paths and have it adopt the color, etc. of the path it's on.

Unfortunately this does not work for Chrome, so it seems like their behavior might be a bug and not a design decision to follow the <use> model. I don't have the ASV installed at the moment so I can't check that.

- Tony

From: David Dailey [mailto:ddailey@zoominternet.net]
Sent: Thursday, April 07, 2011 1:38 PM
To: Tony Schreiner; www-svg@w3.org
Cc: yan.li@sru.edu
Subject: RE: oddities with dasharray, markers and use

Thanks for your response Tony.

On #2 - I looked at some of the discussion here, but will confess to have not looked in great detail. It seems though that if arrow-heads are to inherit dash array, then the author must have some way to override this. The behavior is not what most folks would want. Is there another way? Maybe I need to read deeper in the links you provided.

On #3 - would there be any way to have <use onclick="f(evt.target)"> not point back to the original object? It might be nice to have uses and their predecessors behave more like cloneNode("true"), perhaps with an attribute that allows the author to specify whether the use is instantiated in DOM or merely in a shadow tree. For <replicate> [1], which is sort of like <use>, that is certainly the intention since often times the author will want only the visual aftermath of the rendering, while in other use cases (like gaming and 3D applications) each cloned object should have its own DOM instance. To make <use> more forward compatible, this would make sense.

On #4 - you're right. I don't understand my question either, now that I re-examine it.  My thinking was backward.

On #5 - if we had the ability to position markers fractionally as through .getTotalLength(), but with markup, then browsers that are not yet supporting <glyph> could still at least handle the use case of custom cartographic boundary decorations of a sort that are richer than the Morse code-like decorations afforded by dash-array.

Cheers
David
[1] http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Tony Schreiner
Sent: Wednesday, April 06, 2011 7:51 PM
To: David Dailey; www-svg@w3.org
Cc: yan.li@sru.edu
Subject: RE: oddities with dasharray, markers and use

Hi David, a few comments below:

#1 unfortunately looks like a bug in IE9 and I've forwarded for investigation. This is specific to marker and has a simple (but odd) workaround that should work for most scenarios: create a dummy marker and attach it  to an unused marker attribute on the original path, e.g.:
    <marker id="Blank">
      <rect />
    </marker>
    <path id="P" d="M 100 50 C 100 50 150 250 200 100 250 -50 300 250 350 170 400 90 450 50 600 160" fill="none" marker-start="url(#Blank)" />
This will make the real marker-mid and marker-end from the <use> show up properly.

#2 - There have been discussions about this from time to time. See:
- http://lists.w3.org/Archives/Public/www-svg/2010Feb/0023.html
- http://lists.w3.org/Archives/Public/www-svg/2010Jul/0066.html
- http://www.w3.org/2010/07/20-svg-minutes.html

After consideration and discussion with the working group IE9 slightly deviates from the spec on the grounds that it's the more correct, future-looking behavior. The <use> style of inheritance enables the key scenario of being able to apply a single marker (e.g. arrowhead) to lines with differing styles, and have it match the line. It is a minor interoperability issue, but can be solved by explicitly setting the properties on the primitives in the marker. I can't speak for Chrome or the ASV.

#4 - I don't understand the question. The two <use> elements with transforms are referencing the T1 element, which does not have a stroke-dasharray.

- Tony

From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of David Dailey
Sent: Sunday, April 03, 2011 2:04 PM
To: www-svg@w3.org
Cc: yan.li@sru.edu
Subject: oddities with dasharray, markers and use

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.

Cheers
David