need to define the exact grammar accepted by "syntax"

[heycam]

We need to define the grammar for the string used for describing the syntax of CSS properties. I'm not sure that using CSS value metasyntax is appropriate for this, or at the very least would be a little confusing. :-)

A question that would answer, for example, is whether " *" would be accepted, or what exact white space characters are accepted around the bar in "<length> | <number>".

[shans]

Do you think this should block FPWD? I definitely think we need to have it
at some point.

The CSS value metasyntax is compelling because if we get 100% coverage then
you can express any value that CSS can. However, it is an .. odd .. syntax.

On Sun, 31 Jan 2016 at 11:15 Cameron McCormack notifications@github.com
wrote:

We need to define the grammar for the string used for describing the
syntax of CSS properties. I'm not sure that using CSS value metasyntax is
appropriate for this, or at the very least would be a little confusing. :-)

A question that would answer, for example, is whether " *" would be
accepted, or what exact white space characters are accepted around the bar
in " | ".

—
Reply to this email directly or view it on GitHub
#112.

[heycam]

Do you think this should block FPWD? I definitely think we need to have it at some point.

No that can be done later.

The CSS value metasyntax is compelling because if we get 100% coverage then you can express any value that CSS can. However, it is an .. odd .. syntax.

I'm talking one level up. So how do we describe the value accepted by the syntax member on a PropertyDescriptor? If we did use CSS metasyntax it would look something like this:

<syntax> = '*' | <syntax-disjunction-term> ['|' <syntax-disjunction-term>]*
<syntax-disjunction-term> = '<' [<type> | <ident>] '>' '+'?
<type> = length | number | percentage | length-percentage | color | image | url | integer | angle | time | resolution | transform-function | custom-ident

But you might need to add additional restrictions on white space not being allowed inside the angle brackets for example.

[shans]

Ah got it, thanks. Yes, that would be confusing :)

On Sun, 31 Jan 2016 at 11:42 Cameron McCormack notifications@github.com
wrote:

Do you think this should block FPWD? I definitely think we need to have it
at some point.

No that can be done later.

The CSS value metasyntax is compelling because if we get 100% coverage
then you can express any value that CSS can. However, it is an .. odd ..
syntax.

I'm talking one level up. So how do we describe the value accepted by the
syntax member on a PropertyDescriptor? If we did use CSS metasyntax it
would look something like this:

= '' | ['|' ]
= '<' [ | ] '>' '+'?
= length | number | percentage | length-percentage | color | image | url | integer | angle | time | resolution | transform-function | custom-ident

But you might need to add additional restrictions on white space not being
allowed inside the angle brackets for example.

—
Reply to this email directly or view it on GitHub
#112 (comment)
.

[heycam]

Another question is whether the <ident> allows escapes. For example:

document.registerProperty({ name: "--a", syntax: "<length> | ab\\63" });

[dbaron]

Another question is whether whitespace is allowed before the "+". (The implementation that @heycam and @jyc have does allow this.)

[heycam]

Relatedly, we should define how to parse the name member of the PropertyDescriptor. For example to register a property whose name includes a newline should you use { name: "--a\n" } (i.e. an actual newline character) or { name: "--a\\n" } (a CSS escape).

[tabatkins]

Relatedly, we should define how to parse the name member of the PropertyDescriptor.

That's fixed now - it gets parsed as a <custom-property-name>. Parsing trims leading/trailing whitespace (per Syntax), so that would be registering the --a property. If you want a newline in the name, you have to CSS-escape it.

Another question is whether whitespace is allowed before the "+".

Like foo +? I think that shouldn't be allowed; it's hard to read. The multiplier should immediately follow the term it's modifying.

But this should all be defined by a proper parser, which I'm happy to write soonish.

[tabatkins]

Another question is whether the <ident> allows escapes.

Currently the answer is no - I've clarified the "literal ident" part to be specifically a name-start char followed by 0+ name chars. Would prefer to avoid having to do CSS parsing on the syntax string. ^_^

[andruud]

@tabatkins Should we add something like what @heycam proposed in #112 (comment)? Or define the allowed values some other way?

[foolip]

Ping @tabatkins. This came up in Intent to ship: CSS Properties and Values API Level 1 on blink-dev.

[tabatkins]

I'll get to work on defining this parser ASAP, since it's :checks notes: 2 years overdue. ^_^