HTML File changes background color mid-file

Karl Perry

Not sure if this is intended behavior for .HTML files, but …

In an .HTML file, right after a <script> tag, the background color changes from white to light blue. 75 lines later the background to the right of a line’s final comma is white, but the background color of the next and subsequent lines is back to light blue. Then, in the middle of a line further down, the background color changes back to white for the rest of the file.

Where can I look to troubleshoot why this is happening?
Here is where the background goes light blue …

Then it turns back white after the final comma in a line, but then back to light blue again …

Finally, the background goes back to white right after the closing paren in “data.topic” and remains white for the rest of the file.

Thanks in advance for any help.

Coises

@Karl-Perry

I would guess that the problem at line 143 is because the character sequence </ is not legal within script tags. That definitely applies to string literals; I couldn’t find a clear statement about template literals, but I suspect it applies there, too.

I’m not sure exactly what’s happening on line 98, but judging by the coloring there and elsewhere, it looks like the syntax highlighter doesn’t understand template literals at all. That would be a Lexilla problem, I suppose. I could only find one issue that sounded related, though, and that discussion lost me before I got halfway through.

PeterJones

@Karl-Perry said in HTML File changes background color mid-file:

Then it turns back white after the final comma in a line, but then back to light blue again …

There are two things going on in that portion of the screenshot. One is that I don’t believe you need to escape quote marks inside a JavaScript template literal (backtick string). The other is that it appears the JS-embedded-in-HTML parser that Notepad++ uses might not be handling template literals correctly.

Using the normal Language > J > JavaScript, it properly recognizes and formats the template literal (the Style Configurator for non-embedded JavaScript calls it the STRING RAW style):

v = "double"
t = `backtick "embedded quote" ${v} here`
x = v + t

… but if you wrap that in some HTML and use Language > H > HTML,

<head>
<script>
v = "double"
t = `backtick "embedded quote" ${v} here`
x = v + t
asdfafsdf
</script>
</head><body>
<h1>blah blah</h1>
<p>here we go</p>
</body>

then it doesn’t recognize the template literal.

And yes, if I escape double-quotes inside a template literal, then a parser that doesn’t recognize the template literal will not see that first double-quote as escaped. Pretending to be the LexHTML-based embedded-JS subparser, I think it’s seeing:

`TEXT 100,100,\"3\",0,3,3,\"${printContent}\"`
^ it doesn't seem to recognize the backtick to start the template literal
`TEXT 100,100,\"3\",0,3,3,\"${printContent}\"`
 ^^^^ it is treating TEXT as a WORD
`TEXT 100,100,\"3\",0,3,3,\"${printContent}\"`
      ^^^,^^^ it is treating those as numbers
`TEXT 100,100,\"3\",0,3,3,\"${printContent}\"`           
              ^ it is not using this to escape a character, because it doesn't realize it's in a string
`TEXT 100,100,\"3\",0,3,3,\"${printContent}\"`           
               ^ this is the start of a what it thinks is a "string"
`TEXT 100,100,\"3\",0,3,3,\"${printContent}\"`           
                 ^^       ^^               ^^ these three are all being treated by the parser as part of the "-string

… but it seems to be ending the string at the end of line, because the "BAR 100,100... line is correctly interpreted as a full start-and-end-of-string.

And I’m betting @Coises is right about </ not being legal in template literals inside an HTML script tag. (he beat me to that part)

My educated guess is that it’s a difference in the way that Lexilla’s LexHTML handles javascript vs the way that the full javascript lexer parses javascript (the embedded sublexer apparently doesn’t recognize template literals).

The next steps would be to download the most recent SciTE from the Scintilla.org website – if SciTE has the same problem with your JS-embedded-in-HTML file, then the bug’s definitely with Scintilla’s Lexilla library (which is what Notepad++ uses for lexing). At which point, I’d search their active and closed issues to see if someone has asked about template literals in embedded javascript. I’d also check their older https://sourceforge.net/p/scintilla/bugs/ , which is now reserved for Scintilla-specific bugs, but since the lexers used to be part of that repo before they split it into Lexilla, there still might be an open or closed issue at the older bugslist. (I do have vague recollections of some long-time-ago conversation about javascript-embedded-in-HTML having troubles with template literals, but I don’t have time to do the searching for you right now. Oh, just as I was about to post, @Coises edited with a link to a possible Lexilla issue. Yay for him!)

To sum up my long post: @Coises probably identified the early-termination-of-javascript problem; and the embedded-Javascript’s template-literal problem could very well be a bug (or non-implemented feature) of the Scintilla project’s Lexilla library’s LexHTML

rdipardo

@PeterJones said in HTML File changes background color mid-file:

the embedded-Javascript’s template-literal problem could very well be a bug (or non-implemented feature) of the Scintilla project’s Lexilla library’s LexHTML

It’s a known issue that also affects PHP:

A single lexer module provides highlighting for (X/HT)ML and a few embedded scripts, including PHP, JavaScript, VB and Python. It is many years behind the current JavaScript standard; it was simply never programmed for interpolated strings between backticks (a JS feature since ca. 2015).