11–20 of 47 posts
That ship sailed several paragraphs ago, when got special treatment by the HTML parser. Too bad we couldn't all agree to parse consistently, or, you know, just &-escape the text like we do /everywhere else/ in HTML.
Discussing why parsing HTML SCRIPT elements is so complicated, the history of why it became the way it is, and how to safely and securely embed JSON content inside of a SCRIPT element today.
This was my first submission, and the above comment was what I added to the text box. It wasn’t clear to me what the purpose was, but it seemed like it would want an excerpt. I only discovered after submitting that it created this comment. I guess people just generally don’t add those? Still, to help me out, could someone clarify why this was down-voted? I don’t want to mess up again if I did, but I don't understand…
I think most of the time people dont add a comment to submissions, but if they do its more of the form: I found X interesting because of [insert non obvious reason why X is interesting] or some additional non-obvious context needed.
In any case, i don't think there is any reason to worry too much. There was no ill intent and at the end of the day its all just fake internet points.
> Not so fast, things are about to get messy That ship sailed several paragraphs ago, when got special treatment by the HTML parser. Too bad we couldn't all agree to parse consistently, or, you know, just &-escape the text like we do /everywhere else/ in HTML.
Wait can someone explain why a script tag inside a comment inside a script tag needs to be closed, while a script tag inside a script tag without a comment does not? They explained why comments inside script tags are a thing, but nothing further than that.
The other comment explains this, but I think it can also be viewed differently. It’s helpful to recognize that the inner script tags are not actual script tags. Yes, once entering a script element, the browser switches parsers and wants to skip everything until a closing script tag appears. The STYLE element, TITLE, TEXTAREA, and a few others do this. Once they chop up the HTML like this they send the contents to the…
If you're evaluating JSON as JavaScript, you also need to make sure none of the objects have a key named "__proto__", or else you can end up with some strange results. (This is related to the 'prototype pollution' attack, although searching that phrase will mostly give you information about the more-dangerous variant where two objects are being merged together with some JS library. If __proto__ is just part of a lite…
But note that there's also ` ` these days (usually only useful with `id=`) ... and `importmap` I guess.
type
This attribute indicates the type of script represented. The value of this attribute will be one of the following:
[...]
Any other value
The embedded content is treated as a data block, and won't be processed by the browser. Developers must use a valid MIME type that is not a JavaScript MIME type to denote data blocks. All of the other attributes will be ignored, including the src attribute.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Earlier quoted context omitted.
But note that there's also ` ` these days (usually only useful with `id=`) ... and `importmap` I guess.
It's even more general: type This attribute indicates the type of script represented. The value of this attribute will be one of the following: [...] Any other value The embedded content is treated as a data block, and won't be processed by the browser. Developers must use a valid MIME type that is not a JavaScript MIME type to denote data blocks. All of the other attributes will be ignored, including the src attribu…
It "conflicts" in the same way noscript[1] and script "conflict" no? They're basically related features, but can't really be made exclusive because the mere act of trying to do so wouldn't work: as the link indicates, executing code in a !module browser reserves the type (requires a specific set of types) so you can't use that as a way to opt in !module browsers.
[1] an other fun element with wonky parsing rules besides
Earlier quoted context omitted.
It's even more general: type This attribute indicates the type of script represented. The value of this attribute will be one of the following: [...] Any other value The embedded content is treated as a data block, and won't be processed by the browser. Developers must use a valid MIME type that is not a JavaScript MIME type to denote data blocks. All of the other attributes will be ignored, including the src attribu…
> My favorite is type="module" which competes with the higher level attribute nomodule="true". Anyways it looks like has taken a lot of abuse over the years: It "conflicts" in the same way noscript[1] and script "conflict" no? They're basically related features, but can't really be made exclusive because the mere act of trying to do so wouldn't work: as the link indicates, executing code in a !module browser reserves…
Wait can someone explain why a script tag inside a comment inside a script tag needs to be closed, while a script tag inside a script tag without a comment does not? They explained why comments inside script tags are a thing, but nothing further than that.
From the post: Everything until the tag closer is inside the script element. And: In fact, script tags can contain any language (not necessarily JavaScript) or even arbitrary data. In order to support this behavior, script tags have special parsing rules. For the most part, the browser accepts whatever is inside the script tag until it finds the script close tag . Note the sentence fragment "even arbitrary data." Thi…
Or did they always have two levels of script tag escaping but that behavior only got preserved when inside an HTML comment?
No other JavaScript behavior is different inside an HTML comment, and I’m still missing the connection between the HTML comment and the embedded not closing the tag besides that they were two things that older browsers might have done.
Wait can someone explain why a script tag inside a comment inside a script tag needs to be closed, while a script tag inside a script tag without a comment does not? They explained why comments inside script tags are a thing, but nothing further than that.
The other comment explains this, but I think it can also be viewed differently. It’s helpful to recognize that the inner script tags are not actual script tags. Yes, once entering a script element, the browser switches parsers and wants to skip everything until a closing script tag appears. The STYLE element, TITLE, TEXTAREA, and a few others do this. Once they chop up the HTML like this they send the contents to the…
Earlier quoted context omitted.
> My favorite is type="module" which competes with the higher level attribute nomodule="true". Anyways it looks like has taken a lot of abuse over the years: It "conflicts" in the same way noscript[1] and script "conflict" no? They're basically related features, but can't really be made exclusive because the mere act of trying to do so wouldn't work: as the link indicates, executing code in a !module browser reserves…
You can write: Which is a little weird. At the very least I'd expect the type="module" documentation to say that `charset`, `defer` and `nomodule` attributes have no effect.