
Languages Which Almost Became CSS - zackbloom
https://eager.io/blog/the-languages-which-almost-were-css/
======
Animats
Layout should have been constraint-oriented, not procedural. You should be
able to express "Bottom of this box is adjacent to top of that box", and such.
All those constraints go into a constraint engine, and a layout is generated.
This is something a WYSIWYG editor can generate.

To get a sense of how this could work, try sketch mode in Autodesk Inventor
(there's a free 30 day demo) You can specify that a point must be coincident
to an edge, that an edge must be coincident to an edge, that something must
have specified dimensions, that some dimension must have a numerical
relationship with another dimension, etc. Inventor goes further, supporting
constraints on diagonal lines, circles, arcs, ellipses, etc. Whether layout
should support curves is an interesting question, but the technology exists to
make that work.

The people who designed HTML5 and CSS thought procedurally, not geometrically.
It shows. Designers think geometrically, and a geometric constraint system
would make sense to designers.

~~~
mahyarm
Constraint layout systems are O(n^2) algorithms, while a procedural layout
algo can be O(1) or O(n). I think out of practicality it wasn't adopted. It
would be better if both were available, but such is life.

[http://floriankugler.com/2013/04/22/auto-layout-
performance-...](http://floriankugler.com/2013/04/22/auto-layout-performance-
on-ios/)

~~~
Animats
It's used for screen layout in MacOS Lion and Grid Style Sheets.[1] There's
also a subdomain that goes faster, and simple layouts should be in that
subdomain.

The idea is to get away from programmer-oriented layout input.

~~~
ryanbrunner
Right, but neither Lion or Grid Style Sheets were available in the early 90's.
It may have been possible to implement, sure, but we're talking early enough
in the web's history that the performance of the styling engine was a
legitimate concern.

~~~
shrugger2
Sure, but now we're past all that and people still come up with bullshit
reasons that CSS SHOULDN'T be replaced when there is every reason to believe
that we can do a better job now that we've suffered through 20 years of
learning.

------
frik
> Contrary to popular perception, Mosaic was not the first graphical browser.
> It was predated by ViolaWWW

Neither was ViolaWWW the first grahical browser.

In fact the very first browser by Sir Tim Berners-Lee was already a graphical
browser (even with WYSIWYG edit mode later known from Frontpage/Dreamweaver) -
made possible by thr advanced NeXTSTEP operating system and its window builder
IDE (nowadays known as OSX/macOS and XCode respectively):
[https://en.wikipedia.org/wiki/WorldWideWeb](https://en.wikipedia.org/wiki/WorldWideWeb)
and
[https://en.wikipedia.org/wiki/NeXTSTEP](https://en.wikipedia.org/wiki/NeXTSTEP)

~~~
Millennium
When people talk about "graphical Web browsers" in a historical context,
they're not just talking about browsers that run in a GUI. The term
specifically refers to browsers that can display graphics and text in the same
window. The earliest versions of WorldWideWeb (Tim Berners-Lee's original
browser) couldn't do this. It used NSText (NeXTStep's native text-display
object) for displaying pages, and at the time NSText didn't support inline
images, so WorldWideWeb relegated images to separate windows at the time. It
did eventually become a graphical browser in this regard, once NSText had the
necessary inline image support, but ViolaWWW beat it to the punch.

You don't hear much about graphical browsers anymore, not because they died
out but because they became such an overwhelming majority that it no longer
made much sense to make any distinction. But a few non-graphical browsers are
still in development; Lynx is probably the most famous of them.

~~~
Zelphyr
Is the original source code that Tim Berners-Lee wrote available anywhere? I
would think it would be an interesting read.

~~~
zackbloom
Yep!
[http://browsers.evolt.org/browsers/archive/worldwideweb/NeXT...](http://browsers.evolt.org/browsers/archive/worldwideweb/NeXT/)

Interestingly, some of the code "still resides on Tim Berners-Lee's NeXT
Computer in the CERN museum and has not been recovered due to the computer's
status as a historical artifact."

~~~
glitch
Also check out [https://www.w3.org/History/1991-WWW-
NeXT/Implementation/](https://www.w3.org/History/1991-WWW-
NeXT/Implementation/)

------
Grue3
DSSSL looks amazing. Truly a shame it didn't catch on. Maybe we'd have a
client-side Lisp instead of Javascript too.

~~~
peatmoss
Can we have a do-over on the web? I've seen (and even nominally participated)
in something of a resurgence of Gopher as something of a shadow web for
nostalgia-addled geeks. Gopher isn't an awesome protocol, but I love anything
that recaptures the spirit and decentralized nature of the old web.

At my curmudgeon-iest I like to imagine we carve off our own web where
S-expressions reign, there is no Google, and a million timecubes bloom.

~~~
girvo
When I was 6 years old, in 1996, my parents gave me a book about "Cyberspace"
to go along with our dial-up internet connection (on our Pentium 100mhz
Windows 95 computer!). This book showed me Gopher, and MUDs, and changed my
life! I wish I could remember the name of it, it was a bright yellow cover
with a superhero on it, I think.

I miss Gopher, in a rose-tinted glasses nostalgia-driven way

~~~
dTal
I'm pretty sure I had the same book! The "superhero" was called "CyberSarge",
yes?

[https://www.amazon.com/Internet-Kids-Ted-
Pedersen/dp/0600590...](https://www.amazon.com/Internet-Kids-Ted-
Pedersen/dp/0600590186/175-9303664-6802514?ie=UTF8&*Version*=1&*entries*=0)

~~~
girvo
YES!!!! That's the one! Holy crap, well done, I never thought I'd see it
again! Oh man what a nostalgia trip:

"GEEK: A geek is someone who is really excited by computers and proud of it"
\-- this is the reason I was proud to call myself a geek from 6yo onwards :)

------
Semiapies
There was also JavaScript Style Sheets:
[https://en.m.wikipedia.org/wiki/JavaScript_Style_Sheets](https://en.m.wikipedia.org/wiki/JavaScript_Style_Sheets)

~~~
zackbloom
That's a good point, I'm working on adding something on that now.

Edit: Done, should be live shortly!

~~~
Semiapies
Nice work!

------
schmudde
"HTML is the kind of thing that can only be loved by a computer scientist.
Yes, it expresses the underlying structure of a document, but documents are
more than just structured text databases; they have visual impact. HTML
totally eliminates any visual creativity that a document’s designer might
have. — Roy Smith, 1993"

Seems like an odd request in 1993. Sure, Prodigy had visual impact, but it was
pretty hard to read. HTML's starkness seems in part due to the fact that
styling options were limited by the technology and the ones that existed were
easily abused.

Writing long sentences as headers (<h1>) or all-caps (caps-lock) were styling
options at the time... and often misunderstood and abused.

/ü

~~~
zackbloom
You also have to think about who the audience was (Unix users) and what they
were used to (Gopher, irc, plaintext email). With all of those technologies
they were used to being in control of the styling of what they consumed. One
person's styles for irc could be completely different than another's, and that
was fine. The idea that things should be published with one rigid style which
must be used to consume it was foreign and not all that attractive.

You could make a case that the only reason any of this happened when it did
was because the browsers were reducing the amount of control the end users had
on the page styling. If Mosaic had been super configurable in it's styling,
it's possible it would have taken even longer for CSS to come about.

~~~
wtbob
What burns me up is that CSS was supposed to allow site authors to have
sensible defaults for their pages while enabling me to override them, and yet
when I set a dark theme in Firefox all hell breaks loose.

Honestly, the web was better end-user experience for me on links in a
terminal: I was able to read text and submit forms, and that's all I really
need.

~~~
unexistance
You can do that (of sort) in Firefox by

Preference | Content | Colors

* change the Text & Background colors

* uncheck system colors

* always override

~~~
wtbob
Yeah, but the problem is that modern pages are written in such a way that that
almost always displays garbage. I tried to do it for a few weeks, but it was
_terrible_ looking.

~~~
unexistance
I've set it up to follow Solarized dark color scheme.

Yes it'll take some time to get used BUT totally worth it, especially when
you're reading text a lot :D

I did test with light themes, I have to agree it looks worse compared to dark
themes

------
ergothus
As a web developer, I see two main issues with web styling:

First, the web was built around sharing technical papers. That means HTML
structure focuses on those elements that are relevant to papers (outline
layout via H* tags, tables of data, not much else), and not the sort of things
that marketing and sales want to push. (ads, rails/gutters, etc). Those of use
that suffered through the early "slice-and-dice" method of making web pages
are painfully aware of that. I'm a big fan of technical papers, and my
expectations of flash and glitz are minimal (I, for example, hate the modern
trend of not using the full width of my window.). Despite this, I feel we keep
trying to stay true to the origins of the Web rather than allowing for the
actual USE of the web.

Second, in an effort to keep the content machine-parseable as well as allow
for agents of different devices, CSS is applied separately from
content/structure (theoretically). Specifically, the concepts used DO NOT
MATCH the concepts used in developing desktop applications. Even Flexbox, the
most recent attempt to fix this, only loosely relates to the way desktop
applications would layout the content.

I'm a huge fan of the GOALS involved in HTML/CSS, but after working on web
stuff for over 20 years (not using CSS quite that long), I feel I can say it's
been a failure. We've spent that all or most of that time with painful
workarounds for basic tasks like: center content (particularly vertically!),
Adding a left rail/right rail, filling the height of a container, matching the
height of the visible window, making sure layered content is zindexed
properly, and those are just the ones off the top of my head. We've invented
and reinvented ways to do things like drop down menus, toggleable buttons,
modal windows. Heck, from the very start people implemented their own
authentication windows because the appearance and capabilities of the browser-
based solutions didn't match the demands.

After 20 years, and with the benefit of all the experience of desktop
development to add in, I feel like we shouldn't be fighting to manage such
basic requests, that we shouldn't be reimplementing field validation and error
messages YET AGAIN because even the latest advanced offerings just don't cut
it.

We should be able to have:

* "flexible" content (appearances adjusts to visible space)

* machine parseable content

* attractive UI

...without it requiring the dramatic hoop-jumping we have today.

~~~
talmand
How else would things go when people use a tool for which it was not designed
to do? It's an evolutionary thing. A need is identified, a feature addressing
the need is proposed. Then new needs are identified, new features are
proposed.

The problem wasn't in the tool, the problem was the tragic slowness in the
browser vendors implementing the features into the actual browsers. Don't
forget that for many of those 20 years we had competing standards of different
browsers doing their own thing. If the vendor didn't like a proposed feature
of CSS, it didn't get implemented. I wouldn't blame CSS for that.

Every complaint that I see about lack of features of CSS or how long it took
for the features we do have to get implemented I blame the browser vendors.

------
Touche
This is a fantastic lesson in history. I have nothing more to say than this is
what I come to HN for.

------
paragraft
What a great post. I really appreciate these longer digs into the past that go
behind the 'what' to explain the how & why of where we got where we are; and
just as much the futures that could have been and why they didn't happen. I
keep thinking there's room for a decent series discussing the evolution of
Rust, since that design process was such a public thing.

~~~
steveklabnik
I have a talk at the ACM's conference about the history of Rust, but with that
much time, there's only so much you can do. The RFC process has helped
document a lot, but there's still years of history before that.

------
freyfogle
I've never understood why you need CSS, I just do it all in VRML

~~~
zackbloom
The idea that 3D visualization was being considered in 1994 before CSS was
even released is absolutely fascinating, and a testament to how forward-
looking early Hypertext proponents were.

Skip down to Marc Andreessen's 'Future capabilities' for Mosaic:
[http://1997.webhistory.org/www.lists/www-
talk.1993q1/0099.ht...](http://1997.webhistory.org/www.lists/www-
talk.1993q1/0099.html)

------
dincer
@fat's talk about this [42:07]:
[https://www.youtube.com/watch?v=iniwPUEbPUM](https://www.youtube.com/watch?v=iniwPUEbPUM)

------
koolba
> It is pretty clear how this proposal was made in the era of document-based
> HTML pages, as there is no way compromise-based design would work in our
> app-oriented world. Nevertheless, it did include the fundamental idea that
> stylesheets should cascade. In other words, it should be possible for
> multiple stylesheets to be applied to the same page.

> It its original formulation, this idea was generally considered important
> because it gave the end user control over what they saw.

Content (i.e. ad) blockers are a logical extension of this.

------
martyalain
Writing pages in a web site is a mess, polluted by different syntaxes, HTML,
CSS, Javascript, jQuery things, MarkDown, ... It's a miracle that Wikipedia
exists! Several works have been done to bring some unity, for instance Skribe,
Scribble, LAML, SXML, but they generally lead to complex systems devoted to
coders and forgetting web designers and, of course, beginners.

The {lambda way} project is built as a thin overlay on top of any modern web
browser, and devoted to writing, composing and coding on the web, where the
markup, styling and scripting are unified in a single language, {lambda talk}.

Commenting this work, somebody wrote this: « Reminds me of John McCarthy's
lament at the W3C's choice of SGML as the basis for HTML: "An environment
where the markup, styling and scripting is all s-expression based would be
nice." »

The project can be seen here:
[http://epsilonwiki.free.fr/lambdaway/](http://epsilonwiki.free.fr/lambdaway/)
or in [https://github.com/amarty66](https://github.com/amarty66).

Do you think that {lambda way} is on the good way?

~~~
majewsky
[https://xkcd.com/927/](https://xkcd.com/927/)

~~~
unimpressive
And yet, if everybody followed this logic we would never get new standards.

------
kowdermeister
To me, PSL looks the most promising, at least the conditionals would have come
handy. CSS only 'recently' got features like the CALC() function which is a
blessing.

However I have to agree with the decision to put it aside, because remember
how implementing something seemingly simple as CSS went in the days if IE5,6.
It was a disaster and something more complex like PSL would have been even
worse.

------
pablovidal85
I'd like to see CSS-shaped HTML like this:

    
    
      doctype html
      html {
        head {
          title Hello there
          script type='text/javascript' src='main.js'
        }
        body {
          p class='one two' {
            span Sample text
          }
        }
      }
    

Is there an HTML preprocessor using a similar language?

~~~
K-Wall
Jade comes somewhat close but opts for the offside rule rather than brackets
and abbreviates class and id with . and # respectively.

~~~
jjcm
Just FYI, Jade has been renamed as Pug, for whatever reason.
[https://github.com/pugjs](https://github.com/pugjs)

~~~
montogeek
Legal reasons :)

------
throwanem
Typo:

> When HTML was announced by Tim Burners-Lee

"Berners".

~~~
zackbloom
Fixed, thanks!

~~~
colinramsay
While you're there:

"fatal flaw which would plauge" -> plague

Great article!

~~~
zackbloom
Got it, thanks!

------
petetnt
I love how Bert Bos' homepage pretty much uses CSS to the fullest extent
possible (as it should)
[https://www.w3.org/People/Bos/](https://www.w3.org/People/Bos/)

------
zackbloom
If anyone missed it, there's a discussion with Robert Raisch, the developer
who made the first stylesheet proposal, in the article's comments.

------
intrasight
And several years before that, there was Motif Toolkit.

------
inopinatus
Love the RELEVANCE selector in CHSS. Could use that today.

------
FuturePromise
I spent a long time learning XSL/XSLT. The theory was we'd represent the data
on a web page with XML, and then determine how it's to be displayed with
XSL/XSLT. I think browsers still support it, but it never caught on.

~~~
Mikhail_Edoshin
Which is very sad, because it's a totally sane way. Have a set of different
low-level languages to describe a screen layout, a paper layout, a audio
layout for the blind, a single high-level language that describes content, and
three transformations written in a very powerful yet pretty much declarative
language. What not to like?

For example, sometimes we may need to enumerate certain things, e.g. headings.
Normally this is a part of the final typesetting package (LaTeX or MS Word,
whatever). But with XSLT and XSL/FO we have a different share of
responsibilities: XSLT computes the numbers and XSL/FO typesets what it's
given, so it has one less thing to worry about. This is great, because
typesetting is complex enough already.

Besides, XSLT way of creating styles (xsl:attribute-set) is one of most
elegant I've seen. It's very simple (one element and one attribute) and very
powerful at the same time: you can easily inherit styles and/or use mixins or
combine these approaches and there's no ambiguity. Besides, it's generic.

