Re: marker improvements

Hi Cameron,

Thanks for the quick reply and for having done most changes. See some 
more comments inline.

Le 6/1/2012 10:43 AM, Cameron McCormack a écrit :
>
>> * What is the incoming and outgoing direction for the center of a path
>> segment? How can they be different?
>
> If it's a Bézier with a cusp.
Ah, yes. I hadn't thought about it. Maybe worth mentioning it in the spec.

>
>> * For ISSUE-4, we could also say that the position is computed modulo
>> the path length.
>
> I don't think we should do this, since other "distance along a path" 
> things don't do this (like x position of a glyph along a text path).
I agree we should have a consistent handling of path offset.

>
>> * about href: I thought the resolution was to keep both xlink:href and
>> href and say that href has precedence (see
>> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#Drop_xlink_prefix_for_href). 
>>
>
> I thought that was just for existing xlink:href attributes.
Oh, I had not realized that this was a new thing. I agree.

>
>> * "Properties inherit into the ‘marker’ element from its ancestors;
>> properties do not inherit from the element referencing the ‘marker’
>> element.": I think it should be the opposite. In terms of
>> implementation, I think it is easier. In terms of authoring, if you
>> don't want inheritance to apply, specify non-inherit values on the 
>> element.
>
> I thought this is something that we'd discussed before and come to the 
> conclusion that we don't want to do this.  To handle the situation 
> where you want marker style to match the path, the new paint keywords 
> will let you do this.
Now that you say so, I vaguely remember that we'd discussed this before. 
Sorry for the repetition. In general, I'm not a big fan of having to 
inherit from a different place in the tree that the place of use (as it 
requires to store or compute multiple inheritance contexts per element). 
For gradient for instance this is less of a problem as meaningful 
properties (stop-*) are not inherited by default. But this is not true 
for patterns unfortunately. Could we make the marker-* not inherit by 
default?

BTW, I just noticed that the 'inherit' keyword has been removed from all 
property descriptions. I assume that it says somewhere that all 
properties can take the value inherit even if not written in the 
description, right? Is it to align with the CSS way of defining 
properties? I think it's less readable.

>
>> * ISSUE-7: why do you want to special case the positioned marker?
>
> Because there is a child element to dispatch the event to.  If we 
> wanted to allow events to be dispatched to vertex/segment/repeating 
> markers, then we'd need to add something like the SVGElementInstance 
> tree that <use> has but which we've decided to get rid of.
>
> Also we decided to add some DOM methods to allow authors to detect 
> interaction on vertex/segment/repeating markers when the event is 
> dispatched to the path.
Fine.

>
>> * Figure 9: I don't see the circle and cross markers in the image. Is
>> this normal?
>
> The document does:
>
> <path d="M x,y" marker-start="..."/>
>
> so I guess that's a bug, since a marker should be rendered on such 
> paths.  I'll change it though to have an invisible, non-zero length 
> stroke to avoid this.
I'm not following you here but I'll wait for the change.

>
>> * What does " <funciri> values made absolute" ? absolute as "base URL +
>> path in the document" ?
>
> Yes.  (I just used the wording Tab suggested.)
>
>> Shouldn't we that IRI are transformed into IRI
>> relative to the root element?
>
> In CSS <uri> values always compute to an absolute URI, so I think we 
> should do the same for our <iri>s.
Fine.

>
>> "If a value other than none is given, and the sum of the <length>s and
>> <percentage>s is not positive, then it is an invalid value."
>> Why not say that the lengths and percentages shall all be positive? You
>> want to allow going backwards in the positioning of the markers? Do you
>> have an example?
>
> Yes I want to allow negative values.  It'll let you write things like 
> marker-pattern="25% -10px url(#m1) 20px url(#m2) -10px".
Is it "25% -10px" or "calc(25% -10px)" ? Does it make sense to have 2 
consecutive gaps?  I don't think it's allowed in stroke-dasharray for 
instance.

Regarding the last "-10px", the effect is to shift backwards the next 
occurence of the repetition pattern, so there will be some overlap 
between two patterns. I can't imagine how it is used, what is the 
desired effect and why you couldn't shift the last marker(s) forward 
(ie. bring it(them) at the beginning of the pattern) unless you want the 
first pattern to be different. Is it really the use case?

>
>> * Figure 14: The fact that you changed both the paint order and the
>> stroke width is confusing I think. It does not show the effect of the
>> paint order only.
>
> True, but the values chosen there result in the same visible stroke 
> width.
I think you shouln't need that to do that effect. The paint-order should 
probably be used to control the rendering when the opacity of the fill 
and stroke are different, to select which one goes on top. I'm not even 
sure it's useful for fill/stroke. To do the effect you want, you 
probably should change the position of the stroke 
(stroke-position="inside", 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position), no?

Cyril

Received on Friday, 1 June 2012 09:35:02 UTC