10 ms·

The Languages Which Almost Became CSS

154 points by wyclif 6y ago

stickfigure 6y ago
I had to dig in the wayback machine for the "nonsensical infographic" dead link: https://web.archive.org/web/20120717123816/http://people.opera.com/howcome/2006/phd/i/fosi.png https://web.archive.org/web/20120717123816/http://people.ope...
perardi 6y ago
“As a final way of kindling your jealousy, DSSSL could treat inherited values as variables, and do math on them…” As per the article, this would have been a lot to implement back then, but sigh, what a wonderful world that wold have been.
- peatmoss 6y ago
  I keep wondering how I can Man-in-the-High-Castle my way back to the timeline where Scheme replaces HTML, Javascript, and CSS. Also where Al Gore wins the 2000 election.
  - ignoranceprior 6y ago
    Brendan Eich originally wanted Netscape's scripting language to be a Scheme dialect, but suits forced him to use Java/C-like syntax instead. https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_JavaScript https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_Java...
dmethvin 6y ago
> If CSS was designed the way it is just to satisfy the constraints of 1996, then maybe that gives us permission 20 years later to do things a little differently. Yeah, just like we can choose which side of the road to drive on or pick any arbitrary character encoding for an 8-bit byte.
- hansvm 6y ago
  Or in this day and age to even choose that a byte has 8 bits.
- lkrubner 6y ago
  Driving on one side of the road offers no obvious benefits compared to driving on the other side of the road whereas getting rid of HTML and CSS offers obvious benefits and is long overdue.
  - hombre_fatal 6y ago
    What are the obvious benefits? My experience is that people who tend to disparage web tech don't have much experience building clients in general, so they think building web clients is hard and annoying because it's the web without realizing it's because it's a client.
    - lkrubner 6y ago
      This is my argument: "My experience is that people who tend to disparage web tech don't have much experience building clients in general" My mom should be able to build great frontends for Web software, but currently the technology requires her to know much more than she knows. As you say, she "don't have much experience building clients in general." Therefore it's important that we get rid of HTML, CSS, and Javascript. This is an old debate, but to repeat the highlights: The benefit would be the productivity gained from specialization. The work could be moved away from computer programmers. Beginners would find beginning as easy as building a HyperCard stack, and specialist UI/UX experts (not computer programmers) could be put in charge of advanced frontends. The same argument that was made for Web Assembly also applies to the frontend: we now know what we need as a general compilation layer for frontend descriptive languages, things we did not know in 1996 when HTML/CSS/Javascript were coming together. The crucial thing is to have the kind of serialization formats that software can write, thus opening the door to a version of Dreamweaver that actually works. In other words, something like Adobe InDesign would then be the correct way to create all frontends. I wrote about this in detail here: http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html Earlier, in 2016, I wrote about the general problem, which offers some historical context "HTML is the failed GUI for TCP/IP" : http://www.smashcompany.com/technology/html-is-the-failed-gui-for-tcpip http://www.smashcompany.com/technology/html-is-the-failed-gu...
ignoranceprior 6y ago
> Particularly in the early days of the Internet, it was considered critically important that the page be renderable before the document has been fully loaded. In other words, we want to be able to render the beginning of the HTML to the page before the HTML which will form the bottom of the page has been fully downloaded. It's ironic that nowadays lots of sites completely ignore this guideline and force you to wait several seconds for webfonts/CSS/JS to load before the page is readable at all. We have much faster download speeds now, but this hasn't always translated into proportionately faster perceptual speeds. It's a shame if this is the reason DSSSL was rejected, because DSSSL looks more elegant than CSS other than this issue.
- austincheney 6y ago
  DSSSL reminds me of XML, which is not a bad thing, which makes sense since it evolved into XSL.
- perardi 6y ago
  Just decided to see how many scripts a popular website (CNN) loads. I count 36. And I'm running an ad blocker. Which seems a bit much.
- bestham 6y ago
  This is partly a problem with the design trends. There have been an aversion to have a “Flash Of Unstyled Content / Text” (FOUC / FOUT) in designs, especially since the time when image replacements went out of time and dynamic solutions like sIFR and similar techniques to style headers emerged. Now we have the same with web fonts, we prevent display until the right font I loaded. It’s very bad for UX.
RcouF1uZ4gsC 6y ago
> When HTML was announced by Tim Berners-Lee in 1991 there was no method of styling pages. How given HTML tags were rendered was determined by the browser, often with significant input from the user’s preferences. I almost wished we still lived in this world, where the web pages provides the structure and data, and I as the user get to decide how I want to consume it. I think trying to cram web applications into the same model as distributed, hyperlinked documents was fundamentally a mistake. If a browser was just about rendering html, a significant amount of complexity would have disappeared, and you would have a multitude of different browsers, all catering to different preferences in how you wanted to consume html. It is due in large part to the complexity, that we are going towards to monoculture of Chromium/Blink, because only companies with billions of cash in the bank, can afford to dedicate the teams needed to develop a web browser.
- nawgz 6y ago
  >If a browser was just about rendering html, a significant amount of complexity would have disappeared I don't think this is the right conclusion. I think HTML/rendering engines as described there would have been the thing to disappear. With the smooth user experience of apps & SPAs, a platform with comparable semantics to your nerfed HTML but significantly suped up interactivity features (like not-nerfed HTML) would be all the rage. Plus, I must say, as a web dev, the public-facing web doesn't really do great justice to what you can do with a browser. There's so many internal tools that are super slick, fast loading, bug-free, rendering complex topics like graphs & workflows in attractive yet interactive ways while also supporting client-side validations & computations, all delivered in HTML/CSS/JS. This really isn't a trivial accomplishment, this was driven by the work of many many engineers writing many different tools with increasing complexity, both on the browser and open source sides. The march of this progress wouldn't have stopped just because HTML didn't support it, it would've just replaced HTML.
  - kmeisthax 6y ago
    What you're describing existed. It was called plugins. Back in the Old DaysTM, browsers just rendered documents, and if you wanted whiz-bang interactivity features, you ponied up for a copy of Macromedia Flash. Or Director, if you wanted more features and could tolerate it's long plugin download times. Or, if you were more developer-minded, you wrote Java Applets (or, later on, Silverlight apps). Things like Flash didn't ultimately supplant the web, but this is primarily due to three forces: 1. Adobe's insistence on new Player features over security 2. Google's insistence on adding new features to HTML5 via Chrome to support internal business goals 3. Apple's insistence on killing plugins dead to keep the iPhone secure (and cut Adobe out of the developer tools market) The only vestige of plugins that remains are EME implementations (so-called "HTML5 DRM"), but that's purely due to legal reasons. Had HTML not grown to supplant the use cases of plugins, I think it would have stuck around, if only because all those plugins required significant expense to make use of. I doubt Adobe would have, say, tried to make a web browser in Flash just to cut the HTML middleman out.
Sniffnoy 6y ago
Anyone know when this article was written? I'm pretty sure I've read it before, but there's no date on it. Edit: Checking the Wayback machine, it seems to be from 2016.
- gwern 6y ago
  You might've read the mirror on the Cloudflare blog: https://blog.cloudflare.com/the-languages-which-almost-became-css/ https://blog.cloudflare.com/the-languages-which-almost-becam... (Not sure if it was updated.)
Animats 6y ago
The trouble with allowing a procedural language for styling is that all you can do with it is run it. PostScript and PDF work that way, which is why doing anything other than printing those formats,is very tough. Copying text from PDF barely works. It's an output-only format. I wanted a constraint-type system. A is above B, B is to the left of C, D is below A and B. Something like that. All declarative, handled by a constraint solver. Any serious parametric CAD system has that. Usually with more features than you need for web layout, like the ability to handle curves.
- kmeisthax 6y ago
  Funnily enough Apple's UI toolkits (both macOS's AppKit and iOS's UIKit) use Cassowary constraint solvers under the hood. There was also a startup a while back (The Grid, I think?) that was trying to use it as the basis of a web design platform. No clue if they ever shipped anything but I remember seeing their source release for the constraint solver and thinking, "Man, if calculating layout in JavaScript wasn't a total jankfest for end-users I'd totally use this".
  - Animats 6y ago
    That makes sense for GUI systems. If you have lots of elements with alignment constraints, a constraint solver is the right tool for the job. 20 years ago, they were obscure pieces of software, though, and rather alien to people who were thinking "word processor".
  - wruza 6y ago
    I guess you're talking about GSS, which works fine, but I haven't seen any mention of it on the internets until this. What bugs me most is that we're stuck with what browsers provide, and they not gonna do display: cassowary; or display: kiwi; no matter how loud you cry for something a little more sane than a bunch of css crutches glued together. I'd totally use this too. https://gss.github.io/ https://gss.github.io/ http://overconstrained.io/ http://overconstrained.io/
    - esprehn 6y ago
geoffmunn 6y ago
JavaScript style sheets were proposed by Netscape but didn't get any further adoption and were then dropped. These days it seems that CSS has evolved to support a lot of the features that JSS supported. https://en.wikipedia.org/wiki/JavaScript_Style_Sheets https://en.wikipedia.org/wiki/JavaScript_Style_Sheets
- masswerk 6y ago
  Some more examples (mind `contextual()` for combining selectors): https://www.masswerk.at/nowgobang/2019/object-handle-event#js-styles https://www.masswerk.at/nowgobang/2019/object-handle-event#j...
buss 6y ago
This was just so wonderfully written. It brought back a lot of memories. Kudos to the authors!
noizejoy 6y ago
Am I the only one, who finds it deeply ironic, that increasingly many modern websites are primarily designed for small screens, effectively giving up on designing for large screens? Presumably because designing for widely diverging screen sizes adds a ton of work. And the large screen is about to increasingly become just a surface for viewing multiple small screen apps simultaneously (e.g. iOS apps on MacOS). And arguably a lot of that could be done with rather plain HTML. Seems like the universe is indeed oscillating.
tannhaeuser 6y ago
Technically, there is a native SGML mechanism called link process declaration (without DSSSL) for assigning style properties to document markup. Looks as follows: <!DOCTYPE html [  ]> <!LINKTYPE render html #IMPLIED [ <!ATTLIST a color (blue|red) #IMPLIED> <!LINK #INITIAL a [ color=blue ]> ]> <html> <title>Blue link</title> <p>this <a href=x.html> link</a> is rendered in blue color</p> </html> Beyond this trivial example, style properties (link attributes) can be assigned in a context-dependent way for eg even/odd pages in print, or actually capture the largest part of CSS selectors (sans pseudo-attributes such as :hover though which are "magical" in CSS). I always wondered why people believed we need a distinct property universe for CSS properties when regular HTML attributes are there for this exact purpose (in link processes, attributes reuse regular content attribute declaration syntax).
notjustanymike 6y ago
I went to college for IT in 2000 and got to learn lots of this first hand. One important bit of history following was the introduction of Google Chrome. Up until then IE6 was making our lives quite difficult, and Chrome broke the MS inertia with it's standards support and silent updates in a way Firefox had been unable to achieve.
rurban 6y ago
Worked with DSSSL those times. It was perfect. Too good for the mess which was the web.

154 points by wyclif 6y ago

I had to dig in the wayback machine for the "nonsensical infographic" dead link: https://web.archive.org/web/20120717123816/http://people.opera.com/howcome/2006/phd/i/fosi.png https://web.archive.org/web/20120717123816/http://people.ope...

perardi 6y ago

“As a final way of kindling your jealousy, DSSSL could treat inherited values as variables, and do math on them…” As per the article, this would have been a lot to implement back then, but sigh, what a wonderful world that wold have been.

peatmoss 6y ago
I keep wondering how I can Man-in-the-High-Castle my way back to the timeline where Scheme replaces HTML, Javascript, and CSS. Also where Al Gore wins the 2000 election.
- ignoranceprior 6y ago
  Brendan Eich originally wanted Netscape's scripting language to be a Scheme dialect, but suits forced him to use Java/C-like syntax instead. https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_JavaScript https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_Java...

dmethvin 6y ago

> If CSS was designed the way it is just to satisfy the constraints of 1996, then maybe that gives us permission 20 years later to do things a little differently. Yeah, just like we can choose which side of the road to drive on or pick any arbitrary character encoding for an 8-bit byte.

hansvm 6y ago
Or in this day and age to even choose that a byte has 8 bits.
lkrubner 6y ago
Driving on one side of the road offers no obvious benefits compared to driving on the other side of the road whereas getting rid of HTML and CSS offers obvious benefits and is long overdue.
- hombre_fatal 6y ago
  What are the obvious benefits? My experience is that people who tend to disparage web tech don't have much experience building clients in general, so they think building web clients is hard and annoying because it's the web without realizing it's because it's a client.
  - lkrubner 6y ago
    This is my argument: "My experience is that people who tend to disparage web tech don't have much experience building clients in general" My mom should be able to build great frontends for Web software, but currently the technology requires her to know much more than she knows. As you say, she "don't have much experience building clients in general." Therefore it's important that we get rid of HTML, CSS, and Javascript. This is an old debate, but to repeat the highlights: The benefit would be the productivity gained from specialization. The work could be moved away from computer programmers. Beginners would find beginning as easy as building a HyperCard stack, and specialist UI/UX experts (not computer programmers) could be put in charge of advanced frontends. The same argument that was made for Web Assembly also applies to the frontend: we now know what we need as a general compilation layer for frontend descriptive languages, things we did not know in 1996 when HTML/CSS/Javascript were coming together. The crucial thing is to have the kind of serialization formats that software can write, thus opening the door to a version of Dreamweaver that actually works. In other words, something like Adobe InDesign would then be the correct way to create all frontends. I wrote about this in detail here: http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html Earlier, in 2016, I wrote about the general problem, which offers some historical context "HTML is the failed GUI for TCP/IP" : http://www.smashcompany.com/technology/html-is-the-failed-gui-for-tcpip http://www.smashcompany.com/technology/html-is-the-failed-gu...

ignoranceprior 6y ago

> Particularly in the early days of the Internet, it was considered critically important that the page be renderable before the document has been fully loaded. In other words, we want to be able to render the beginning of the HTML to the page before the HTML which will form the bottom of the page has been fully downloaded. It's ironic that nowadays lots of sites completely ignore this guideline and force you to wait several seconds for webfonts/CSS/JS to load before the page is readable at all. We have much faster download speeds now, but this hasn't always translated into proportionately faster perceptual speeds. It's a shame if this is the reason DSSSL was rejected, because DSSSL looks more elegant than CSS other than this issue.

austincheney 6y ago
DSSSL reminds me of XML, which is not a bad thing, which makes sense since it evolved into XSL.
perardi 6y ago
Just decided to see how many scripts a popular website (CNN) loads. I count 36. And I'm running an ad blocker. Which seems a bit much.
bestham 6y ago
This is partly a problem with the design trends. There have been an aversion to have a “Flash Of Unstyled Content / Text” (FOUC / FOUT) in designs, especially since the time when image replacements went out of time and dynamic solutions like sIFR and similar techniques to style headers emerged. Now we have the same with web fonts, we prevent display until the right font I loaded. It’s very bad for UX.

RcouF1uZ4gsC 6y ago

> When HTML was announced by Tim Berners-Lee in 1991 there was no method of styling pages. How given HTML tags were rendered was determined by the browser, often with significant input from the user’s preferences. I almost wished we still lived in this world, where the web pages provides the structure and data, and I as the user get to decide how I want to consume it. I think trying to cram web applications into the same model as distributed, hyperlinked documents was fundamentally a mistake. If a browser was just about rendering html, a significant amount of complexity would have disappeared, and you would have a multitude of different browsers, all catering to different preferences in how you wanted to consume html. It is due in large part to the complexity, that we are going towards to monoculture of Chromium/Blink, because only companies with billions of cash in the bank, can afford to dedicate the teams needed to develop a web browser.

nawgz 6y ago
>If a browser was just about rendering html, a significant amount of complexity would have disappeared I don't think this is the right conclusion. I think HTML/rendering engines as described there would have been the thing to disappear. With the smooth user experience of apps & SPAs, a platform with comparable semantics to your nerfed HTML but significantly suped up interactivity features (like not-nerfed HTML) would be all the rage. Plus, I must say, as a web dev, the public-facing web doesn't really do great justice to what you can do with a browser. There's so many internal tools that are super slick, fast loading, bug-free, rendering complex topics like graphs & workflows in attractive yet interactive ways while also supporting client-side validations & computations, all delivered in HTML/CSS/JS. This really isn't a trivial accomplishment, this was driven by the work of many many engineers writing many different tools with increasing complexity, both on the browser and open source sides. The march of this progress wouldn't have stopped just because HTML didn't support it, it would've just replaced HTML.
- kmeisthax 6y ago
  What you're describing existed. It was called plugins. Back in the Old DaysTM, browsers just rendered documents, and if you wanted whiz-bang interactivity features, you ponied up for a copy of Macromedia Flash. Or Director, if you wanted more features and could tolerate it's long plugin download times. Or, if you were more developer-minded, you wrote Java Applets (or, later on, Silverlight apps). Things like Flash didn't ultimately supplant the web, but this is primarily due to three forces: 1. Adobe's insistence on new Player features over security 2. Google's insistence on adding new features to HTML5 via Chrome to support internal business goals 3. Apple's insistence on killing plugins dead to keep the iPhone secure (and cut Adobe out of the developer tools market) The only vestige of plugins that remains are EME implementations (so-called "HTML5 DRM"), but that's purely due to legal reasons. Had HTML not grown to supplant the use cases of plugins, I think it would have stuck around, if only because all those plugins required significant expense to make use of. I doubt Adobe would have, say, tried to make a web browser in Flash just to cut the HTML middleman out.

Sniffnoy 6y ago

Anyone know when this article was written? I'm pretty sure I've read it before, but there's no date on it. Edit: Checking the Wayback machine, it seems to be from 2016.

gwern 6y ago
You might've read the mirror on the Cloudflare blog: https://blog.cloudflare.com/the-languages-which-almost-became-css/ https://blog.cloudflare.com/the-languages-which-almost-becam... (Not sure if it was updated.)

Animats 6y ago

The trouble with allowing a procedural language for styling is that all you can do with it is run it. PostScript and PDF work that way, which is why doing anything other than printing those formats,is very tough. Copying text from PDF barely works. It's an output-only format. I wanted a constraint-type system. A is above B, B is to the left of C, D is below A and B. Something like that. All declarative, handled by a constraint solver. Any serious parametric CAD system has that. Usually with more features than you need for web layout, like the ability to handle curves.

kmeisthax 6y ago
Funnily enough Apple's UI toolkits (both macOS's AppKit and iOS's UIKit) use Cassowary constraint solvers under the hood. There was also a startup a while back (The Grid, I think?) that was trying to use it as the basis of a web design platform. No clue if they ever shipped anything but I remember seeing their source release for the constraint solver and thinking, "Man, if calculating layout in JavaScript wasn't a total jankfest for end-users I'd totally use this".
- Animats 6y ago
  That makes sense for GUI systems. If you have lots of elements with alignment constraints, a constraint solver is the right tool for the job. 20 years ago, they were obscure pieces of software, though, and rather alien to people who were thinking "word processor".
- wruza 6y ago
  I guess you're talking about GSS, which works fine, but I haven't seen any mention of it on the internets until this. What bugs me most is that we're stuck with what browsers provide, and they not gonna do display: cassowary; or display: kiwi; no matter how loud you cry for something a little more sane than a bunch of css crutches glued together. I'd totally use this too. https://gss.github.io/ https://gss.github.io/ http://overconstrained.io/ http://overconstrained.io/
  - esprehn 6y ago

geoffmunn 6y ago

JavaScript style sheets were proposed by Netscape but didn't get any further adoption and were then dropped. These days it seems that CSS has evolved to support a lot of the features that JSS supported. https://en.wikipedia.org/wiki/JavaScript_Style_Sheets https://en.wikipedia.org/wiki/JavaScript_Style_Sheets

masswerk 6y ago
Some more examples (mind `contextual()` for combining selectors): https://www.masswerk.at/nowgobang/2019/object-handle-event#js-styles https://www.masswerk.at/nowgobang/2019/object-handle-event#j...

buss 6y ago

This was just so wonderfully written. It brought back a lot of memories. Kudos to the authors!

noizejoy 6y ago

Am I the only one, who finds it deeply ironic, that increasingly many modern websites are primarily designed for small screens, effectively giving up on designing for large screens? Presumably because designing for widely diverging screen sizes adds a ton of work. And the large screen is about to increasingly become just a surface for viewing multiple small screen apps simultaneously (e.g. iOS apps on MacOS). And arguably a lot of that could be done with rather plain HTML. Seems like the universe is indeed oscillating.

tannhaeuser 6y ago

Technically, there is a native SGML mechanism called link process declaration (without DSSSL) for assigning style properties to document markup. Looks as follows: <!DOCTYPE html [  ]> <!LINKTYPE render html #IMPLIED [ <!ATTLIST a color (blue|red) #IMPLIED> <!LINK #INITIAL a [ color=blue ]> ]> <html> <title>Blue link</title> <p>this <a href=x.html> link</a> is rendered in blue color</p> </html> Beyond this trivial example, style properties (link attributes) can be assigned in a context-dependent way for eg even/odd pages in print, or actually capture the largest part of CSS selectors (sans pseudo-attributes such as :hover though which are "magical" in CSS). I always wondered why people believed we need a distinct property universe for CSS properties when regular HTML attributes are there for this exact purpose (in link processes, attributes reuse regular content attribute declaration syntax).

notjustanymike 6y ago

I went to college for IT in 2000 and got to learn lots of this first hand. One important bit of history following was the introduction of Google Chrome. Up until then IE6 was making our lives quite difficult, and Chrome broke the MS inertia with it's standards support and silent updates in a way Firefox had been unable to achieve.

rurban 6y ago

Worked with DSSSL those times. It was perfect. Too good for the mess which was the web.