[HN Gopher] SuperHTML is here to rescue you from syntax errors, ...
___________________________________________________________________
SuperHTML is here to rescue you from syntax errors, and it's FOSS
Author : rc00
Score : 48 points
Date : 2024-10-23 14:01 UTC (9 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| PreInternet01 wrote:
| Previous discussion, _sans_ El Reg hyperbole:
| https://news.ycombinator.com/item?id=41512213
| petesergeant wrote:
| This looks awesome but I don't really understand the complexities
| that mean this is new in late 2024 and wasn't one of the first
| LSPs implemented? Can someone explain?
| smaudet wrote:
| xml != html so you can't just plug an xml parser and a schema
| together and call it quits.
|
| Plus, there's things like browser support, relative paths, and
| content embedding to consider, which always made dedicated
| products like Adobe's (Macromedia's?) DreamWeaver hit-or-miss
| (on top of being a very clunky way to edit some tiny text
| files).
|
| As for why it took so long...well nobody cared enough, and
| everyone "just used scripts" i.e. Django, Wordpress, Ruby on
| Rails, etc, to get that "good enough" experience + access to
| testing. There's no reason this couldn't have been done back in
| 2014 when LSPs were first just starting to come into being...
| rozab wrote:
| There is an LSP from Microsoft, it just doesn't report this
| sort of syntax error (presumably for the sake of people doing
| templating etc)
| Semaphor wrote:
| > doesn't report this sort of syntax error
|
| It's because it's not a syntax error, but a legal construct.
| SuperHTML disallows things HTML allows.
| OtomotO wrote:
| So it should be called SubHTML instead?!
| kristoff_it wrote:
| I've never seen the language server that ships with VSCode
| produce any kind of diagnostic whatsoever, so I think it just
| doesn't implement any error checking.
| Semaphor wrote:
| This is not HTML. This is HTML, but without allowing all kinds
| of shortcuts.
|
| In HTML, <li>item<li> is correct (it gets parsed as
| <li>item</li><li></li> I think). In SuperHTML it throws an
| error. Essentially, this is an opinionated subset of HTML, and
| no one cared enough before.
| afavour wrote:
| ...so it's XHTML?
| taeric wrote:
| Can seem similar, but realize that the parsing rules for
| HTML are far more complicated than you'd think from this
| simple example. It is the idea of when tags are
| automatically closed that is odd, here. Consider how
| `<li><div>Hello<li>world. How <div/>Does this</li> work?`
| gets turned into elements.
|
| The common trap many run into is that `<div/>` essentially
| closes at the next boundary.
| kristoff_it wrote:
| It's not just that, I've never seen any other HTML language
| server produce diagnostics at all. All the major editors use
| the VSCode stock HTML language server and that thing just
| doesn't produce any diagnostic at all.
| Semaphor wrote:
| Huh. Wow. I don't normally use VSCode, and you are correct.
| JetBrain IDEs correctly report some nonsense like
| <p><div><img></ul>test</p> as an error, but VSCode does
| nothing. That's really weird.
| notpushkin wrote:
| > Author would like to see a switch back to plain old static
| HTML. Us too
|
| Wholeheartedly agree. Can we also go to XHTML5, while on it?
| wizzwizz4 wrote:
| Being able to write: <script src="util.js" />
|
| instead of: <script src="util.js"></script>
|
| would be nice. But it's not (iirc) compatible with WHATWG's
| HTML5 parsing algorithm, browsers only use XML mode if served
| the correct content type, and in XML mode they don't recover
| _at all_ from errors (when really, they should show an annoying
| popup and then switch to a quirks parser).
|
| We need to fix that, before XHTML can be viable. As-is, it's
| like it's being sabotaged.
| notpushkin wrote:
| > they don't recover at all from errors
|
| This is a recurring argument I see against XHTML.
| Fundamentally I don't see it as a downside (you don't expect
| the browser to run malformed JavaScript - why not HTML,
| too?). I agree there's a couple of possible obstacles,
| though:
|
| 1. It can be hard to produce 100% valid XHTML by hand - I
| personally run into errors from time to time. This is
| actually something an LSP could help with! All these errors
| can be detected at authoring time, given the proper tooling.
|
| 2. Naive template systems might produce invalid XHTML if
| you're not careful. Personally I haven't run into such
| situations, but some people say they do.
|
| This is also a tooling problem, but it's a bit trickier to
| tackle. A solution could be either (1) an LSP for the
| templating system, working together with the (X)HTML LSP, or
| (2) a templating system that is XML-native (but more
| ergonomic than XSLT haha).
|
| (Personally, I'm thinking about starting something like (2)
| with Jinja-like syntax, but I feel it's not something I have
| the time or energy for, at this point.)
|
| > when really, they should show an annoying popup and then
| switch to a quirks parser
|
| Not sure if it's a good solution long-term, but I see how
| that could help with adoption, so I'm all for it.
| wizzwizz4 wrote:
| > _you don't expect the browser to run malformed
| JavaScript_
|
| Refer to https://tc39.es/ecma262/2024/multipage/ecmascript-
| language-l... (extract below)
|
| ---
|
| In contrast, the source { 1 2 } 3
|
| is also not a valid ECMAScript sentence, but is transformed
| by automatic semicolon insertion into the following:
| { 1 ;2 ;} 3;
|
| which is a valid ECMAScript sentence.
| jancsika wrote:
| Interviewer: "So what's your professional opinion about
| this annoying popup that blocks the main thread?"
|
| Interviewee: "I see how that could help with adoption, at
| least until we are able to migrate to a red single-line
| error with a long-ass-scrollbar that displays instead of
| rendering any of the page at all."
|
| Interviewer: "Thanks. We'll be in touch."
| wruza wrote:
| Maybe web shops must stop producing malformed documents. No
| one else expects a corrupt pdf, xlsx, exe, jpg, etc to work.
| Ability to show incorrect documents. What an absurd
| requirement. If it's incorrect, fuken correct it man, or get
| a simpler job.
| alwillis wrote:
| I used to write XHTML and it took a while to lose the muscle
| memory.
|
| But I have no desire to go back.
| kristoff_it wrote:
| > Can we also go to XHTML5, while on it?
|
| Personally, I would like that, but in practice I don't think
| it's ever going to be a thing, so I didn't even bother adding
| support for it in SuperHTML, sorry!
| notpushkin wrote:
| Totally understandable, you do you! But I think the problem
| is, it's not yet a thing _because_ of the lack of tooling. It
| is kind of a chicken and egg situation here.
|
| Would you perhaps be open to a PR, maybe? (I would love to
| work on something like that, although I'm swamped right now
| and can't promise anything.)
| kristoff_it wrote:
| Yes, I'd be open to a PR, but I think the other comment on
| lack of browser support is the actual obstacle and really
| don't see that changing easily.
| jraph wrote:
| What's missing in browsers for XHTML5? Don't they
| understand and validate the XML and allow using the HTML5
| elements when some page is served with a
| application/xhtml+xml mimetype? Don't they, at worst,
| degrade to html5 parsing?
|
| (I only tried writing polyglot syntax, with only stuff
| allowed in both XHTML and HTML syntaxes)
|
| Or are you concerned with the unrecoverable mechanism?
| Am4TIfIsER0ppos wrote:
| I don't suppose there is a Vim version, is there?
| krig wrote:
| I'm using it in neovim right now. For vim, I guess you need a
| lsp plugin but it should work fine.
| kristoff_it wrote:
| SuperHTML can be used as a normal CLI tool, if you can
| integrate it with Vim to run it on save (and ideally parse the
| error trace), then you're all set.
| WhyNotHugo wrote:
| The tool is editor agnostic. You can use an existing Vim LSP
| client to use SuperHTML's LSP implementation. In theory this
| would work with things like ALE, it just needs to be
| integrated.
| ChrisArchitect wrote:
| Related from same creator, referenced in this article:
|
| _The Static Site Paradox_
|
| https://news.ycombinator.com/item?id=41775238
| TekMol wrote:
| the following snippet is correct HTML [...] will still
| be reported as an error by SuperHTML [...] it's most
| probably a typo
|
| Bad. A tool should do one thing and do it will. A tool to verify
| HTML should verify HTML. Not report errors where there are none.
| kristoff_it wrote:
| This is not a tool to verify HTML, it's a tool to support the
| act of handwriting HTML, and that's what it does :^)
| AlienRobot wrote:
| >This language server is stricter than the HTML spec whenever it
| would prevent potential human errors from being reported.
|
| It doesn't support implicitly closing <li>, <p>, <dd>, <dt>,
| <head>, <body> tags which is one of the best features of HTML if
| you're handwriting it. I assume it doesn't support implicitly
| opening <html>, <head>, and <body> either. Why do I have to skip
| indenting those levels when I can simply not open the tags?
|
| HTML is a terrible language and I'd rather write some strict
| superset of it that includes template tags to make it functional.
| If HTML features are treated as errors, that's not a superset.
| mediumsmart wrote:
| I write sites in html and the only thing I need js for is a nav
| overlay for the phone when they have a nav. And I adore my typos.
___________________________________________________________________
(page generated 2024-10-23 23:02 UTC)