[css-values] ambiguity when matching syntax to value

[idoros]

I can't seem to find a place in the spec or a discussion on how ambiguous syntax definition is handled when matched against a value. It might be the case that there is no definite answer and formal syntax is checked to have no edge cases before approval, but I haven't found that criteria either.

for example if a data-type ends with an optional ending that matches the beginning of another data-type:

syntax = <A> || <B>
<A>    = <number>+
<B>    = <number>

For the value "1 2 3", does <A> matches "1 2 3" ? it seems like <B> would never be matched (and it is optional).

What if the syntax was using all-of: <A> && <B>, should the matcher do some kind of negative-lookahead to stop <A> at "1 2"? or maybe fail when <A> takes all the value, swap the order so <B> would match "1" and <A> would match "2 3"?

---

The other ambiguity is with <custom-ident> that the spec states that "When parsing positionally-ambiguous keywords in a property value, a production can only claim the keyword if no other unfulfilled production can claim it."

For example:

syntax  = <C> && <D>
<C>     = <custom-ident>
<D>     = abc

For the value "abc ccc", <C> would match "ccc" and <D> would match "abc", since it claimed it and have priority. I assume that if the syntax was defined with juxtaposition: <C> <D>, then for the same value "abc ccc", <D> wouldn't be able to take the first part of the value and the match would fail.

To emphasis the possible order of (mis)matching:

syntax  = [<E> | <F>] && [<G> | <H>]
<E>     = <custom-ident>
<F>     = <number>
<G>     = abc
<H>     = <number>

For the value "abc 1", what order of matches/claims should the matcher take?

Just thinking how it might work, maybe the matcher uses the following concepts while matching

• register claim ambiguity - add to a stack of match states (used when <custom-ident> is matched to a keyword)
• force claim - rollback to previous match state and force next match option
• next match option - move to next match option if available.

and claim could be treated in several ways:

• defer claim - iterate through syntax options that don't match a (taken?) claim, and only after mismatching all other non claim matches, call "force claim" to rollback the match.
  • <E>=="abc" <custom-ident> - "register claim ambiguity"
  • <G>!="1" - not claimed since there is another option: "match next option" in [<G>|<H>]
  • <H>=="1" <number>
• immediate claim - immediately "force claim" to rollback the match to a different path in which the keyword is not taken before claimed.
  • <E>=="abc" <custom-ident> - "register claim ambiguity"
  • <G>!="1" - call "force claim" rollback and match next option <F>
  • <F>!="abc" - next match option: reorder top level all-of [<G>|<H>] && [<E>|<F>]
  • <G>=="abc" (abc keyword)
  • <E>!="1" - "next match option" in [<E>|<F>]
  • <F>=="1" (number)
• probably other ways are possible

more matching examples:

syntax  = <I> || <K> || <N>
<I>     = <custom-ident>
<K>     = abc
<N>     = <number>

For the value "abc 1" (notice diff between the way claim is handled):

• defer claim:
  • <I> -> "abc"
  • <N> -> "1"
• immediate claim:
  • <K> -> "abc"
  • <N> -> "1"

syntax  = <I> || <M> | <K> || <N>
<I>     = <custom-ident>
<M>     = <number>
<K>     = abc
<N>     = <number>

For the value "abc 1" match first <I>||<M>, and then preferring <K><N> in re-claim process:

• defer claim:
  • <K> -> "abc"
  • <N> -> "1"
• immediate claim:
  • <K> -> "abc"
  • <N> -> "1"

---

So I have some questions:

• Does the order of syntax definition changes the matching process? would a sort within a group (one-of,any-of,all-of) change the meaning of a syntax?
• The order that a matcher would go through the possibilities would change the result. Are there rules for the order of matching (mismatching)?
• Are there any other positionally-ambiguous cases like <custom-ident>? matches that allow registering match state that can be reclaimed in some way?
• Can there be more then 1 <custom-ident> in a syntax?
• Regarding the rule that says that <custom-ident> is only valid when unclaimed. Does it take affect if the potential keyword in the syntax is never checked against? for example when the keyword is at the end of some optional group and the value is matched completely before reaching it.

[tabatkins]

When a grammar is ambiguous, there's no pre-specified resolution strategy, beyond the one you've already found for assigning <custom-ident>s.

Ambiguous grammars fall into three cases:

• disambiguated in prose; this is relatively rare (I can't recall one that does it off the top of my head, but I know there are)
• the grammar is deliberately ambiguous in a harmless way, to specifically highlight a particular case in the more general grammar that we want to discuss specially in the prose below
• it's an error and should be reported ^_^

Does the order of syntax definition changes the matching process? would a sort within a group (one-of,any-of,all-of) change the meaning of a syntax?

Order is not important. (It's only relevant for serialization purposes, where you use the grammar order to serialize things that could be in multiple orders, so we have a predictable result without having to specify orders constantly by hand.)

The order that a matcher would go through the possibilities would change the result. Are there rules for the order of matching (mismatching)?

n/a

Are there any other positionally-ambiguous cases like <custom-ident>? matches that allow registering match state that can be reclaimed in some way?

Don't think so; if there are it's a one-off and should be handled in specific prose.

Can there be more then 1 <custom-ident> in a syntax?

Yeah def. Having more than one positionally-ambiguous <custom-ident> would be a problem, as the general rule doesn't cover that case.

Regarding the rule that says that is only valid when unclaimed. Does it take affect if the potential keyword in the syntax is never checked against? for example when the keyword is at the end of some optional group and the value is matched completely before reaching it.

I'm not entirely sure what you mean here, but I think you're referring to order again? The rule is just that you try your best to satisfy the grammar while ignoring the <custom-ident>, and then if there's a keyword left over that would cause the grammar to fail that the <custom-ident> could claim, it gets it.

[Loirooriol]

disambiguated in prose; this is relatively rare (I can't recall one that does it off the top of my head, but I know there are)

An example is list-style with <'list-style-position'> || <'list-style-image'> || <'list-style-type'>

Using a value of none in the shorthand is potentially ambiguous, as none is a valid value for both list-style-image and list-style-type. To resolve this ambiguity, a value of none in the shorthand must be applied to whichever of the two properties aren’t otherwise set by the shorthand.

[fantasai]

@idoros I think Tab and Oriol have answered your question, is there anything else you need clarification on or anything specific you need clarified in the specs?

[idoros]

No, sorry for keeping it opened and thanks for the answer