Hacker News Reader

HTML was for providing declarative markup. CSS was for styling that on a user-agent. JS was for enhancing the capabilities of the user-agent in the context of the markup.

We then tried to make what was basically gopher++ into an app framework. Then we wanted all user-agents to behave the same, wanted pixel perfection. This meant we didn't empower user-agents to make their own presentation decisions.

Glad you refer to SGML, I thought XHTML was amazing at the time too, then HTML5 broke compatibility with everything. JSON has been inferior in every way, but XML and attendant standards had also blossomed into fractal complexity. Ever try XSL-FO?

Everyone can roll a wheel, and imagine a vehicle, but not everyone can build a car, at least not without engaging with some complexity. We need better tools for the middle ground, but need to avoid building new layers of abstraction that pretend the complexity isn't there.

> HTML5 broke compatibility with everything How? It's backward compatible, it's the first spec that tells the browsers how they should handle errors and introduced new semantics. Semantics that gracefully degrade in non html5 browsers, I find this thing simply wonderful. It's for this same reason sites like https://spacejam.com/ still renders fine like they did back then.

HTML5 is no longer XHTML compliant. There were a suite of tools that worked with markup that weren't browsers. This allowed the web to be the input, output, and middle of other chains of tools. It was sort of like removing '|' from the CLI.

I still don't get it, HTML5 lets you write your documents in XHTMLish way. The spec doesn't care, you just decide. And tools should still work as expected

And BWT it was xhtml to broke backward compatibility "XHTML is not compatible with the IE8 and other older versions of the browsers. HTML5 is capable of using XHTML style tags but not vice versa. While writing code in XHTML, there are several restrictions that the developers need to adhere to"

HTML5 documents are not XML; this means that tooling that isn't a browser, or isn't 'HTML aware' became excluded. The web 'special cased' itself at this point, and HTML and common data processing pipelines of the time parted ways, this is my only point.

You can't compare it to the pipe operator, you can still write xhtml valid documents in html5

But most of HTML5 documents aren't written like that, which is the problem.

> Glad you refer to SGML, I thought XHTML was amazing at the time too, then HTML5 broke compatibility with everything.

HTML5 was explicitly designed for backward-compat with the large body of HTML4 (and earlier) content out there. And HTML5 can still be parsed using SGML, which as a superset of XML is every bit as powerful as XML, yet also has tag inference, attribute shortforms, and other minimization features dropped from the XML subset of SGML that are necessary for HTML, though. So there's no reason to be bitter about XML's demise on the web; I've even written a tutorial for XML workflows involving HTML integration or output using SGML [1].

[1]: http://sgmljs.net/docs/sgml-html-tutorial.html

> XML and attendant standards had also blossomed into fractal complexity.

Fully agree. It appears that once XML was out there, people wanted to apply it to each and everything. When markup is really only useful for semistructured text. In that department, you actually might find SGML much more useful, since not only can it deal with HTML, it can also parse markdown or other custom syntax (even JSON and s-exprs!), has built-in styling and transformation facilities capturing core CSS, and much more powerful templating and transclusion/fragment reuse mechanisms for actual text authoring and processing.

Interesting. Makes me wonder if even YAML could be brought to heel ...

There was a moment in the web's history where we were trying to figure out how to make XML, HTML, RSS, and 'microformats' all play well together. Next to that were a million authors of WordPress themes who thought 'semantics' was academic rubbish, and just wanted to make the web into another word processor. We got OWL, RDF triples, and no-one paid attention, and just carried on farming complexity.

The cries for simplification are more the result of the tooling, build chains, etc., in my mind than the core tech of HTML, CSS, JS. I'm just concerned that we redouble the complexity by inventing new abstractions to wrap the old.

> The result is a media format that is simply unusable for creating acceptable results by a layman

Not that I disagree, the web is a mess, but to be really fair, is there any media format, like at all, that can be used by a layman to achieve reasonable results? The only one I can think of is latex, and that requires taking a very generous definition of 'layman'.

The real problem I'm seeing here is that the web was designed as a document presentation media when what everyone really wanted from the get go was an application platform, and we're forever stuck in this contradiction because frankly every other platform has entirely disjoint but at least equally grievous issues.

>is there any media format, like at all, that can be used by a layman to achieve reasonable results?

I'd argue a WYSIWYG that outputs PDF. But that's probably shifting not only the goal post but the playing field. (It does get at whether the creator should have full control of display or not debate though.)

If you need a responsive layout then PDF isn't really an option.

Maybe I'm looking at the past with rose-tinted glasses, but I think Hypercard was something that could be used by a layman to create good results.

Sure. Plain old HTML worked just fine for dozens of years, for a vast majority of text-based and mixed text/image media content.

But it wasn't precise enough for the designers, or dynamic enough for the developers, or closed down enough for the media conglomerates and ad companies.

I mostly agree with you, HTML is stuck in the mindset of the era it was created in, to represent static documents that are created once and are not supposed to ever change.

This is why I feel projects like htmx (https://htmx.org/docs/#introduction) can really be what HTML should be in the 21st century: a container for dynamic data fully driven by the server. It's all made possible with javascript of course, but the idea is to not write a single line of it of course.

There are so many things that would make the web a better platform, instead of every single website reimplementing: proper authentication and account management, proper payment for a better monetization, proper separation of application and data, ... instead it's gone deep down into the valley of extreme graphical customization to the point it's now impossible to create a browser from scratch that can respect all the specs

>reveal menus ... interrogating scroll position

No one wants these.

This simply isn’t true

Then perhaps it's better to say that the overwhelming majority of end users don't want those (or wouldn't care if they disappeared tomorrow).

I'm sure designers love 'em.

I'm as much of an old-school markup geek as it gets, but still there are website visitors expecting to scroll unto the bottom to see "all there is" on a site. You may say this behavior is learned from doom scrolling, reminicent to taboola crap, etc., but who I am to judge? Personally, I find the development of content UIs and new idioms fascinating.

Just to be sure, when I've written about reveal menus and scroll position above, I didn't mean capturing/blocking scroll events or otherwise messing with default browser behavior.

Well... not you, or me. Unfortunately, I can find a dozen UX designers and project managers who do, in fact, want these things, and advocate and whip developers to add these things under the pretense of "cohesion" and "brand intuition" and other such terms that lead to someone (not me) being promoted.

This debate is really about what people want and how they envision the Web.

> Who's to say digital text has to stick to a 80s concept of casual academic publishing?

Hypertext is a valid business case as it was back then and it still is today.

What changed is how the Web evolved from a small group of academics and engineers 30 years ago into the billions that it connects today. It's not just hypertext. It's hypertext and every other conceivable business case which is being shoehorned into the browser.

The Web originally wasn't conceived to provide affordances that allow for "rich media experiences". Foundational technologies - HTTP, HTML, CSS, JS,... - weren't originally designed to build complex user interfaces and applications. Yet, as more and more and more people got connected: that's exactly what they wanted.

Remember Flash? Or Java applets? Or Silverlight? Those were hailed as additional technologies that would merge complex user interfaces into the Web. Macromedia coined the term "Rich Web Applications" back in 2002. All of them failed for various reasons.

Ever since the Web Standards moving of the mid-00's, communities of designers have taken CSS and HTML and tried to bend and use them in any way possible to bring visually stunning experiences on the Web. This is where you will find the direct roots of many ideas and dynamics that are currently in vogue. It's their influence, as well as other dynamics - e.g. the introduction of the smartphone, the rise of big tech - that has defined how browser technology has evolved.

Over the past decade, browser vendors have tacked on additional browser API's on top of the original, decade old foundations, while communities of frontend developers have spawned ever intricate constellations of interlocking JavaScript libraries and frameworks that specifically try to break out of how the Web originally was intended to work.

Some things have become easier as specifications evolved a bit (e.g. CSS3). But at the end of the day, your browser still needs to download HTML, JS and CSS, parse all of that, execute and render it onto a canvas.

Even so, it's safe to say that this approach is miles removed from what native applications offer in terms of performance and maintainability. Markets being what they are, web applications are in vogue because they earn big money if done well. (Slack just became the latest poster child for that, right?) I don't see that changing anytime soon either, lest someone is willing to go back to the original drawing board and design a totally new paradigm that integrates the promise of Rich Web Applications in the browser properly.

And so, I think it's hyperbole when someone states that "HTML, CSS and JS are broken". One may also consider the history of Web technology over the past decade as a great example of how the popularity of a set of technologies turned them into Maslow's Golden Hammer. Used to solve any and all problems under the sun, but still not any closer to what native applications aspired to achieve back in the 80's, 90's and 00's.

"Even so, it's safe to say that this approach is miles removed from what native applications offer in terms of performance and maintainability. Markets being what they are, web applications are in vogue because they earn big money if done well."

Disagree. I really do love the speed of native apps, but there's a very good reason the web has become the way most software is delivered. Web apps cost less to build, distribute and maintain for both publisher and user. Web apps are often, but not always, easier to install (just type a url in the browser, press enter, done), easier to learn, more interactive, and more likely to run on the device you own. Native apps are a load of work for both the publisher and user, and that is just to get the app installed and running.

Maybe the current web isn't what was envisioned. I'm ok with that.

Well, you make good points. I don't disagree with you.

I'm weary of drawing the discussion towards pitting web apps against native apps in absolute or general terms. I think that would detract things too far from reality.

It's a complex debate because the 'right fit' - native or web app - depends on the use case or business case as well as the perspective of the stakeholders involved: developers, business owners, customers and users. The many trade off's each and every stakeholder has to make are what sparks tensions and debate.

Speed is just one of those.

It's true that web applications have set a new bar as far as customer / user convenience as well as application maintenance are concerned. But then there are also trade off's regarding privacy, confidentiality, security, legal compliance, accountability, trust, expenses,... There's also reliability / availability of a services, and there's even a moral question regarding energy consumption tied to operating data centers.

Again, I'm not going to take position on those in absolute terms. Rather, I think it's very much valid to look at your own business case or use cases and keep taking native applications into consideration as well, rather then dismissing them outright as yesteryear's technology.

> Maybe the current web isn't what was envisioned. I'm ok with that.

Oh, I'm okay with that as well.

It's interesting to see you use the phrase "current Web" because what is the "current Web" exactly? In the vast majority of discussions, it tends to be reduced to the well known big tech companies and their products. For many the "current Web" is mainly Reddit, HN, StackOverflow, LinkedIn, Medium,... For others, the "current Web" might be a plethora of self-hosted websites which they have bookmarked in text documents. Your mileage really varies depending on who you ask.

The Web is far larger then the perception we get from it through our own daily use. And a vast amount of it will remain dark simply because we either can't find it, or because we aren't aware it exists, or because we simply don't look for it's existence.