Re: marker-pattern syntax

On Nov 27, 2012, at 3:23 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Nov 27, 2012 at 3:01 PM, Cameron McCormack <cam@mcc.id.au> wrote:
>> Tab Atkins Jr.:
>>>> The required "segment" or "path" keyword at the start of
>>>> 'marker-pattern' would disambiguate.  (Without it, a single "url()" is
>>>> a valid 'marker-pattern' value, and thus is ambiguous in the
>>>> shorthand.)
>> 
>> Oh, that's a nice feature of having the keyword in there.  Can/should we
>> make it optional in marker-pattern?
> 
> We *could* (defaulting to which?), but then we'd just need a prose
> restriction for 'marker' that it's not optional there.
> 
> (Maybe we could default it to "segment", actually, so that the easy
> case of putting a marker in the middle of each segment is just
> "marker-pattern: 50% url();".)
> 
>> Dirk Schulze:
>>> If we would decide to make marker a shorthand. Not sure if it is worth it.
>> 
>> I think we should, if only because it currently is a shorthand (for
>> marker-{start,mid,end}) and I find it strange if it isn't a shorthand for
>> all of these marker-* properties.
> 
> Agreed.  I think you need a good reason to not have things be part of
> the obvious shorthand (like the shorthand becoming far too
> complicated, like 'font' or 'background').
> 
> 
>>>> We could potentially do some fanciness to simplify the common case
>>>> that marker-segment is trying to address, too, and make it so that an
>>>> omitted offset defaults to "50%" in "segment" mode, rather than the
>>>> "0" of "path" mode.  Dunno if that's worthwhile, but it does mean that
>>>> we're simply replacing "marker-segment: url()" with "marker-pattern:
>>>> segment url()", rather than "marker-pattern: segment 50% url()".  (In
>>>> addition to being more verbose, it's not immediately clear what the
>>>> difference is between that last one and "marker-pattern: segment url()
>>>> 50%;", which actually draws *three* markers, at the beginning, middle,
>>>> and end of each segment.  Shortening the default case might make this
>>>> easier to get right.)  However, defaults changing based on other parts
>>>> of the declaration can also be confusing on their own, so I dunno.
>> 
>> 
>> I'm also unsure about this.  But I'm in favour of making the
>> marker-segment:url() case simple to write.
>> 
>> I think I am still not quite convinced about having the offset as the length
>> value before the first url().  Since all the values after that optional
>> length are url()s and lengths, in any order, I feel like the initial length
>> looks like it is part of that repeating list.  Can we distinguish it
>> somehow?
> 
> I understand the concern.  Having the distinguishing characteristic
> being "comes first" is all I could come up with that I liked.
> 
>>  marker-pattern: 20px path url() 40px, ...
>>  marker-pattern: path(20px, url() 40px), ...
>>  marker-pattern: path 20px repeat(url() 40px), ...
>> 
>> (I don't really like any of those.)
> 
> I don't like the first.  I'm not opposed to the second; it's just a
> rearrangement of my existing proposed syntax, with an extra comma
> thrown in to separate the offset more.
> 
> I actually rather like the third, though, particularly if the syntax becomes:
> 
> [ path | segment ]
> <distance>?
> [ <marker> <distance> [ <marker>? <distance> ]* ]?
> [ repeat( <marker> <distance> [ <marker>? <distance> ]* ) ]?
> [ <distance> <marker>? ]* <distance>?
> 
> This way, you can add an arbitrarily complex prelude and postlude to
> the marker sequence.  The repeat() segment is allowed to use up
> whatever amount of distance isn't eaten by the distances before and
> after.

No, this syntax seems by far to complex to implement. (Note that implementing repeating patterns is very calculation insensitive anyway.) 

10px url() 20px 40% repeat(url() 20px 20px 10% url()) 20px

What does this mean?

Please keep it simple

<distance> with a <url> defines a pattern. Another proposal would go into the same directions as Tab's proposal:

[   [<url> <distance>*]+ [no-repeat | repeat]?   ]#

Each distance after a url describes the offset for the current marker:

	url(#m1) 20px;

would be:

	--#--#

and

	url(#m1) 20px no-repeat;

would be:

	--#---------

with no-repeat It would not repeat. A url without a distance has an offset of 0:

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

would be

	--#/O--#---#--#/O--#---#….

#/O means both markers are drawn at the same position.

The advantage is that you always know which offset belongs to which url. It may not be so clear from the beginning with Tabs proposal that 20px url(#m1) 20px 20px 30px url(#m2) is the same as 20px url(#m1) 20px url(#m1) 20px url(#m1) 30px url(#m2). If no keyword repeat or no-repeat is used, then it is the same as no-repeat.

But maybe we can use the same approach with Tabs original proposal:

[    <distance>? <marker-instance> [ <distance> <marker-instance>? ]*   [repeat | no-repeat]?  ]#

I think allowing both within one pattern sequence is to over engineered.

Btw. In this context it might make sense to differ between segments and patterns in general again. For patterns the default is repeat, for segment the default is no-repeat.

Greetings,
Dirk

> 
>> In terms of whether I'm OK with the overall approach, yes, if we can ensure
>> the marker-segment case can be written easily.
> 
> As I said above, if we make the keyword optional in 'marker-pattern'
> (but not 'marker'), and default it to "segment", all you have to do is
> write "50% url()" instead of "url()".  Nice and easy, with no weird
> defaults tweaking.
> 
> ~TJ

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