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 literal, the behavior is not as dangerous, but still surprising.)

▲ o11c 8 days ago | parent | next [-]

But note that there's also `<script type="application/json">` these days (usually only useful with `id=`) ... and `importmap` I guess.

▲ themafia 8 days ago | parent | next [-]

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 attribute.

Although 'importmap' has specific functionality, as does 'speculationrules', although they operate similarly. My favorite is type="module" which competes with the higher level attribute nomodule="true". Anyways it looks like <script> has taken a lot of abuse over the years:

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

▲ masklinn 8 days ago | parent [-]

> My favorite is type="module" which competes with the higher level attribute nomodule="true". Anyways it looks like <script> 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 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

▲ themafia 8 days ago | parent [-]

You can write:

    <script nomodule="true" type="module"></script>

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.

▲ domenicd 8 days ago | parent | next [-]

It does? https://html.spec.whatwg.org/multipage/scripting.html#attr-s...

▲

themafia 8 days ago | parent [-]

It specifies it in the abstract. Did you mean to link here instead of to the 'src' attribute documentation?

https://html.spec.whatwg.org/multipage/scripting.html#attr-s....

My expectation was that this condition would have been reflected in MDNs documentation where it breaks the conditions for 'charset' and 'defer' out.

▲

masklinn 8 days ago | parent [-]

Why? MDN does not purport to be exhaustive, that's the spec's job.

▲

themafia 8 days ago | parent [-]

MDN does a pretty good job anyways. Perhaps I feel that it would be in keeping with that spirit to have this condition documented. This is partly because MDN is far easier to read for the purposes of _reference_ than the spec which is easier to read for the purposes of _implementing_. It's also easier to search and to share links to, as the link you presented earlier was both wrong and confusing, and there was no natural way to link to the part of the document you intended.

Perhaps the spec isn't the right tool for every job? That's why, for me, at least.

	▲	moron4hire 5 days ago \| parent [-]
		Submit a change, then. MDN isn't written by some secret cabal. It's written by all of us.

▲ masklinn 8 days ago | parent | prev [-]

> You can write:

Yes, and you can write

    <noscript>
        <script>
             ...
        </script>
    </noscript>

▲ minitech 5 days ago | parent | prev | next [-]

Yes, that option is the real “just do this”.

- escape `<` as `\u003c`

  <script id="my-json" type="application/json">{{ escaped_json }}</script>

  JSON.parse(document.getElementById('my-json').textContent)

No __proto__ issue, and no dynamic code at all, so you can use a strict CSP.

▲ jgalt212 8 days ago | parent | prev [-]

Why does the author ignore this method? Django docs show this as a best practice via a built in tag.

▲ pwdisswordfishz 4 days ago | parent | prev [-]

Or you can use JSON.parse with a string literal on the client side. Which is, surprisingly, more performant than parsing at compile time.

https://www.youtube.com/watch?v=ff4fgQxPaO0