parseley

!lint status badge
!test status badge

Parser for CSS selectors.

----

Features

- Convert CSS selector strings into objects that are easy to work with;

- Serialize back if needed;

- Get specificity for free.

Changelog

Available here: CHANGELOG.md.

Install

$3

``shell
> npm i parseley
`

`typescript
import * as parseley from 'parseley';
`

$3

`typescript
import * as parseley from 'https://deno.land/x/parseley@.../parseley.ts';
`

Usage example

`js
import { parse1, serialize, normalize } from 'parseley';
import { inspect } from 'node:util';

const str = 'div#id1 > .class2.class1[attr1]';

const ast = parse1(str);
console.log(inspect(ast, { breakLength: 45, depth: null }));

const serialized = serialize(ast);
console.log(Serialized: '${serialized}');

normalize(ast);
const normalized = serialize(ast);
console.log(Normalized: '${normalized}');
`

Documentation

- API
- Snapshots

Input reference

Terminology used in this project is more or less consistent to the spec, with some exceptions made for clarity. The term "type" is way too overloaded in particular, the term "tag" is used where appropriate instead.

Output AST

Consistency: overall AST shape is always the same. This makes client code simpler, at least for a certain processing tasks.

For example, always use compound selectors, even when there is only one simple selector inside.

Comma-separated selectors might not be needed for every use case. So there are two functions - one can parse commas and always returns the top-level list regardless of the comma presence in a particular selector, and the other can't parse commas and returns a compound selector AST directly.

Complex selectors are represented in the way that makes the left side to be an another condition on the right side element. This was made with the right-to-left processing direction in mind. One consequence of this is that there is no such thing as a "complex selector" node in the AST hierarchy, but there are "combinator" nodes attached to "compound selector" nodes.

Pseudo-classes and functional pseudo-classes are represented as separate types. All supported functional pseudo-classes have their own types with strongly typed content.

All AST nodes have their specificity computed (except the top-level list of comma-separated selectors where it doesn't really make sense).

Selector type hierarchy

- Selector
- ListSelector - comma-separated
- _contains CompoundSelector list_
- CompoundSelector - all simple selectors that apply to the same element
- _contains SimpleSelector (incl. Combinator) list_
- SimpleSelector
- UniversalSelector - *
- TagSelector - div, etc.
- ClassSelector - .className
- IdSelector - #idValue
- AttributePresenceSelector - [attrName]
- AttributeValueSelector - [attrName="value"], etc.
- FunctionalPseudoClassSelector
- IsSelector - :is(...)
- _contains CompoundSelector list_
- WhereSelector - :where(...)
- _contains CompoundSelector list_
- NotSelector - :not(...)
- _contains CompoundSelector list_
- PseudoClassSelector - :hover, etc. - except functional ones
- Combinator - , >, +, ~, ||
- _contains left CompoundSelector_

Motivation and inspiration

| Package | Hits | Misses
| ---------- | --------- | ---------
| parsel | Sensible AST; specificity calculation; cool name | Not friendly to node.js; based on regex
| css-what and css-select | The idea to process complex selectors in right-to-left order | css-select is a solution for a different problem compared to what I needed; css-what` produces only a list of tokens
| scalpel | Introduced me to nearley parsing toolkit (albeit I'm not using it here anymore) | AST it produces is very far from what I can use
| css-selector-parser | Configurable and lightweight | Again, AST is far from my needs