- From: Guillaume via GitHub <sysbot+gh@w3.org>
- Date: Sat, 12 Feb 2022 11:09:02 +0000
- To: public-css-archive@w3.org
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [syntax-3][cssom-1][selectors-3][mediaqueries-4][cascade-3][css-counter-styles-3] Improve the procedures used for parsing a CSS input == As a follow up on [the second part of this comment](https://github.com/w3c/csswg-drafts/issues/4927#issuecomment-1012127022), which was about replacing the steps *parse a list of component values* and *match the result against the corresponding grammar*, by a reference to *parse something according to a CSS grammar*, I create this (list of) issue(s) (and suggestions) about the parsing procedures used across Syntax, CSSOM, Selectors, Media Queries, etc. I'm very sorry about the length of this issue. Thank you to anyone who will have the courage to pay attention to it. I published [this document](https://github.com/cdoublev/css/blob/master/doc/parse/entry-points.md) which gives an overview of all the parsing procedures and includes the following issues/suggestions: 1. [CSS Syntax associates](https://drafts.csswg.org/css-syntax/#qualified-rule) "style block" to *parse a list of declarations* but it should be associated to [parse a `<style-block>`](https://drafts.csswg.org/css-syntax/#typedef-style-block). 2. [CSS Cascade defines](https://drafts.csswg.org/css-cascade/#fetch-an-import) *fetch an @import* (removed in Cascade 4-5) with a step that includes [parse a stylesheet](https://drafts.csswg.org/css-syntax/#parse-a-stylesheet) but it would be helpfull to note that only the basic syntax will be validated, or to define that [parse a CSS style sheet](https://drafts.csswg.org/css-syntax/#css-stylesheets) should be used, otherwise the list of rules will not be parsed against the context rules or the corresponding grammar for the rule (only the basic syntax will be validated and the nested rule's contents will be left unparsed as a list of component values). 3. [CSSOM defines](https://drafts.csswg.org/cssom/#dom-cssstylesheet-replace) the procedures for `CSSStyleSheet.replace()` and `CSSStyleSheet.replaceSync()` with *parse a list of rules* but it would be helpfull to note that only the basic syntax will be validated, or to define that [parse a CSS rule](https://drafts.csswg.org/cssom/#parse-a-css-rule) should be used (as in [insert a CSS rule](https://drafts.csswg.org/cssom/#insert-a-css-rule), used with [`CSSStyleSheet.insertRule()`](https://drafts.csswg.org/cssom/#dom-cssstylesheet-insertrule), see dedicated issue: #6995), otherwise the list of rules will not be parsed against the context rules or the corresponding grammar for the rule (only the basic syntax will be validated and the nested rule's contents will be left unparsed as a list of component values). 4. [CSS Syntax defines](https://drafts.csswg.org/css-syntax/#parser-entry-points) *parse a list of component values* as the entry point to parse a *stand-alone selector*, but what is a *stand-alone selector* and where is it used? If it is a style rule's prelude, it would be helpfull to note that only the basic syntax will be validated, or to define that a selector should be parsed with [parse a selector](https://drafts.csswg.org/selectors/#parse-a-selector), otherwise the component values will not be parsed against `<selector-list>` (only the basic syntax will be validated). 5. [CSS Syntax defines](https://drafts.csswg.org/css-syntax/#parser-entry-points) *parse a list of component values* as the entry point to parse `Element.media`, but it would be helpfull to note that only the basic syntax will be validated, or to define that `Element.media` should be parsed with [parse a media query list](https://drafts.csswg.org/cssom/#parse-a-media-query-list), otherwise the component values will not be parsed against the grammar of the corresponding descriptor (only the basic syntax will be validated). 6. [CSS Media Queries defines](https://drafts.csswg.org/mediaqueries/#typedef-media-query-list) the procedure to parse `<media-query-list>` with *parse a comma-separated list of component values* composed with *parse something according to a CSS grammar* using `<media-query>`, but it should use *parse a comma-separated list according to a CSS grammar* using `<media-query>` instead, therefore parsing a whitespace as input (eg. from `Element.media`) to an empty list instead of `not all` ([as defined in *parse a media query or a media query list*](https://drafts.csswg.org/cssom/#parsing-media-queries)), and it should define this production specific rule: an empty list should default to `all` and an invalid `<media-query>` should default to `not all`. 7. [CSS Conditional defines](https://drafts.csswg.org/css-conditional-3/#support-definition) that *a CSS processor is considered to support a declaration (consisting of a property and value) if it accepts that declaration*, but it would be helpfull to refer to *parse something according to a CSS grammar using the grammar of the property*, or to [parse a CSS value](https://drafts.csswg.org/cssom/#parse-a-css-value). 9. [CSSOM defines](https://drafts.csswg.org/cssom/#parse-a-css-declaration-block) *parse a CSS declaration block* with *let parsed declaration be the result of parsing declaration according to the appropriate CSS specifications, dropping parts that are said to be ignored*, but this step could be *parse something according to a CSS grammar* using the property’s grammar instead, or a reference to *parse a CSS value* using the property and its value. 10. *Parse a CSS declaration block* could be named *parse a CSS declaration list*, because a "block" implies the presence of its associated tokens but a CSS declaration list has none (the list is the value/content of the block), then it could be parsed with *parse something according to a CSS grammar* using `<declaration-list>` and to avoid a conflict and the confusion with the current use of `<declaration-list>`, the latter would be renamed to eg. `<rule-block>` (a list of declarations and at-rules), which is not perfect but a small semantic improvement imo. 10. [CSSOM defines](https://drafts.csswg.org/cssom/#parse-a-css-value) *parse a CSS value* for parsing a declaration property value, but it would be more correct to name it *parse a CSS property value* because a CSS value is not defined anywhere: at least, it can also be a CSS descriptor value. 11. [CSSOM defines](https://drafts.csswg.org/cssom/#parse-a-css-value) *parse a CSS value* with *parse a list of component values* composed with *match [the result] against the grammar for the property `property` in the CSS specification* but it could refer to *parse something according to a CSS grammar* using the property’s grammar instead. 12. [CSS Counter Styles - (set) CSSCounterStyleRule.`<descriptor>`](https://drafts.csswg.org/css-counter-styles/#the-csscounterstylerule-interface) should use *parse something according to a CSS grammar* using the descriptor’s grammar instead of *parse a list of component values*, otherwise the component values will not be parsed against the grammar of the corresponding descriptor (only the basic syntax will be validated). 13. [CSS Syntax is missing](https://drafts.csswg.org/css-syntax/#declaration-rule-list) `<style-block>` in the section title *8.1. Defining Block Contents: the `<declaration-list>`, `<rule-list>`, and `<stylesheet>` productions*. 14. [CSS Syntax do not define](https://drafts.csswg.org/css-syntax/#parse-a-css-stylesheet) where/when *parse a CSS stylesheet* should be run (dedicated issue: [#2997](https://github.com/whatwg/html/issues/2997)), but I think it could exist in [create a (non-constructed) stylesheet](https://drafts.csswg.org/cssom/#create-a-css-style-sheet). 15. [CSSOM defines](https://drafts.csswg.org/cssom/#parse-a-group-of-selectors) *parse a group of selectors* to parse the prelude of a style rule, but it should be replaced with [parse a selector](https://drafts.csswg.org/selectors/#parse-a-selector) (dedicated issue: #6927). Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7040 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 12 February 2022 11:09:04 UTC