Re: marker-pattern syntax

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.

> 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 Tuesday, 27 November 2012 23:24:06 UTC