typo fixed lol, I didn’t even know that was an English word (especially one with that meaning), I just typed the Italian (my native language) spelling of the word by mistake
Installed, immediately showed my <hgroup> is deprecated, and linked to MDN, where MDN says it’s “widely available” and makes no mention of deprecation.
Not sure where it’s getting its data, but back when the W3C was involved with handling the “Living Document” spec of HTML5, they said <hgroup>would be deprecated, but when the WHATWG took over stewardship, they renewed the relevance and support of said tag, so this extension is pulling either old or poorly sourced information.
The fun part is this also affects parsing, <p><div></div></p> becomes <p></p><div></div> since div can’t go inside p. This however is not enforced at the DOM level, so if you use Javascript, you can easily put a div into a p, and so the browser needs to support that structure regardless!
Nope sorry, and I don’t think I will add support for that in the future, as allowing this HTML ‘feature’ would produce more confusing errors for the user and hide mistakes on occasion.
Even if your goal is to emit minimal html via optional tag omission, wouldn’t you want the source to be in the stricter language subset to avoid mistakes?
HTML doesn’t allow end tags to be omitted willy‐nilly. It’s only allowed in a subset of cases that are unambiguous, like <li><li> (since list items obviously can’t be nested) or <td><td> (since table cells obviously can’t be nested). It’s a convenient feature in that sense since the resulting document is no less rigorous than the redundant version.
Much better to make it an error, because even if unambiguous for the parser, it can still be a source of confusion
<ul>
<li>item1</li>
<li>item2<li>
<script id="this-script">
let ul = document.getElementById("this-script").parentElement;
console.log(ul.tagName); // prints "LI"
// *confused screams by the developer*
</script>
</ul>
If the goal is to type less, you would be better served by both editor support for automatic insertion of tags (from simple stuff up to emmet), and/or using a different format that can render to html, like kdl
This looks super cool, and if I was a Vim or VS Code user I would use it right now. I wonder how it would integrate with the various HTML/XML editing modes for Emacs like nxml-mode, sgml-mode, html-mode and web-mode.
If you can run a command on save, integration should be easy, you can both pipe the data via stdin or point the CLI tool at a file to get syntax checking and autoformatting, depending on how you invoke it.
If you decide to figure out how to integrate it, a PR to update the project’s readme with those instructions would be appreciated (see this other example).
nxml-mode has its own validator built-in, so I would say this would be a replacement for that rather than augmenting it.
I was very surprised that there weren’t any existing HTML servers for LSP until now that did this, but I guess HTML is old enough and simple enough that most editors already have an existing way to do this, and thus the demand is not as great? Plus also since browsers are very accepting of bad HTML, there is less demand because lots of programmers just give up and write bad HTML? Still feels very weird.
The excitement around Docker containers that bombards our industry is disappointing but makes abstract sense. Whether the sensible boundary involves WASI, Capsicum, or something else, I’m always happy when it’s more than just incessant Docker noise.
Templating yes, but not with {{curlies}}. SuperHTML is actually a templating language used by Zine, my static site generator. The LSP functionality is part of the developer tooling I developed for the Zine ecosystem.
SuperHTML is explicitly designed to be a templating language that doesn’t treat HTML as flat text, so it uses special elements and attributes to express logic. You can read more here.
Curretly only Zine uses SuperHTML but the two projects are decoupled and so eventually other things, like a web framework for example, could decide to adopt SuperHTML as their templating language.
Is this a typo or a reference to Matthew Lugg’s lack of membership in the twelve tribes? 😅
typo fixed lol, I didn’t even know that was an English word (especially one with that meaning), I just typed the Italian (my native language) spelling of the word by mistake
Installed, immediately showed my
<hgroup>is deprecated, and linked to MDN, where MDN says it’s “widely available” and makes no mention of deprecation.Not sure where it’s getting its data, but back when the W3C was involved with handling the “Living Document” spec of HTML5, they said
<hgroup>would be deprecated, but when the WHATWG took over stewardship, they renewed the relevance and support of said tag, so this extension is pulling either old or poorly sourced information.Thank you, fixed in this commit: https://github.com/kristoff-it/superhtml/commit/24651f9ee587989dbfed85a58816d9674b5c263b
I’ve also released a new version of the VSCode extension with this change.
Wow, that was a fast, thanks!
(Also, sorry if my comment sounded negative. Just re-read my comment and realized it’s worded a little terse.)
I’ve been looking for an HTML formatter so I’m definitely going to give this a try!
Does it error on
<p><p></p></p>/<p><div></div></p>?Not yet but I plan to!
Added a corresponding issue https://github.com/kristoff-it/superhtml/issues/28
I had no idea that’s an error, where can I read more about it?
… Conflicts with:
And more fun can always be found in the whole whatwg spec.
The fun part is this also affects parsing,
<p><div></div></p>becomes<p></p><div></div>sincedivcan’t go insidep. This however is not enforced at the DOM level, so if you use Javascript, you can easily put adivinto ap, and so the browser needs to support that structure regardless!The example with
<h1><h1>is not valid HTML. Theh1..6elements all require both tags.In any case, for those of us who prefer to omit optional tags, could this ‘feature’ be disabled?
Nope sorry, and I don’t think I will add support for that in the future, as allowing this HTML ‘feature’ would produce more confusing errors for the user and hide mistakes on occasion.
I’ve updated the example with
<li>item<li>.Even if your goal is to emit minimal html via optional tag omission, wouldn’t you want the source to be in the stricter language subset to avoid mistakes?
When I’m hand-writing HTML I especially want to be able to not type unnecessary things.
HTML doesn’t allow end tags to be omitted willy‐nilly. It’s only allowed in a subset of cases that are unambiguous, like
<li><li>(since list items obviously can’t be nested) or<td><td>(since table cells obviously can’t be nested). It’s a convenient feature in that sense since the resulting document is no less rigorous than the redundant version.The syntax might be unambiguous, but it’s still error prone.
This:
Becomes this:
Much better to make it an error, because even if unambiguous for the parser, it can still be a source of confusion
If the goal is to type less, you would be better served by both editor support for automatic insertion of tags (from simple stuff up to emmet), and/or using a different format that can render to html, like kdl
This looks super cool, and if I was a Vim or VS Code user I would use it right now. I wonder how it would integrate with the various HTML/XML editing modes for Emacs like
nxml-mode,sgml-mode,html-modeandweb-mode.Why not just use eglot, like with every other language server?
If you can run a command on save, integration should be easy, you can both pipe the data via stdin or point the CLI tool at a file to get syntax checking and autoformatting, depending on how you invoke it.
If you decide to figure out how to integrate it, a PR to update the project’s readme with those instructions would be appreciated (see this other example).
nxml-mode has its own validator built-in, so I would say this would be a replacement for that rather than augmenting it.
I was very surprised that there weren’t any existing HTML servers for LSP until now that did this, but I guess HTML is old enough and simple enough that most editors already have an existing way to do this, and thus the demand is not as great? Plus also since browsers are very accepting of bad HTML, there is less demand because lots of programmers just give up and write bad HTML? Still feels very weird.
The WASI bundling with VSCode extensions is some seriously cool stuff. Imagine bundling the Lua runtime in the Lua plugin!
The excitement around Docker containers that bombards our industry is disappointing but makes abstract sense. Whether the sensible boundary involves WASI, Capsicum, or something else, I’m always happy when it’s more than just incessant Docker noise.
Zig makes it trivially easy to target both WASI and all other native platforms from one codebase.
This is killer. Any chance you’ll allow mustache/django-style
{{ if foo }}or{% safe %}templating?Templating yes, but not with {{curlies}}. SuperHTML is actually a templating language used by Zine, my static site generator. The LSP functionality is part of the developer tooling I developed for the Zine ecosystem.
SuperHTML is explicitly designed to be a templating language that doesn’t treat HTML as flat text, so it uses special elements and attributes to express logic. You can read more here.
Curretly only Zine uses SuperHTML but the two projects are decoupled and so eventually other things, like a web framework for example, could decide to adopt SuperHTML as their templating language.