Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-properties-values-api] Define parsing rules for the syntax string. #860

Merged
merged 2 commits into from Feb 16, 2019

Conversation

andruud
Copy link
Member

@andruud andruud commented Feb 15, 2019

This defines how to parse the syntax strings using some algorithms and
concepts from css-syntax, while leaning as little as possible on its
concept of tokens.

  • Whitespace behavior is now defined.
  • Escaping is now allowed for ident syntax strings.

Resolves #112.

andruud and others added 2 commits February 15, 2019 15:54
This defines how to parse the syntax strings using some algorithms and
concepts from css-syntax, while leaning as little as possible on its
concept of tokens.

* Whitespace behavior is now defined.
* Escaping is now allowed for ident syntax strings.

Resolves w3c#112.
changes:

* refer directly to algorithms dfns
* use and link to some Infra and Syntax concepts
* strip whitespace from the syntax string
* simplify algorithms a little
* fix a reconsume bug in "consume a syntax component"
@tabatkins tabatkins merged commit 1281246 into w3c:master Feb 16, 2019
@tabatkins
Copy link
Member

I added some fixups. Still needs some more work, as various things aren't linking, but it's usable right now.

One point tho: CSS allows +# as a grammar multiplier; that is, multipliers can be stacked. Is there a good reason not to allow that?

Copy link
Member Author

@andruud andruud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, thanks @tabatkins! :-)

@andruud
Copy link
Member Author

andruud commented Feb 18, 2019

Re. stackable multipliers, I don't think anything prevents us from doing that. I was only maintaining limitations that were already in the spec. (According to my interpretation, that is). The previous spec text said something like "+/# multiplies any primitive term".

I don't think we should scope-creep this spec any further right now, in any case. There are still too many gaps on the existing functionality, e.g. CSS(Typed)OM behavior, and substitution behavior. Apparently the cascading behavior / syntax-checked-at-computed-value-time concepts were also not clear to TAG.

@tabatkins
Copy link
Member

Sounds reasonable, I'll bring it up as an improvement later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants