pushqrdx/vscode-inline-html

When using /*css*/ for inline-style declarations it bugs out and propagates somewhat to containing JS context

Opened this issue · 0 comments

[Might be related to #37 and #48 ]
[Includes solution proposal]

I was using /*css*/ for setting the HTMLElement.prototype.style.cssText CSSStyleDeclaration string and it seems to bug out at some point:

image

Notice:
The apparently unbalanced braces highlighted red.
The uncolored color: css declaration.
The uncolored ending backtick.
The uncolored await keyword (should be same color as if and else)

I went lightly digging in the code and ended up inferring from the css test cases in /tests/index.js that /*css*/ declarations seem to expect curly brackets in them. Indeed, removing the brackets (but not the :host ruler) in the test function does repro:

image

Seems to break all preceeding nested opening brackets, and all those they would balance to from the first declaration. Noticing that if I break an earlier declaration (ss in line 3) it preserves those. It also preserves following siblings balanced pairs, and nested ones.

Looking at #37 and #48 I'm led to believe this differentiated behavior between css (strictly for css stylesheet-style declarations) and style (strictly for inline-style declarations) is by design. So perhaps it would do to simply add a visible, "⚠warning-like⚠" disambiguation on the readme clarifying each use case scenario.

Still, maybe look into limiting the code invalidation because of the propagating consequences for the containing JS language context (it even breaks the >Go to bracket functionality from the Notepad++ keymap extension). Perhaps changing the regex in

this._expression = /(\/\*\s*(css|less|scss)\s*\*\/\s*`|(?<!`)(?:css|less|scss)\s*`)([^`]*)(`)/gi;

and
private _expression = /(\/\*\s*(css|less|scss)\s*\*\/\s*`|(?<!`)(?:css|less|scss)\s*`)([^`]*)(`)/gi

to /(\/\*\s*(css|less|scss)\s*\*\/\s*`|(?<!`)(?:css|less|scss)\s*`)(\s*.*?\{[^`]*\s*\}\s*)(`)/gi. Which AFAICT has the effect of outright not recognizing the string as a css context if a balanced topmost pair of brackets are missing.

Looking at proposed https://regex101.com/r/lA6oO4/1 it seems to match the same boundaries as the current https://regex101.com/r/0KOPbL/1 while making whatever rules optional (I assume the :host rule declaration from test.js isn't mandatory) but still expecting to have an opening and closing brackets somewhere in between the backticks (as close as possible to the first and separated only by optional whitespace from the last). I realize I could have probably done a PR, but I'd leave the decision on whether to go this way to you (plus, you're already infinitely more familiar than I with the workings of the extension and may come up with something better) :).

Many thanks for your continuing work on this awesome extension.