6 ms·

Yes, but let's not pretend the trifecta of HTML, CSS, JS is perfect either, or spin a genesis myth of order and purposeful design around it. In theory, JS is fo

Yes, but let's not pretend the trifecta of HTML, CSS, JS is perfect either, or spin a genesis myth of order and purposeful design around it. In theory, JS is for interactivity, but in practice it's used for compensating the many, many shortcomings of HTML. For example, reveal menus used by many modern sites can't be implemented without JS (need to programmatically interrogate scroll position). Who's to say digital text has to stick to a 80s concept of casual academic publishing? Or take lazy loading (needs intersection observer), when the basic concept of assembling larger docs from pieces/text variables has been right there in SGML for over 30 years. The deal that made JS acceptable is that over time, as we learn more about digital text presentation, idioms pioneered using JS can be integrated/consolidated into HTML. Yet HTML is essentially stuck in the 90s or 80s. While CSS has gone nuclear and gained an unhealthy amount of syntax and layout concepts to compensate for it. The result is a media format that is simply unusable for creating acceptable results by a layman, and also doesn't capture essential structure of modern text (such as threads or bubbles of online discourse). Not that self-declared web "standardization bodies" care; web vocabulary activity has essentially stopped in 2017 when W3C published the final HTML spec and cancelled the SVG2 WG, and Mozilla stopped investing into core web tech. The only new proposals since were for example Google's "portal" element to aggregate third-party snippets.

mdpm 6y ago
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.
- mirkodrummer 6y ago
  > 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/ https://spacejam.com/ still renders fine like they did back then.
  - mdpm 6y ago
    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.
    - mirkodrummer 6y ago
      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
      - mirkodrummer 6y ago
        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"
      - mdpm 6y ago
        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.
    - mirkodrummer 6y ago
      You can't compare it to the pipe operator, you can still write xhtml valid documents in html5
qsort 6y ago
> 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.
- ghaff 6y ago
  >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.)
  - sbergot 6y ago
    If you need a responsive layout then PDF isn't really an option.
- wtetzner 6y ago
  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.
- falcolas 6y ago
  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.
CaptArmchair 6y ago
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.
swiley 6y ago
>reveal menus ... interrogating scroll position No one wants these.
- buzzerbetrayed 6y ago
  This simply isn’t true
  - falcolas 6y ago
    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.
    - tannhaeuser 6y ago
      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.
- wildrhythms 6y ago
  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.
rakoo 6y ago
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 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

mdpm 6y ago

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.

mirkodrummer 6y ago
> 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/ https://spacejam.com/ still renders fine like they did back then.
- mdpm 6y ago
  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.
  - mirkodrummer 6y ago
    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
    - mirkodrummer 6y ago
      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"
    - mdpm 6y ago
      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.
  - mirkodrummer 6y ago
    You can't compare it to the pipe operator, you can still write xhtml valid documents in html5

qsort 6y ago

> 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.

ghaff 6y ago
>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.)
- sbergot 6y ago
  If you need a responsive layout then PDF isn't really an option.
wtetzner 6y ago
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.
falcolas 6y ago
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.

CaptArmchair 6y ago

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.

swiley 6y ago

>reveal menus ... interrogating scroll position No one wants these.

buzzerbetrayed 6y ago
This simply isn’t true
- falcolas 6y ago
  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.
  - tannhaeuser 6y ago
    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.
wildrhythms 6y ago
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.

rakoo 6y ago

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 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