Element Inline style attribute showing as error

[EmanSza]

Steps to reproduce:

Using EJS inside of a inline style atrribute shows as a lint error. Does not affect code

    <div class="title">
        <p style="color: <%= iconColor %>"><%= title %></p>
    </div>

Expected result:

Have the lint not detect a "problem" with it.

[tmdkamins]

I'm also running into this issue. This EJS extension injects itself into the built-in HTML language (via "injectionSelector": "L:text.html") which itself references the built-in CSS language/syntax, so it's not immediately obvious how to fix this.

As a slightly hacky workaround that at least makes the errors go away for now, consider your example:

<div class="title">
    <p style="color: <%= iconColor %>"><%= title %></p>
</div>

Instead, you can hide the whole style attribute from the syntax by dynamically outputting the attribute name, contents, and open/close quotes like this:

<div class="title">
    <p <%- 'style="color: ' %><%= iconColor %><%- '"' %>><%= title %></p>
</div>

Note that this is masquerading as something else (keyword.operator.relational.js?) in the grammar which doesn't cause errors now but might at some point in the future.

[tmdkamins]

The above "workaround" (aka grotesque hack) only goes so far, and I've run into a similar issue with script tags. This current issue we're commenting on is specific to style tags, so this may be a bit out of scope, but I wanted to mention it as it is similar enough that they both might have the same ultimate fix.

<script>
    const x = <%- myvar %>;
</script>

This gives an "Expression expected. javascript" error on the "<%-".

Suggestion:

It would be great (and simpler than chasing down every little syntax quirk) if there was some way to just tell the EJS linter to ignore the next line, just like there is with eslint and others. E.g. something like:

<script>
    <%# ejslint-disable %>
    const x = <%= myvar %>;
    <%# ejslint-enable %>
</script>

[tmdkamins]

After looking deeper into the issue of EJS in script blocks and how VS Code and languages work, it appears that the EJS language syntax (which injects into L:text.html) is responsible for tagging parts of the text, but VS Code itself forwards what it thinks is JS/TS to its internal TS Server for linting. And I don't believe it's possible for a language syntax to prevent other patterns from outside of itself (such as the one that tags source.js on code which is built in to VS Code itself) from matching. So the previous suggestion of adding some kind of disable/enable wrapping may not be possible without rebuilding an entire language definition from scratch.

Instead, another hacky workaround for using EJS in script tags without flagging invalid squiggly red errors looks like this:

<%-'<script>'%> <%# Syntax/lint hack to allow EJS in script tags %>
    const x = <%- myvar %>;
<%-'</script>'%>

This outputs a valid script block but tricks the language syntax into thinking the inner content is still HTML. Because it creates its own script block, you might need to assign globals to window if you need to share anything between blocks. Or take this idea and twist it to your own situation.

Of course the simpler approach of wrapping it in a string works too (and tricks the language syntax into thinking the inner content is a string). But with complex data, this adds bandwidth and CPU overhead such as parsing extra escaped JSON instead of just assigning it directly. But it works:

<script>
    const x = "<%= myvar %>";
    // (Parse x here if necessary)
</script>

Hopefully all of this helps save somebody a bit of time and hair. And if anyone has a better idea, please do share, because whether you like it or not, this is really NOT what peak performance looks like...