css-modules / css-selector-tokenizer Goto Github PK

Parses and stringifies CSS selectors.

License: MIT License

JavaScript 100.00%

css-selector-tokenizer's Introduction

CSS Modules

A CSS Module is a CSS file where all class names and animation names are scoped locally by default. All URLs (url(...)) and @imports are in module request format (./xxx and ../xxx means relative, xxx and xxx/yyy means in modules folder, i.e. in node_modules).

CSS Modules compile to a low-level interchange format called ICSS (or Interoperable CSS) but are written like normal CSS files:

/* style.css */
.className {
  color: green;
}

When importing a CSS Module from a JavaScript Module, it exports an object with all mappings from local names to global names.

import styles from './style.css';

element.innerHTML = '<div class="' + styles.className + '">';

Why CSS Modules?

Local Scope Prevents Clashes: CSS Modules use local scope to avoid style conflicts across different project parts, allowing component-scoped styling.
Clear Style Dependencies: Importing styles into their respective components clarifies which styles impact which areas, enhancing code readability and maintenance.
Solves Global Scope Problems: CSS Modules prevent the common issue of styles in one file affecting the entire project by localizing styles to specific components.
Boosts Reusability and Modularity: CSS Modules allow the same class names in different modules, promoting modular, reusable styling.

css-selector-tokenizer's People

Contributors

Stargazers

Watchers

Forkers

rtsao joshwnj justintulloss pieter jessidhia cauldrath alexander-akait tallaxes t-nakatsu-mf mertdeg2 pascalduez vagnersilva warmans barak007 eddyw dineshks1 supercat911

css-selector-tokenizer's Issues

"of" clause of :nth-(last-)child is not fully parsed

See http://drafts.csswg.org/selectors-4/#the-nth-child-pseudo
Currently, in e.g. :nth-child(n+3 of li.important), the li.important portion is just returned as part of a content string and doesn't get parsed into a selector subtree.

Bundle size increases by more then 10x

Hi,
Just to note that latest patch release increased the bundle size by more then 10x.
The reason is that the new version of regexpu-core is now depended on regenerate-unicode-properties (380k)

Bundle Size

unescapeString doesn't properly unescape unicode characters

The following are valid unicode escaped strings:

'\a'
'\00000A'

Both of these aren't matched by unescapeString(), which wants to have at least 2 characters and a maximum of 5. In fact stringifyValues() can stringily to '\A', which then can't be parsed again by parseValues().

Symbolset font content incorrectly escaped

I use the symbolset ss-pika in several projects and when trying to use webpack with the css-loader the resulting CSS string breaks and I end up with two scrambled characters (��) instead of my search icon (🔎).

This happens when you have UTF-16 characters like 🔎 (escapes properly to \1F50E) which becomes a surrogate pair when trying to escape it in Javascript.

I've been attempting to fix this using the cssesc module:

var cssesc = require("cssesc");

function escape(str, stringType) {
    return cssesc(str, {
        quotes: stringType === "'" ? "single" : "double"
    });
}

The tests break though, cause assert.deepAssert creates a surrogate pair when comparing the parseValues result of the file test-cases-values.js.

However, if I rollback css-loader to 0.14.5 (webpack-contrib/css-loader@51e11f3) then this is no longer an issue as the CSS isn't escaped.

Not escaping the content might be a more sane option?

Missing support for selectors with CSS escapes

Let's say we have a selector used to select an element in HTML with the class name "10w"

.\31 0w

This is valid selector according to https://jigsaw.w3.org/css-validator/#validate_by_input (enter .\31 0w {})

But when we parse it we get the following result

  {
    "type": "selectors",
    "nodes": [
        {
            "type": "selector",
            "nodes": [
                {
                    "type": "element",
                    "name": "31"
                },
                {
                    "type": "spacing",
                    "value": " "
                },
                {
                    "type": "invalid",
                    "value": "0"
                },
                {
                    "type": "element",
                    "name": "w"
                }
            ]
        }
    ]
}

While expected result is

  {
    "type": "selectors",
    "nodes": [
        {
            "type": "selector",
            "nodes": [
                {
                    "type": "class",
                    "name": "10w"
                }
            ]
        }
    ]
}

Emoji support

The selector .🍰 is valid CSS, but this parses it to .\ï¿½\ï¿½

Column combinator (||) doesn't parse

The column combinator (A || B) currently results in a parse error (i.e. it produces "type":"invalid" nodes).

:matches() not parsed correctly

See :matches().

:not(.b) parses to:

{
  "type":"selectors",
  "nodes":[
    {
      "type":"selector",
      "nodes":[
        {
          "type":"nested-pseudo-class",
          "name":"not",
          "nodes":[
            {
              "type":"selector",
              "nodes":[
                {
                  "type":"class",
                  "name":"b"
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

whereas :matches(.b) currently parses to:

{
  "type":"selectors",
  "nodes":[
    {
      "type":"selector",
      "nodes":[
        {
          "type":"pseudo-class",
          "name":"matches",
          "content":".b"
        }
      ]
    }
  ]
}

Attribute selectors not fully parsed

Currently, the parse tree doesn't include full details for attribute selectors. For example, [att*=val] is parsed into:

{"type":"selectors","nodes":[
  {
    "type":"selector",
    "nodes":[
      {
        "type":"attribute",
        "content":"att*=val"
      }
    ]
  }
]}

It would be better if the "content" was further parsed, so we could get something like:

{"type":"selectors","nodes":[
  {
    "type":"selector",
    "nodes":[
      {
        "type":"attribute",
        "name":"att",
        "operator":"*=",
        "content":"val"
      }
    ]
  }
]}

Explicit descendant combinator not parsed correctly

For example, A >> B is currently parsed as two {"type":"operator","operator":">", ...}s in a row instead of a single >> operator.