Re: marker-pattern syntax

On Nov 27, 2012, at 9:20 PM, Cameron McCormack <> wrote:

> Dirk Schulze:
>> This would not be a good idea, and we just can support one repeat. But why should authors just differ with different markers at the beginning and the end of the path? Why shouldn't they want to have special value in the middle and everything around repeats? This gets ridiculous complicated. Let us concentrate on basic functionality. Something that you would expect from a pattern: it repeats.
> If all we want is repeating then I would say do away with the initial 
> offset.  As I said, if we include an initial (non-repeated) offset, then 
> we should allow one at the end as well.  The use for this is to ensure 
> repeated markers in the middle don't run up against the ends of the 
> path, right?  (It might be you have marker-{start,end} markers there you 
> don't want to run in to.)  In which case it's just as likely you'll need 
> to do this at the other end of the path.

All concepts so far just defined the offset on a sequence base, not on the whole pattern. And even with repeat() you would not address this problem. Then you just define static markers at the beginning and end of the pattern and the pattern runs into these static markers.

> Of course this is all about balancing power and complexity for the 
> author.  I am happy with not having arbitrary non-repeating patterns at 
> the start/end of the path; you can do that with separate tracks (as long 
> as you don't mind that they'll be all painted above or below the 
> repeated ones).


> Cameron McCormack:
>>> I didn't realise that about Tab's proposal (if it is actually the case),
>>> that the url()s are implied between each length.  I assumed it was like
>>> in the current spec text, where consecutive lengths just keep advancing
>>> the current position.
> Dirk Schulze:
>> No, he explained that this would be possible with calc(). We don't need to invent the wheel again. If you want 20% + 10px then do calc(20% + 10px).
> OK thanks for explaining.  I am OK with calc() here instead of 
> consecutive lengths.
>> I think this makes clear what he wanted:
>>>>        marker-pattern: path 10px url(#m1) 20px url(#m2) 50px;
>>>>        -#--#-----O--#-----O--#.
>>>>        marker-pattern: path 10px url(#m1) 20px url(#m2) 50px 10px;
>>>>        -#--#-----O-O--#-----O-O--#.
>>> These last two aren't right.  They should be, respectively:
>>> -#--O-----#--O-----#--O---...
>>> -#--O-----O-#--O-----O-#--O---
>> Here it seems the first distance is the offset of the pattern, the last distance the gap after the pattern sequence. Two distance after each other imply that there is the previous url between them.
> But I don't like the omitted url()s -- I would rather it be explicit by 
> including them.

I think this is reasonable and makes the grammar a lot easier, even if the author needs to copy code.

> My issue about the initial offset (and final offset as above in Tab's 
> example) still stands: to me it looks very much like it's part of the 
> repeating pattern, and in the first of the two examples above I would 
> have to think hard about whether the 50px at the end is an offset or if 
> it is part of the repeating pattern.  I think the repeat() syntax helps 
> make that distinction clear.

I don't like the handling of the offset either. It should be clear which part belongs to the pattern and which part belongs to the offset. I also think that defining one offset is sufficient enough, if it moves the whole pattern and does not just define another "gap" then you could easily produce something that is ---#--#--- by defining ------#--# and move the whole pattern. That is why I suggested the '/' operator. However, this seems not to convince everyone. But please don't allow a mixture of static markers and repeating markers in one sequence. That makes it even harder to understand marker-pattern.


Received on Wednesday, 28 November 2012 05:40:08 UTC