- From: Guillaume via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Aug 2021 14:06:42 +0000
- To: public-css-archive@w3.org
If you allow me to report some issues I had while implementing a library for automatic parsing of CSS values... **Context:** this library aims at replacing `jsdom / cssstyle` (an implementation of` CSSStyleDeclaration`), and I only discovered `csstree` yesterday, after almost all the work for this library was done. I didn't look at `csstree` in depth, but its author might have come accross the same issues. I will only report the issues that are related to *automatic parsing of definitions* (of types and properties, ie. the title of this issue), which is defined in a comment above as *the goal of the CSS value syntax*, defined in the specification of CSS values, because I think the issues related to parsing a CSS value by using a parse function generated from the corresponding property definition, deserve their own issues. I was not sure where to submit the following issues. Some are more directly related to `webref/css` and others to the CSS specifications of the W3C. ## Types written in prose and not reported by `w3c/webref` (ie. `reffy`) I have not yet been able to run all existing tests for many CSS properties and CSS types, but for example `<dimension>` and `<rounding-strategy>`, which are not listed in the document whose [link](https://github.com/w3c/reffy/blob/main/src/specs/missing-css-rules.json) is given in a comment above (anchored on *list of "missing" rules* - which means a list of missing definitions? -). I report this issue with the idea in mind that it can be fixed either by preventing a property/type definition written in prose, which I think is unlikely to happen, or that it can be fixed in `w3c/webref`. ## Consistency in the initial values of shortened properties The "initial value" fields of the shorthand properties have values written in prose that varies accross the different specifications: most often it is `see individual properties`, but also `N/A (see individual properties)`, `not defined for shorthand properties`, etc. The issue can be easily fixed but it's a pebble in the road towards automatic parsing using `@webref/css`. To be honest, this is more about an opportunity for me to ask the following two questions: - are shortened properties the only properties that have no initial value? - does the value `not applicable (initial value comes from physical property)` for the properties `background-position-block` and `background-position-inline` correspond to `auto`? ## Definition of terminal types with token types `w3c/webref` reports the types `<EOF-token>`, `<length>`, and `<percentage>` with definitions written in prose, but that don't allow to expand those types to explicit values because obviously they are tokens or terminal CSS types. The component values are often identical to the tokens that result from tokenization, which makes me think that the terminal CSS types could be defined with the corresponding type of tokens: `<dimension-token>`, `<percentage-token>`, etc... This may be a dumb idea. I'm not sure that if other reason exists for this, but it makes sense to me. ## Order of "xor" combinations I remember that I read a property or type definition before, that defines a "greedy" parsing behavior. I can't remember which one, but perhaps the following issue is not a an issue at all. If so please forgive me. To give an example, the value `left center`, when parsed for a property defined with `<position>`, will match only with the component value` left` if the parse function is not greedy and if the definition of `<position>` contains the combination that allow a single value before the other combinations that allow two or more values. 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. Implementing the former solution looks more difficult to me, but the second solution might have several drawbacks. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2921#issuecomment-901145153 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 August 2021 14:06:44 UTC