
The Languages Which Almost Became CSS - wyclif
https://eager.io/blog/the-languages-which-almost-were-css/
======
Animats
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
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".

~~~
wruza
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
The Houdini Layout API is specifically designed to allow adding things like
display: cassowary and display: kiwi

[https://houdini.glitch.me/layout](https://houdini.glitch.me/layout)

There's much discussion within browser makers about making it so you're not
stuck with only what they provide.

~~~
madeofpalk
I was going to say exactly this - Houdini is a set of APIs that exposes the
(CSS) layout engine to you in CSS to do all sorts of custom funky things.

~~~
wruza
Oh, that looks so promising that just glancing over that page and seeing a
request/allocate cycle felt like a breath of fresh air (well, good old fresh).
Thanks for sharing!

------
stickfigure
I had to dig in the wayback machine for the "nonsensical infographic" dead
link:

[https://web.archive.org/web/20120717123816/http://people.ope...](https://web.archive.org/web/20120717123816/http://people.opera.com/howcome/2006/phd/i/fosi.png)

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

~~~
cmrdporcupine
The way things were in the early days is if you wanted rich interactivity you
used Flash, or a Java applet. The rather standard and boring 'web page' still
hosted it, but the rich features were to be provided by the applet/plugin.

This was both worse and better. Better because it retained the notion of the
web as a hypertext system -- not a networked magazine or TV -- worse because
what happened in that (usually poorly implemented) little box was its own
world outside of the rest of the page.

I don't like the present web stack, but I don't have any particular fondness
for the mid-90s one I worked on, either.

~~~
nawgz
To be honest, I perceive the main problems with the present web stack to not
be on the consuming developer's end - writing JSX & CSS is honestly a pretty
decent representation of what HTML/CSS/JS can actually combine to be. Plus
modern JS is a half-decent language, even more so when TypeScript is used.

I perceive the main problem to be how hard it is on the implementing
developer's side - only megacorps can make functional web browsers. That's a
huge problem.

------
tannhaeuser
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 [
          <!-- ... declarations
               for HTML elements, 
               attributes ... -->
        ]>
        <!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).

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

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

------
geoffmunn
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
Some more examples (mind `contextual()` for combining selectors):

[https://www.masswerk.at/nowgobang/2019/object-handle-
event#j...](https://www.masswerk.at/nowgobang/2019/object-handle-event#js-
styles)

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

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

~~~
cookiengineer
Everybody talks about replacing CSS, yet nobody comes up with a feasible
solution.

Layouting is hard. Very hard.

I mean, there's a reason why ooxml or docx are so similar to CSS, and why PDF
is so broken that it's a candy store for exploits.

Both object and functional oriented replacements always have led to a lot of
redundancy compared to their compiled CSS equivalents. And usually you cannot
model layouts as flexible as with CSS' different flow models.

Everybody that says CSS can be replaced with something simple usually hasn't
even thought of print stylesheets, media queries, or why the box model and
flow model got so complicated.

The spec authors had very good reasons to make changes to the CSS spec(s).

~~~
googlryas
Maybe instead of having stylesheets for print and media queries, different
versions are just written for each?

I've wondered this about a11y in HTML too. Instead of trying to torment the
browser into understanding how a11y should work with a bunch of ARIA
properties, what if a simple alternative was offered which was easier to
understand for a11y but not for 'normal' users?

~~~
zeven7
Those suggestions would probably be better if everyone building a website had
infinite man power. But in the real world adoption is going to suffer if you
have to make a separate document for web, print, a11y, etc. Then someone will
say "Why don't we have a unified markup language that we can use to produce
each of these documents for us?" And then XSLT will be invented. And what a
mess we've made.

~~~
googlryas
But if people are already putting in extra effort to get these features
working in their unified markup language, then it isn't different (from the
perspective of effort) to write separate versions. In fact, it might be
easier, because at that point you're working in a language custom designed for
the task at hand, not trying to shoe horn a spoken-word UI into a visual UI
language.

------
perardi
“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
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
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_Java...](https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_JavaScript)

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

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

------
Sniffnoy
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
You might've read the mirror on the Cloudflare blog:
[https://blog.cloudflare.com/the-languages-which-almost-
becam...](https://blog.cloudflare.com/the-languages-which-almost-became-css/)
(Not sure if it was updated.)

------
notjustanymike
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
Worked with DSSSL those times. It was perfect. Too good for the mess which was
the web.

