11 ms·
HTML comments work in JavaScript too
- jkrems 5y agoImportant footnote: Unless you are in an JavaScript module file. They work in scripts only. E.g. the following is a syntax error in a module but a valid script: <!-- ok if it's a script only --> console.log("ok");
- tentacleuno 5y agoStrict mode is forced in modules, while you need to "use strict" in scripts. That might explain it.
- jkrems 5y agoIt's actually not related to strict mode. HTML comments work fine in strict mode as well as sloppy mode in scripts. The difference here is that modules are a different file format / syntax and they fundamentally don't include parts of the syntax that was supported in the older script file format (and vice versa: they allow syntax like top-level await that wasn't/isn't valid in the script file format).
- lhorie 5y agoTechnically, they "work" in both scripts and modules, they just work differently in each case. This is valid Javascript that returns true if running in script mode or false if running in module mode: const isScript = (x = true) => x <!--x console.log(isScript()) // true or false depending on whether the code is ESM What's happening is that `<!--` is a comment token in script mode, but it's parsed as `< ! --` in module mode.
- ape4 5y agoI would like more commenting options in CSS. Doing /* something */ is the only way I know of.
- thrusong 5y ago// I would love a two-forward-slashes comment in CSS
- ajb92 5y agoMe too. I expect though that there'd be lots of breaking changes around existing CSS having, for instance,`background-image: url(https://somedomain.abc/somefile.png https://somedomain.abc/somefile.png)`, as quotes are optional in URL values
- david422 5y ago// is only a comment if there is only whitespace directly before it?
- mananaysiempre 5y agoNote that //foo/bar.txt is a valid address (a “network-path relative URI reference”[1]). Those are rarely seen but are used sometimes when the same resource or snippet needs to be usable with both HTTP and HTTPS. (I think I first learned about this form while reading a text on gradual migration to HTTPS circa 2014.) My impression is this form might actually be the original way of expressing network paths, what with UNC in Windows (\\server\share\file etc.) and POSIX carving out an exception specifically for two slashes at the beginning of a pathname (that is, foo//bar is the same as foo/bar and ///foo/bar is the same as /foo/bar, but //foo/bar may or may not be the same as /foo/bar). [1] https://datatracker.ietf.org/doc/html/rfc3986#section-4.2 https://datatracker.ietf.org/doc/html/rfc3986#section-4.2
- chrismorgan 5y agoOn the web, and most of the rest of the internet as well for most practical purposes, WHATWG’s URL Standard is now the normative reference for URLs, and obsoletes IETF’s RFC 3986 and 3987. (Source: https://url.spec.whatwg.org/#goals https://url.spec.whatwg.org/#goals.) There, this concept is called a scheme-relative URL (a much more sensible name): https://url.spec.whatwg.org/#scheme-relative-url-string https://url.spec.whatwg.org/#scheme-relative-url-string. They’re not the most common, but they’re not especially rare, either. HTML compressors especially will normally support emitting URLs in this form—you tell the compressor “this file you’re compressing will be served from the URL https://1.example/path/to/foo” https://1.example/path/to/foo” and it uses this knowledge to rewrite URLs inside the page, https://1.example/path/to/bar https://1.example/path/to/bar into bar, https://1.example/path/from https://1.example/path/from into ../from, https://1.example/baz https://1.example/baz into /baz, https://2.example/ https://2.example/ into //2.example, and http://1.example/ http://1.example/ into http://1.example http://1.example.
- somehnacct3757 5y agoI look forward to reading a future disclosure showing how you can somehow use this information for mayhem
- yohannparis 5y agoNow I feel old to remember doing this when adding a tiny bit of Javascript to display alert() as a cool feature.
- Kiala 5y agoAh, the good old <script language="JavaScript1.2"> days.
- nightgarden 5y agoAh, the good ol' days of javascript text animations in the status bar. I remember them too
- danShumway 5y agoHuh, that's really interesting, the Firefox dev tools even do proper syntax highlighting. I wonder how JSX parsers react to this. A quick test with an online Babel parser is throwing errors, so I assume it's just not supported? But maybe there's a setting. JSX also by default doesn't have an easy way to insert comments into the generated HTML, so I don't think JSX is the reason why it wouldn't be supported in Babel. My understanding was always that it has more to do with comments being treated slightly differently than normal document nodes, but I could be wrong. I guess more likely the reasoning is that it's just obscure. I've been programming JS for a reasonably long time and never knew this was supported.
- colejohnson66 5y agoThe reason for the error from Babel is that JSX is an HTML like (more so XML) syntax, not HTML. The obtuse comment syntax is because you need to escape to JavaScript with the braces, then use a multi-line JavaScript comment block. I wish they would've allowed HTML comments in the original design, but my guess is that comments were an oversight that just happened to work due to the escape syntax.
- schwartzworld 5y agoIt shouldn't be hard to create a component that does what you want <Comment>some comment</Comment>
- deleted 5y ago[deleted]
- chrismorgan 5y agoOne good reason not to support it is that it’s ambiguous: is it a comment (to be ignored), or does it represent a comment node? If the former, why not just use /…/? If the latter, it requires that the library or compilation target or whatever support comment nodes, which is more work for a dubious feature.
- 5y ago
- nayuki 5y agoIn XHTML (XML) mode, comments are treated as actual comments. In the following working code: <script> alert("Hello <!-- Comment 0 -->world"); <!-- Comment 1 alert("Bonjour le monde"); </script> Comment 0 gets removed by the XML parser so it doesn't go into the alert string. Comment 1 is seen by the JavaScript parser and gets removed at that stage.
- chrismorgan 5y agoDemonstration of this, using a data: URL (paste it in the address bar): data:application/xhtml+xml,<script xmlns="http://www.w3.org/1999/xhtml">%0Aalert("Hello <!-- Comment 0 -->world");%0A<!-- Comment 1%0Aalert("Bonjour le monde");%0A</script> (Observe also how what I’ve written here nets you a document that lacks html, head and body tags—HTML syntax fills those in through the magic of optional start and end tags, but XML syntax takes what it’s given and can be used to do things like nesting hyperlinks or putting a heading inside a paragraph. The HTML and XML syntaxes for HTML are actually mutually incompatible.)
- nayuki 5y agoVery nice use of media types and data URIs! Indeed, the root of your document is <script>, which is rather funny. Of course HTML and XML syntaxes are incompatible, but there is a reasonable polyglot subset that is compatible with both. Other common things that HTML syntax won't let you do: <p><p></p></p>, <table><tr><td> without an implicit <tbody>. Why I know this obscure corner of the HTML standard is because I've been running my website on XHTML mode for more than a decade continuously. https://www.nayuki.io/page/practical-guide-to-xhtml https://www.nayuki.io/page/practical-guide-to-xhtml
- chrismorgan 5y agohttps://www.w3.org/TR/html-polyglot/ https://www.w3.org/TR/html-polyglot/ is good reading on this topic too. A fun thing that I learned recently is that `table > tr` is actually valid, the tbody is genuinely optional in the spec, even though the HTML syntax injects it.
- deleted 5y ago[deleted]
- yakshaving_jgt 5y agoAnother ugly historical snapshot, but JS in CSS instead: https://jezenthomas.com/you-think-css-in-js-is-bad/ https://jezenthomas.com/you-think-css-in-js-is-bad/
- err4nt 5y agoToday we have CSS custom properties which do similar things: - Authors can define custom properties as long as they start with a double-dash, like --demo - Authors can leave these values empty, or put any code that doesn't break CSS's syntax inside. This can be CSS values, it can be JSON, it can be other languages, even some JavaScript could be stored in CSS to be read later - Using JavaScript you can read the values of CSS custom properties, and set them So it's possible with a tiny bit of JS to re-create what the old IE expression() function used to do in any modern browser in a fully standards-compliant way
- mushyhammer 5y ago> So it's possible with a tiny bit of JS Not really. expression() was evaluated by just moving the mouse around, which is what allowed attaching stuff to your cursor with "just some CSS" https://web.archive.org/web/20120420154658/http://msdn.microsoft.com/en-us/library/ms537634(v=VS.85).aspx https://web.archive.org/web/20120420154658/http://msdn.micro... To do what expression() could do you need several event listeners at least which, I mean, of course you can still do it, but it's really unrelated to CSS Properties and just JavaScript at this point.
- err4nt 5y agoThis is actually part of the design of CSS custom properties. It's not an abuse, but part of how they've been designed to be used. You can trigger updates from your own code programmatically, as well as any event listeners (built-in or custom) or from Observers the browser may have (e.g. Resize Observer, Intersection Observer, Mutation Observer) or any other ways you want to update them!
- tomxor 5y ago
- Leszek 5y agoFun fact -- in V8 this is the only case which requires three token lookahead, to distinguish `<!-foo` meaning "less-than not negative foo" from `<!--` meaning "start of HTML comment". There's a whole rewinding mechanism in the scanner which wouldn't have to exist if not for this syntax.
- srcreigh 5y agoThat's extra funny considering `<!-foo` is an extraordinarily useless expression.
- eyelidlessness 5y agoIn useful code sure. But `<!-f` with its dynamic casting implications may be useful in code golf. I haven’t golfed in years so I’m not sure, but I can imagine it having some benefit I haven’t though of.
- srcreigh 5y agoYou may be right. Unless it's true that `<!-f` is always equivalent to `<!f`. Then again, I'd be even more horrified if the above statement is not true anyways.
- eyelidlessness 5y agoHad to try it! Here is some horror for your day: https://codepen.io/eyelidlessness/pen/abVrjQq https://codepen.io/eyelidlessness/pen/abVrjQq
- olliej 5y agoThis behaviour was a result of people transmitting "xhtml" as html back when people were obsessed with xhtml.
- chrismorgan 5y agoThis behaviour came long before the XHTML craze. This is from the early days of JavaScript, before <script> was universally supported.
- myfonj 5y agoMaybe worth mentioning tangentially related WTH of JS syntax: that there are two additional line breaks besides CR and LF: line separator (\u2028) and paragraph separator (\u2029). Some editors and text viewers render them as zero width spaces, so you can see something that seems like innocent line comment but what is actually executed: data:text/html;charset=utf-8,<script>//%E2%80%A9alert(1)</script> view-source of that document displays just `<script>//alert(1)</script>` in Firefox. In Chrome there is "P SEP" in dashed rectangle between `//` and `alert`, so you at least get a hint there is something fishy.