## 0.8.10 - Hardened Lit CSS parsing for quoted CSS strings that contain braces or escaped backticks. - Allowed selector-position interpolations such as `.x-${suffix}` without making a top-level `${sharedStyles}` ambiguous. - Added regression coverage for attribute selectors, pseudo selectors, `@keyframes`, `@font-face`, `@property`, and preserving HTML quoted-attribute interpolation. # cm6-lezer-lit-html 0.8.0 rename - Package renamed to `cm6-lezer-lit-html`. - Public parser export renamed to `litJavaScript`. - Grammar source renamed to `src/litJavaScript.grammar`. - Version set to `0.8.0`. - Parser behavior is unchanged from the v0.5 fixture pass. # Lit direct JavaScript grammar fork This fork replaces the mixed-parser approach with ordinary grammar productions in `src/litJavaScript.grammar`. New direct tagged-template expression nodes: - `LitHtmlTaggedTemplateExpression` - `LitSvgTaggedTemplateExpression` - `LitCssTaggedTemplateExpression` New Lit template node families include: - `LitTemplate` - `ComponentElement` - `Element` - `OpenTag` / `CloseTag` / `SelfClosingTag` - `EventListener` - `PropertyInput` - `BooleanInput` - `SpreadInput` - `AttributeInput` - `DynamicValue` - `Interpolation` CSS tagged templates parse as ordinary `StyleSheet` nodes containing neutral `CssText` chunks and `Interpolation` children. This is intentionally not a mounted/mixed parser. `html`, `svg`, and `css` tagged template bodies are parsed inside the JavaScript grammar itself, so plain tree traversal can see the embedded syntax without `resolveInner`. Known tradeoff: this is a direct grammar fork, not a full browser-grade HTML/CSS grammar. It is shaped for matcher visibility and robust Lit-event/property tokenization rather than strict HTML validation. ## v0.2 refinement Refined against broader Lit patterns and the uploaded `cm-lispgram-panel` source. Added: - `VoidElement` / `VoidOpenTag` / `VoidTagName` for standard HTML void tags such as `input`, `br`, `img`, `meta`, and `link`. - Regression coverage for quoted interpolation attributes, unquoted dynamic attributes, self-closing components, void elements, nested `html` templates inside interpolations, `repeat(...)`, conditional nested templates, `svg`, `css`, and non-Lit template fallback. Fixed: - `` now stays under `LitHtmlTaggedTemplateExpression` instead of falling back to generic `TaggedTemplateExpression`. - Text containing words that are also void tag names, such as `input`, no longer creates error nodes inside ordinary element text. Still intentional: - This is a matcher-oriented grammar, not a full HTML/CSS validator. - Generic non-Lit template strings may expose some reused local token names internally, but they remain under `TemplateString` / `TaggedTemplateExpression` rather than Lit nodes. ## v0.4 refinement Refined against two larger LitElement example files supplied during development. Structural change: - The direct Lit parser now uses a matcher-oriented tag stream rather than strict nested HTML validation. Tags remain ordinary syntax-tree nodes, but the parser no longer requires every open tag to be reduced with its matching close tag. This avoids cascading parse errors in real Lit templates with nested `html``...`` branches, conditionals, repeated templates, and complex render helpers. Added matcher-visible nodes: - `DynamicElement` - `DynamicOpenTag` - `DynamicCloseTag` - `DynamicSelfClosingTag` - `ElementExpression` - `LitDeclaration` Fixed: - Void tags may be explicitly self-closed, e.g. `` and ``. - Real Lit render methods with conditionals such as `${cond ? html`...` : html``}` parse without error nodes. - Element-position directive expressions parse, e.g. `
`. - Spread-like bindings without an equals sign parse, e.g. ``. - Static/dynamic tags created with interpolation parse as `DynamicOpenTag` / `DynamicCloseTag`, e.g. `<${unsafeStatic(tag)}>`. - Declarations such as `` keep the template under `LitHtmlTaggedTemplateExpression`. Tradeoff: - The Lit template grammar is now intentionally less validating about HTML parent/child structure. That is deliberate for the matcher use case: it preserves event/property/attribute/tag nodes without letting one complex or partial template damage the whole JavaScript CST. ## v0.5 fixture pass - Added two additional real Lit fixtures: - `test/fixtures/cm-cst-debug-window.js` - `test/fixtures/cm-ai.js` - Added `test/lit-direct-more-fixtures.js` to lock in real-world templates with nested `html``...`` branches, boolean attributes, event listeners, property bindings, void inputs, and CSS blocks. - No parser-table change was required for these fixtures. They parse cleanly with the v0.4 grammar shape. - Re-tested the broader upstream JavaScript suite. The fork still parses plain templates, but generic non-Lit template strings expose the broader local token vocabulary in their child nodes. That remains documented as a compatibility tradeoff of keeping Lit/CSS tags as ordinary single-tree grammar nodes instead of mounted parsers. ## 0.8.2 - Fixed noisy generic JavaScript template strings. Primitive Lit/CSS token terms are now hidden lexical tokens, so non-Lit templates such as `` `${type}-${range.from}` `` and `gql` templates no longer expose `LitName`, `LitSpace`, `CssBracketStart`, etc. in the CST. - Kept Lit/CSS tagged templates direct: `html`/`svg` still parse as `LitHtmlTaggedTemplateExpression` / `LitSvgTaggedTemplateExpression`, and `css` still parses as `LitCssTaggedTemplateExpression` with `StyleSheet` / `CssText` / `Interpolation` nodes. - No API-shape change from 0.8.0: `litJavaScript` remains the raw parser export. ## 0.8.3 - Replaced exposed `CssToken` implementation nodes with neutral `CssText` nodes under `StyleSheet`. - Kept `css` templates direct as `LitCssTaggedTemplateExpression` / `StyleSheet`. - Added regression coverage for large Lit CSS fixtures and verified ordinary `TemplateString` nodes still do not leak Lit/CSS tokens. ### 0.8.5 Nested Lit template fix: - `html` / `svg` / `css` tag recognition is now handled by a contextual external tokenizer that only emits Lit tag tokens when the identifier is followed by optional whitespace and a backtick. - This prevents complex nested `html` templates from being captured by the generic JavaScript `TaggedTemplateExpression` path. - Imports such as `import { html, css } from "lit"` and ordinary identifiers remain valid. CSS remains intentionally shallow in this direct grammar: `LitCssTaggedTemplateExpression > StyleSheet > CssText/Interpolation`. A richer CSS grammar would require porting substantially more of `@lezer/css` or returning to mounted mixed parsing for CSS. ## 0.8.6 - Reworked `css` tagged-template parsing from a flat `CssText` stream into a robust token-level CSS CST. - Added matcher/highlight nodes for `CssPropertyName`, `CssClassSelector`, `CssHash`, `CssIdentifier`, `CssAtKeyword`, `CssPunctuation`, and `CssComment`. - Preserves `Interpolation` nodes inside CSS values. - Kept CSS parsing forgiving: it distinguishes useful CSS syntax without trying to validate the full CSS grammar. ## 0.8.7 - Iterated the CSS grammar with focused Lezer-MCP slices, then ported the safe change to the full JavaScript fork. - Added `CssDeclaration`, `CssDeclarationValue`, and `CssValuePunctuation` nodes so CSS declarations are grouped instead of appearing only as a flat token stream. - Kept the CSS parser forgiving: selectors/at-rules remain mostly token-level, while declarations are structured enough for matching and highlighting. - Added `test/lit-direct-css-declarations.js`. ## 0.8.8 Implemented the CSS rule/block iteration after checking the Lezer constraints around local token groups. The failed approach was mixing external CSS text tokens with the template-local tokenizer; Lezer rejects that because local token groups cannot be used together with unrelated token sources in the same parse states. The shipped approach keeps CSS inside the existing template-local token island and avoids broad new tokens that would interfere with Lit HTML text. Instead, it uses the existing Lit/template tokens with adjusted precedence and grammar structure: - `CssRule` groups selectors and blocks. - `CssSelector` groups selector atoms, including descendant selector sequences. - `CssBlock` and `CssBlockContent` group block contents. - `CssAtRule` now has `CssAtPrelude` plus a nested `CssBlock` or semicolon. - `CssDeclaration` / `CssDeclarationValue` remain grouped from 0.8.7. - `CssRawText` covers numeric/custom-property-ish raw fragments without adding broad local tokens that break HTML templates. Validated cases include `calc(var(--dock-h) + 16px)`, `color-mix(in srgb, var(--cm-text, #000) 12%, white)`, decimal values such as `0.08em`, URL strings such as `url("/a?b=c&d=e")`, pseudo selectors, descendant selectors, and nested `@media` rules. ## 0.8.9 - Fix CSS vendor-prefixed property names such as `-webkit-user-select:` and `-ms-user-select:`. - Prevent complex `css` template bodies with vendor-prefixed declarations and `!important` values from leaking out of `LitCssTaggedTemplateExpression` into ordinary JavaScript/error nodes. ## 0.8.11 CSS hardening pass for edge cases discovered after 0.8.10. Adds coverage for at-rule string preludes such as `@charset`/`@import`, interpolated CSS property names like `${prop}: value`, nested/braced custom-property values, and additional modern nesting/container/scope selector cases. Keeps complex CSS inside `LitCssTaggedTemplateExpression` without leaking into JavaScript recovery.