W3C home > Mailing lists > Public > www-svg@w3.org > November 2012

Re: 'marker-segment' and distance + 'marker-pattern' + 'marker'

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 26 Nov 2012 14:19:45 -0800
Message-ID: <CAAWBYDCrjYxAXDCD4FnkQ_oM13p=kmz_e+bZvZL4rUxGOvtZ0g@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: SVG public list <www-svg@w3.org>
On Mon, Nov 26, 2012 at 1:56 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Nov 26, 2012, at 11:10 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Thu, Nov 22, 2012 at 7:37 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>>> Hi SVG WG,
>>>
>>> I think 'marker-segment' should have the same syntax as 'marker-pattern' and allow a distance. Often you want to position markers on the corners of a path (even the example for marker-segement does it for demonstration ;)).
>>
>> Isn't this what marker-start/end/mid is for?  marker-segment is just a
>> fourth member of that family, for putting things in the center.
>>
>>> <percentage> would be relative to the segment length, <length> is a distance from the start of a segment.
>>>
>>>        marker-segment: none | [ <url> <distance>+ ]+
>>>
>>> Multiple markers on the same position should be possible. This can have some neat affects. Markers are drawn by the order. First all markers of the first sequence, then all markers of the next sequence and so on. It must be clarified what happens with negative values.
>>
>> However, this seems reasonable to me.  If you're putting them on a
>> segment, rather than a vertex, choosing the center is a logical
>> default, but still an arbitrary choice.  Allowing authors the ability
>> to position their markers anywhere along the segment is a good idea.
>>
>> If at all possible, the syntax should be comma-separated, though.
>> Having pairs of things without a delimiter is confusing to read.  We'd
>> just have to make sure that's not troublesome in the shorthand.
>
> I am not only suggesting a positioning of one marker, but a pattern dependent on the marker. Each segment could have a marker that is like this:
>
>         -|---|
>
> This would be repeated from the start of each segment till the end. If you just want to have a marker per segment in the middle, you would do
>
>         marker-segment: url(#marker) 50%;
>
> But if you want to have something like marker-pattern per segment, you do something like this:
>
>         marker-segment: url(#marker) 10px 30px;
>
> And even allow multiple markers:
>
>         marker-segment: url(#marker1) 20px url(#marker2) 30px;

Oh, I missed this part.  So you're wanting something that's basically
marker-pattern, but limited to and repeated over each segment?

If we do that, perhaps we can just specialize marker-pattern with a
keyword that details whether it applies the pattern over the whole
length of the path or each segment.  That could simplify some bits.


>> Alternately, and perhaps more understandably, adopt more explicit
>> delimiters, like:
>>
>> marker: [start <url>] || [mid <url>] || [end <url>] || [ segment [
>> <url> <distance>+ ]# ] || [pattern <'marker-pattern'>] | <url> | none;
>>
>> Possibly allow start/mid/end to be collapsed together, so you can say
>> "marker: start end url(...) mid url(...);".  I don't really want to
>> write out the necessary grammar for that right now.
>
> We need to be consistent with the old marker syntax, which is still used very often. That means, one part is always:
>
>         none | <url>{1,3}
>
> And represent marker-start, mid and end. That is why the syntax proposed above doesn't work.

Note the end of my suggested syntax, which contains " | <url> | none".
 I couldn't tell from the SVG1.1 spec what the syntax of 'marker'
actually is; it's oddly unspecified.  (It just says "see individual
properties", but that doesn't actually help at all).  I assumed it
just took "<url> | none", in the absence of any further details.

If the current syntax of 'marker' is "<url>{1,3} | none", then just
throw a {1,3} on that term at the end of my suggested grammar.

~TJ
Received on Monday, 26 November 2012 22:20:35 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:53 GMT