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 selector may be an inappropriate data type #1137

Open
cdoublev opened this issue Dec 5, 2022 · 3 comments
Open

CSS selector may be an inappropriate data type #1137

cdoublev opened this issue Dec 5, 2022 · 3 comments

Comments

@cdoublev
Copy link
Contributor

cdoublev commented Dec 5, 2022

Since v11, Reffy extracts CSS selector definitions in selector at the root level. I was not sure about where and how to report the following problems regarding this data type. Please consider this issue as a feed back to open discussions on future versions of Reffy, not as an actual bug report.

Selectors defines selector as a term that can refer to a simple selector, compound selector, complex selector, or selector list, and defines their basic syntax. All selectors extracted by Reffy actually are pseudo-classes and pseudo-elements, except & (which can replace any selector) and >, +, ~, ||, which match <combinator>, and do not match the above definition of a selector, therefore I think these combinators should not be defined with data-dfn-type="selector" in Selectors.

I think these pseudo-classes and pseudo-elements should probably be defined as value in the specs, without the leading : or ::, eventually namespaced to <pseudo-class-selector> or <pseudo-element-selector>.

Semantically, pseudo-elements are not considered part of a compound selector (see this section in Selectors). For example, div::after can be "interpreted" as div :: after, ie. it selects the pseudo-element named after, combined with div. after is nested in the pseudo tree of div. Similarly, div > span selects span directly nested in the element tree of div.

There are discussions about leaving :: as legacy and to define a new combinator to traverse a pseudo tree. <pseudo-element-selector> matching :: followed by a pseudo-element name would also become legacy.

@tidoust
Copy link
Member

tidoust commented Dec 5, 2022

Thanks for the feedback. Always good to try to "make sense" of the data that gets extracted ;)

All selectors extracted by Reffy actually are pseudo-classes and pseudo-elements, except & (which can replace any selector) and >, +, ~, ||, which match <combinator>, and do not match the above definition of a selector, therefore I think these combinators should not be defined with data-dfn-type="selector" in Selectors.

Right, combinators are components of a selector, not selectors per se. E > F is a selector, while > is "just" a combinator. I suppose that data-dfn-type="selector" is used as a shortcut for lack of a better type. That does not strike me as problematic but that probably depends on the usage you intend for the data.

I think these pseudo-classes and pseudo-elements should probably be defined as value in the specs, without the leading : or ::, eventually namespaced to <pseudo-class-selector> or <pseudo-element-selector>.

That may be something worth bringing to the CSS working group. I understand it as suggesting that the selector type could be dropped because selectors can be described through a set of grammar types. I would personally also view the selector category as targeting humans reading and writing the specs. That is, it still seems useful to me to categorize selectors as selectors instead of having them defined as values tied to some obscure grammar construct, so that tools reusing the data such as MDN can easily highlight selectors. I certainly don't speak on behalf of CSS spec authors though!

@cdoublev
Copy link
Contributor Author

cdoublev commented Dec 6, 2022

Right, combinators are components of a selector, not selectors per se. [...] That does not strike me as problematic but that probably depends on the usage you intend for the data.

It is problematic when parsing against a CSS syntax derived from this data, indeed. Pseudo-class and pseudo-element selectors are defined with this syntax (simplified, for brevity): ":"":"?<any-value>. Therefore the parser must include a postprocessing step to check that <any-value> corresponds to a defined selector.

it still seems useful to me to categorize selectors as selectors instead of having them defined as values tied to some obscure grammar construct, so that tools reusing the data such as MDN can easily highlight selectors

I forgot to mention that, yes. Similarly, I guess media-query would be usefull to this audience.

I also have not touched on qualified rules (only at-rules are extracted), which have no corresponding type in Bikeshed. Selectors are closely (and almost only) related to style rules (which are qualified rules).

MDN could gather selectors by collecting values namespaced under the style rule entity, added to top-level rules (vs. atrules). Also note that qualified rules have no name. It could gather media query related values the same way, by collecting values namespaced under @media.

Anyway, these are just thoughts for now. I will follow discussions on pseudo-element combinators and I will create a dedicated issue on w3c/csswg-drafts at the appropriate time.

@w3c w3c deleted a comment from dockter34 Dec 7, 2022
@cdoublev
Copy link
Contributor Author

Here are some interesting related facts.

:blank is a pseudo-class defined in Selectors 4 and CSS Paged Media 3. In the latter, its semantic is different. It is namespaced under @page and is defined as a value, not as a selector.

The :blank pseudo-class matches content-empty pages that appear as a result of forced page breaks.

matches links to:

A page selector is said to match a given page if and only if all of its components match the page.

Selectors seems to define element selectors whereas CSS Paged Media defines page selectors.

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

No branches or pull requests

2 participants