Re: marker-pattern syntax

On Nov 26, 2012, at 2:31 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Mon, Nov 26, 2012 at 2:04 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> On Nov 26, 2012, at 11:36 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Thu, Nov 22, 2012 at 6:44 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>>>> To get back to it: sometimes you want a marker follow a pseudo irregular pattern. It should be possible to define multiple distances:
>>>> 
>>>>       marker-pattern: url(#marker1) 20px 40px, url(#marker2) 20% 40px;
>>>> 
>>>> The first marker pattern draws a marker after 20px, then after 40px from the first marker position, then after 20px of the second marker position and so on. Same for the second marker pattern. That is why I  would suggest the following change now :)
>>>> 
>>>>       marker-pattern: none | [ <url> <distance>+ ]#
>>> 
>>> I think the additional ability offered by setting multiple lists in
>>> marker-pattern is potentially useful, but I don't like the
>>> simplification you've made to each individual list.  You can no longer
>>> easily swap between two different markers (you have to instead
>>> coordinate two separate distance lists), nor can you easily insert
>>> "gaps" in the marker list (you have to instead lengthen the distance).
>> 
>> Can you give an example? I don't get your point. Where is the problem with "url(..) 20px 30px url() 20%"? Why can't you see the two different lists per <url>?
> 
> As far as I can tell, in your suggested grammar you specify a single
> marker type via url(), then a list of distances that it should iterate
> between.  If you want a second type of marker, you need a separate
> list.  That means that the example in the spec, which alternates
> between 1 and 2-line markers, actually *cannot* be written.  It's
> *almost* this:
> 
> marker-pattern: url(#SingleDash) 80px, url(#DoubleDash) 40px 80px;
> 
> ...except that doesn't work, because the double-dash will now
> alternate as 40px-80px-40px-80px, rather than being 80px apart with an
> "initial offset" of 40px, as intended.
> 
> Even if you *could* provide an initial offset, with something like
> "40px url(#DoubleDash) 80px", it's still a worse grammar.  It's not
> immediately clear, from looking at it, that the intended effect is for
> the two markers to alternate every 40px.  The current grammar in the
> spec makes this easy to see with "40px url(#DoubleDash) 40px
> url(#SingleDash)".  My suggested grammar preserves this easy
> readability.

I would disagree. I think it is totally confusing that it starts with a distance. but even if we go this way: it means you can just add one distance per <url>, after that you need to respecify it. Which is… a lot of code. It also means that you can not specify different markers with different repeatings in different contexts, you are always bound to one pattern, and can't specify independent patterns as well, or need to continue listing the urls until the frequencies of the two different patterns come together. Just see the following two patterns as example:

-------------------#-------------------#-------------------#-------------------#-------------------#-------------------#-------------------#-------------------#-------------------#
--------O--------O--------O--------O--------O--------O--------O--------O--------O--------O--------O--------O--------O--------O--------O--------O--------O--------O--------O--------O

These are two marker patterns that you want to apply on a path. I wrote the whole sequence until both patterns start on the same peak again. With your proposal it would be:

9px url(#m2), 18px url(#m2), 20px url(#m1), 27px url(#m2), 36px url(#m2), 40px url(#m1), 45px url(#m2), 54px url(#m2), 60px url(#m1), 63px url(#m2), 72px url(#m2), 80px url(#m1), 81px url(#m2), 90px url(#m2), 99px url(#m2), 100px url(#m1), 108px url(#m2), 117px url(#m2), 120px url(#m1), 126px url(#m2), 135px url(#m2), 140px url(#m1), 144px url(#m2), 153px url(#m2), 160px url(#m1), 162px url(#m2), 171px url(#m2), 180px url(#m1), 180px url(#m2)

In comparison to:

url(#m1) 20px url(#m2) 9px

(btw. I always mixed up url with the length value, just because it is so uncommon in CSS to write the numbers before the url, even if it would be possible in many situations.)


> 
> 
>>> marker-pattern: [ <distance>? <marker-instance> [ <distance>
>>> <marker-instance>? ]* ]#
>>> 
>>> This lets you still intersperse multiple markers (or gaps) in a single
>>> run, but also lets you specify multiple independent runs.
>> 
>> What do you mean with gap? I don't understand your <distance> at the beginning?
> 
> Instead of providing a url() at a spot to indicate a marker, you can
> provide "none", which just means "no marker here, continue with what
> you were doing".  This is allowed by the current grammar, and seems
> reasonable for readability purposes.  (You could always just combine
> the lengths on either side into a single one, but that might obscure
> some useful symmetries.)

But unnecessary, since you can address it with the other proposal as well, even simpler.

> 
> 
>>> I've included your optimization that you can omit the <single-marker>,
>>> meaning "use the last <single-marker> provided".  This is a change
>>> from what the current spec seems to mean by having multiple lengths,
>>> which I think is just "combine them", but that's an insignificant loss
>>> in the modern age of calc().
>> 
>> Has nothing to do with calc(). I am speaking about partly regular returning patterns. See the example here:
>> 
>> --|-----|-|--|-----|-|--|….
>> 
>> This is just possible with different distances.
> 
> I answered this above.
> 
> 
>>> This plays nicely with the 'marker' shorthand that I suggested in the
>>> other thread, where you prefix each segment of the shorthand with an
>>> ident for the subproperty it's specifying.
>> 
>> It does not, since your example doesn't work with the current syntax.
> 
> I have no idea what you mean.  My exact words is that it would work
> nicely with the 'marker' shorthand *I suggested*, not the current
> spec's shorthand grammar.

> 
> 
>> I also have an addition to my syntax. I would like to define an offset for a returning pattern, like for stroke-dasharray:
>> 
>>        <marker-instance> <distance>+ [/ <distance>]?
>> 
>> where the last distance, separated by a '/', is the offset of this pattern.
> 
> Yeah, an offset seems necessary for your proposal.  I suggested such
> above before I read down this far.  ^_^  However, I think sticking
> closer to the current spec's grammar removes the need for an offset,
> right?

If you want to write a lot, maybe.

Greetings,
Dirk

> 
> ~TJ

Received on Tuesday, 27 November 2012 00:07:38 UTC