W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2021

Re: [csswg-drafts] [css-values] Automatic parsing of value definitions (#2921)

From: Guillaume via GitHub <sysbot+gh@w3.org>
Date: Thu, 19 Aug 2021 13:44:53 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-901928389-1629380692-sysbot+gh@w3.org>
> `<dimension>` is necessarily a prose definition; there's too many things that could potentially resolve to a `<dimension>` to be reasonably listed in an explicit grammar.

Currently I define `<dimension> = <angle> | <frequency> | <length> | <time> | <resolution>` in order to be able to check *if nodes contains any dimensions* in the procedure to [*sort a calculation’s children nodes*](https://drafts.csswg.org/css-values-4/#sort-a-calculations-children), and to check *If the root of the calculation tree `fn` represents is a numeric value (number, percentage, or dimension)* in the procedure to [*serialize a math function*](https://drafts.csswg.org/css-values-4/#serialize-a-math-function).

> Does the value `not applicable (initial value comes from physical property)` for the properties `background-position-block` and `background-position-inline` correspond to `auto`?
> > Unclear. The logicals probably are the same as shorthands, and don't have an initial value at all; this isn't consistent between css-logical and css-backgrounds currently.

Sorry. I was (confusedly) thinking that `auto` could mean *whatever the initial value of the corresponding physical property is*. Anyway, the initial value of both `background-position-x` and `background-position-y` is `0%`, but I guess that at some point, I may have to resolve the writing mode of a DOM element first, to resolve the initial value, instead of resolving a static initial value defined in the property definition.

> the terminal CSS types could be defined with the corresponding type of tokens: `<dimension-token>`, `<percentage-token>`, etc...
> > No, they can't be - there are often many ways to produce a particular terminal value that are not just the literal tokens. For example, calc(1%) is a `<percentage>`, but is definitely not a `<percentage-token>`. The token productions should almost never be used in ordinary specs; they only deserve mention when you're discussing very low-level details of CSS, such as the definition of "dimension".

Ok. I guess that *the many ways to procedure a particular terminal value* are when consuming a function or a simple block. I didn't really understood that *a math function can be many possible types, such as `<length>`, `<number>`, etc., depending on the calculations it contains*, because this quote is followed by the procedure to dermine the type of a calculation. I only assign a numeric type on calculations. Obviously, `calc(1%)` should not be serialized as a `<percentage>`.

> Either this greedy or non-greedy behavior is defined explicitly somewhere, or the order of the "xor" combinations must be to start from the combination that allows the highest number of component values first, towards the combination that allows the lowest.
> > CSS tokenization is greedy [...] but parsing is definitely non-greedy.

The most up to date definition of `background-position` is `<position>#`, which is expanded to 
`[ [left | ...] | [left | ...] [... | <length-percentage>] ]` (truncated for brevity). Because parsing is non-greedy, `left 10%` will match the first combination, `[left | ...]`, and `<length-percentage>` will be left unparsed. To workaround this, I rewrited the definition by modifying the combinations order to `[ [left | ...] [... | <length-percentage>] | [left | ...] ]`. I can figure out another workaround when parsing `background-position`, but it will be harder or even impossible when parsing `background`, `conic-gradient()`, `radial-gradient()`, or `mask-layer`, which contains a `<position>` between other types.

Thank you tidoust for giving me these links. I will certainly read everything because I'm sure to learn other things that will help me to save time.

-- 
GitHub Notification of comment by cdoublev
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2921#issuecomment-901928389 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 August 2021 13:44:55 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:42 UTC