Re: Handling of orient="auto" markers

Tab Atkins Jr.:

>>
>> Thanks for the update Tab
>
>> > We've rejected
>> > the suggestion that start/end markers should be applied per subpath,
>> > because it seems likely to be too inconsistent with existing content
>>
>> I appreciate the desire for backwards compatibility. I expected that this 
>was likely going to the most controversial proposal.
>>
>> I still think it is a reasonable suggestion, but I suspect any arguments 
>for it will have to be based on emotion. I'm not sure if any real survey of 
>marker use is possible unless someone like the Chrome or Firefox teams 
>volunteer to put in some metering.  I would be open to suggestions on how to 
>otherwise conduct a survey on marker usage.  Given the number of rendering 
>bugs I have found, and that few people seem to have noticed, my sense is 
>that usage of markers is at a level of rarity that it would have little 
>impact if the semantics changed.
>
>Yeah, I'm not sure what would be convincing.  :/

One could add a new property/attribute to leave it to the author.
The default value should be the current behaviour, with other
values one could provide a fine adjustment.

By the way, related missing options to adjust the behaviour applies
for example for stroke-linecap and stroke-dasharray as well.

Such a collection of properties/attributes is an important help for
authors. Currently they have to decompose everything into
single paths to get the control - what can result in a lot of
additional work - and sometimes in undesired artefacts,
because a group of paths does not always result in the
same presentation as a single path with a lot of subpaths.

 
Olaf

Received on Tuesday, 4 June 2013 09:35:49 UTC