Re: [css3-lists] glyphs in single string

On Fri, Nov 25, 2011 at 3:24 AM, Håkon Wium Lie <howcome@opera.com> wrote:
> Also sprach Tab Atkins Jr.:
>  > >>> @counter-style lower-norwegian {
>  > >>>   type: alphabetic;
>  > >>>   glyphs: a b c d e f g h i j k l m n o p q r s t u v w x y z æ ø å;
>  > >>> }
>  > >>
>  > >> Then you can't distinguish an<image>  from a glyph that just happens
>  > >> to look remarkably like url(foo).
>  > >
>  > > If you're using unquoted values, you definitely should be restricting
>  > > them to identifiers only (or, at most, IDENT, NUMBER, and DIMEN).
>  > >
>  > > And, as Peter Moulder says, allow quoted strings for hard-to-escape cases.
>  >
>  > This seems completely reasonable.  I'm totally fine with allowing
>  > IDENT, NUMBER, DIMEN, <string>s, and <image>s.  This has none of the
>  > weaknesses of the other proposals, while being maximally compact.
>  >
>  > Hakon, does this sound good to you too?
>
> What are the hard-to-escape cases? I can only see that 'url()' causes
> problems, no? If we separate out images, I'm not sure we need
> <strings>.

Peter correctly pointed out that it's not actually ambiguous - url()
isn't a valid identifier, so no escaping is necessary there.  However,
I don't think it should be *necessary* to escape spaces - that's an
annoying thing to do, so we should still allow strings.

Peter also points out the interesting ambiguity with using numbers -
if an author writes "glyphs: 01 02 03;", they'll be parsed as integers
without the leading zeros.

However, I guess it isn't really very necessary to allow numbers; the
cases where the all-strings syntax gets annoying are when you're
writing out long alphabetic or similar systems.  Numeric systems are
typically pretty short, as most of them have just 10 digits.

So, new proposal based on this:  allow <string>, IDENT, or <image>.

> As John pointed out, they are really characters so the 'glyphs'
> property should be renamed.

Yes, I'm discussing this in another thread.

> Then there's my concern about 'type' being too generic (Many other
> places in CSS would also like to describe types. Should they be
> allowed to use it too? If not, why should it be allowed here?)

Yes, they should be able to use 'type' too.  These are descriptors -
their meaning is local to the at-rule that defines them.

> We can address all these concerns with a syntax like this:
>
>  @counter-style lower-norwegian-glyphs {
>   alphabetic: a b c d e f g h i j k l m n o p q r s t u v w x y z æ ø å;
>  }

[snip some other examples]

> (We'd need some rules to determine the winner if more than one is set:
>
>  @counter-style foo {
>   alphabetic: a b c d e f g h i j k l m n o p q r s t u v w x y z æ ø å;
>   images: url(a.svg) url(b.svg) url(c.svg);
>   numeric: \3007 \4E00 \4E8C \4E09 \56DB \4E94 \516D \4E03 \516B \4E5D;
>  }
>
> but that's simple enough, we just establish relative strength between
> the various types.)

Like Christoph, I'm not wild about this.  It doesn't quite feel right,
and it introduces the need to do conflict resolution when there
previously was no conflicts.  As well, the 'images' descriptor doesn't
describe the algorithm the images should use.  In general, this seems
to create issues that don't exist with 'type', with the only gain of
saving the characters used to type "type:" and "glyphs:".

~TJ

Received on Friday, 25 November 2011 23:44:11 UTC