Live data from Hacker News

Forking HTML into a static language doesn't make sense

robert.ocallahan.org

31–40 of 94 posts

Re: Forking HTML into a static language doesn't make sense

#31

HTML doesn't need to be simplified to reign in the complexity. Rather, it needs to be completed as a hypertext, so that people can build complete software systems using (only or mostly) that language. See the htmx examples page for stuff that should be doable in plain HTML: https://htmx.org/examples/ The fact that only anchor and forms, only clicks and submits, only GET and POST and only full page replacement is avai…

That reminds me of XHTML2 https://en.wikipedia.org/wiki/XHTML#XHTML_2.0

Re: Forking HTML into a static language doesn't make sense

#32
post #23

From my perspective, the reason to have a language for static documents is parsability. With HTML5+CSS+JS, there are few organizations at the scale which can sustain making something like a web browser, a general-purpose web crawler, a11y tools, or similar. Could it be a common language? Perhaps. I liked HTML2. I hated basically everything which went into HTML3 and HTML4. HTML5 has made a lot of good progress on roll…

XHTML2. You just need XML parser for that.

Re: Forking HTML into a static language doesn't make sense

#33
I think there is a rather big divide between people like me who thinks the web should be "content-only" and people who see it as an application platform.

Most of what I do on the web resolves around reading things, not interacting in any meaningful way. Most of the web tries it's best to ruin that experience. Most of what I do online would be better served by gopher. I understand I am a part of a minuscule minority, but that doesn't stop me from whining.

Re: Forking HTML into a static language doesn't make sense

#34
I wonder if it would be practical to make a VPN-like service that acts like a middleman and handles all the JS code, forwarding only HTML, stylesheets and other static assets to the client using websockets. So something like a hover or click event would be sent to the server, which would run the javascript code and it would send back the resulting changes to the DOM which the browser can render.

Re: Forking HTML into a static language doesn't make sense

#36

Heck, go back to using WML. It would be interesting to build that browser again, the cards would work. https://en.wikipedia.org/wiki/Wireless_Markup_Language

I worked with some of very first mobile web sites. It was WML and Nokia 7110. While it seems rosy now, it was not that pleasant to work with. Pushing out any meaningful user interaction was painful. It was similar to remote control menus on TVs.

Plus it did not help that the entire device rebooted on a markup parsing errors and such bugs.

Re: Forking HTML into a static language doesn't make sense

#37

Earlier quoted context omitted.

The projects that SDOs decide to work on are those which people there are willing to spend their time on. An SDO could say "we're doing project X", but if nobody shows up…

Sure, but htmx is small (~1.7K loc[1]), written mostly by one guy part time and, while not perfect, advances HTML significantly as a hypermedia. That something like this hasn't been discussed in a significant, public manner by the w3c in over a decade[2] indicates to me there is either a lack of understanding or of interest in advancing HTML as a hypermedia. I readily admit I may be missing something. [1] - https://g…

Advancing HTML is indeed something that the w3c members aren't super interested in. There are a few reasons for this:

1) Changes to HTML can create security issues, especially if it results in a change to the HTML parser. You have to consider that non-browser use cases still need to be able to parse HTML correctly. Since we opted to make HTML versionless with it became harder to do.

2) Big changes are harder to get consensus on. This is one of the reasons why they opt to do smaller, less controversial changes.

3) w3c and whatwg are dominated by large corporations, who hire thousands of engineers to work on their web properties. They are able to overcome the shortcomings of HTML easier than small teams and single-developer websites.

I agree though, this is a major problem. HTML is essentially a dead language, no major changes have been made in almost a decade.

Re: Forking HTML into a static language doesn't make sense

#39

HTML doesn't need to be simplified to reign in the complexity. Rather, it needs to be completed as a hypertext, so that people can build complete software systems using (only or mostly) that language. See the htmx examples page for stuff that should be doable in plain HTML: https://htmx.org/examples/ The fact that only anchor and forms, only clicks and submits, only GET and POST and only full page replacement is avai…

I think this is an interesting and important argument, because I always felt many shortcomings of the modern web were actually caused by browser vendors and their reluctance to improve their platforms and the web. We have so many custom UI Elements, because forms did and still do suck. RSS always had a back seat, because it always was second class in browsers. Semantic web died outside of search engines, because brow…

Forms suck, but if you actually make a form, it becomes clear that while you can do 90% of stuff declaratively, there's a leftover 10% that just has to be described imperatively, which requires something like JS. Modern forms actually give you a lot for free with pattern matching and whatnot. I could imagine it going a little further and adding properties for "dirty" or not, which right now you have to add using JS onblur listeners. Probably, the standards bodies could add in credit card field types and input masking to get things 99% of the way there. But there's still left over things like: your display name should default to being your personal name plus your family name, but also overridable. I don't see how you can create a declarative language for relationships like that without stumbling into a Turing tarpit.

Re: Forking HTML into a static language doesn't make sense

#40
post #23

From my perspective, the reason to have a language for static documents is parsability. With HTML5+CSS+JS, there are few organizations at the scale which can sustain making something like a web browser, a general-purpose web crawler, a11y tools, or similar. Could it be a common language? Perhaps. I liked HTML2. I hated basically everything which went into HTML3 and HTML4. HTML5 has made a lot of good progress on roll…

XHTML2. You just need XML parser for that.

That's vastily oversimplifying things. XHTML2 was a markedly superior language to HTML in a few ways, but you still would have needed to have the same CSS & JS components to interact with an XHTML page.
Post reply on HN