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-transforms-2] Potentially invalid syntax for perspective() #7582

Closed
pyoor opened this issue Aug 9, 2022 · 4 comments
Closed

[css-transforms-2] Potentially invalid syntax for perspective() #7582

pyoor opened this issue Aug 9, 2022 · 4 comments

Comments

@pyoor
Copy link

pyoor commented Aug 9, 2022

The CSS Transforms 2 spec currently defines the perspective() function as:
perspective( <length [0,∞]> | none )

In the syntax above, the functional notation accepts one of two arguments (using the single bar operator). Now, I can't find anything specifically in css-values-5 that forbids this, but I believe that these arguments should be wrapped in a group as in:
perspective( [ <length [0,∞]> | none ] )

Could some please provide clarification on if this actually is an issue?

: <span class='prod'><dfn>perspective()</dfn> = perspective( <<length [0,∞]>> | <dfn id="valdef-perspective-func-none" dfn-type="value" for="perspective()">none</dfn> )</span>

@tabatkins
Copy link
Member

Yup, that's an error.

@cdoublev
Copy link
Collaborator

Is it a syntax style error, or more? Where is this style defined?

dbaron added a commit that referenced this issue Aug 10, 2022
dbaron added a commit to w3c/fxtf-drafts that referenced this issue Aug 10, 2022
@tabatkins
Copy link
Member

The Syntax extension of the CSS grammar defines how at-rules and functions (and other things) are written in the grammar. It doesn't have any special rules for functions (or anything else) to automatically create groups in the grammar.

Perhaps it should, tho? Hm.

@cdoublev
Copy link
Collaborator

cdoublev commented Aug 30, 2022

It doesn't have any special rules for functions (or anything else) to automatically create groups in the grammar.

What are the cases (other than function arguments) where a group should be created automatically? Do these rules also explain why a group is created for the types specific to font-variant-alternates in the value definition of font-variant?

I guess the reason for creating a group that is not strictly required, is to make a grammar parser produce a nested list with the corresponding value(s). From this perspective, it would have been nice to create groups for the types specific to font-variant-ligatures, font-variant-numeric, and font-variant-east-asian. It would make shorthand expansion easier, imo.

I'm sorry for this noise on a closed issue. Please tell me if I should create a new issue.

Related: #2921

  normal 
| none 
| [
       # font-variant-ligatures
       <common-lig-values> || <discretionary-lig-values> || <historical-lig-values> || <contextual-alt-values> 
       # font-variant-caps
    || [small-caps | all-small-caps | petite-caps | all-petite-caps | unicase | titling-caps] 
       # font-variant-alternates
    || [
            stylistic(<feature-value-name>) 
         || historical-forms 
         || styleset(<feature-value-name>#) 
         || character-variant (<feature-value-name>#) 
         || swash(<feature-value-name>) 
         || ornaments(<feature-value-name>) 
         || annotation(<feature-value-name>)
       ] 
       # font-variant-numeric
    || <numeric-figure-values> || <numeric-spacing-values> || <numeric-fraction-values> || ordinal || slashed-zero 
       # font-variant-east-asian
    || <east-asian-variant-values> || <east-asian-width-values> || ruby 
       # font-variant-position
    || [sub | super] 
       # font-variant-emoji
    || [text | emoji | unicode] 
 ]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment