
Languages Which Almost Became CSS - zackbloom
https://blog.cloudflare.com/the-languages-which-almost-became-css/?f
======
tarikjn
I started doing web development around 1999 or a bit earlier, NotePad.exe was
my first text editor. By 2003 I was building websites in strict XHTML and CSS,
and always avoided using presentation markup, OpenWeb.eu.org was one of my
favorite resources, along with W3C specs.

Most developers I knew in person didn't care about CSS or didn't 'get' it.
Things have come a long way since, in term of browser compatibility and
tooling, but it always feels like a large portion of people who do web dev
don't 'get' the web, for example, I am always surprised at the usage of
frameworks such as Bootstrap in tech teams, you're basically redefining what
you want your elements to look like using a combination of class names, which
means you lose style separation and selectors. It's like a circle repeating
itself.

People will always want to use the web to build their 'visual' or 'app' to
look like they want to just as if they are designing a business card, but the
web at its core is a web of knowledge, for it to be linked by other pages,
browsed by bots, and is worth little without traffic or way to catalog that
knowledge in the grand scheme of things. And that's why a bunch of people like
me have always been pushing to have a semantic definition of the knowledge in
your document, separate, and to be considered before its presentation.

Now we can make rich apps, and get pretty much pixel exact renders, but all
the underlying philosophy remains: accessibility, context, semantics, and
still should come before the styling in order of priority, and all the bells
and whistles should ideally be implemented as an augmentation of the
semantics.

~~~
lkrubner
> it always feels like a large portion of people who do web dev don't 'get'
> the web

My history is surprisingly similar to yours, I started in 1999, I used Notepad
as my first text editor, and by 2003 I got caught up in the movement towards
making markup strict, which I felt was the mark of professionalism. However,
by 2006 I had mostly rejected the notion of "strictness". There were several
things that turned me against strictness. One of them was Mark Pilgrim's essay
"XML on the Web Has Failed":

[https://www.xml.com/pub/a/2004/07/21/dive.html](https://www.xml.com/pub/a/2004/07/21/dive.html)

Another problem was brought up by Sam Ruby: his daughter sent him an image,
which he wanted to share on MySpace, but he couldn't. And the reason he
couldn't was because the image was in a SVG format which required strict XML,
and MySpace was, of course, very far from anything "strict".

Some people looked at the chaos of non-standard HTML and decided the Web was
successful because it had been broken from the beginning, and it had learned
to work well while broken. I reached a different conclusion. It became clear
to me that what developers wanted to do simply had nothing to do with
HTTP/HTML.

We don't yet have the technology to do what developers want to do. HTML was an
interesting experiment, but it suffered from a dual mandate. Sir Tim Berners
Lee wanted HTML to both structure data and also present it in graphical form.
Almost from the start, developers were conflicted about which mandate they
should obey, but the preference, since at least 1993, if not earlier, was to
give priority to the visual. For all practical purposes, developers saw
HTTP/HTML as GUI for IP/TCP. Previous IP/TCP technologies (email, gopher, ftp)
had lacked a visual component, but HTML finally offered a standard way to send
things over Internet and format the end result visually (emphasis on
"standard"; I could insert an aside here about X window systems and some cool
software of that era, but every app implemented their own ideas about visual
presentation. X-Emacs, for instance, had its own system for visual formatting
over a network).

That we now have so many versions of languages that compile back to
Javascript, which renders HTML, shows that there is a great hunger for
something that moves beyond HTTP/HTML.

The quote that Mark Pilgrim used at the beginning of his article is worth
repeating:

"There must have been a moment, at the beginning, where we could have said ...
no. Somehow we missed it. Well, we'll know better next time." "Until then ..."
\-- Rosencrantz and Guildenstern are Dead

He may have meant that ironically (since Rosencrantz and Guildenstern are
murdered) but I like to think that we will eventually get rid of HTTP/HTML and
replace it with what developers actually want: a pure GUI for IP/TCP, a
technology with a single mandate, with no burden of also offering semantics or
structure or hierarchy.

~~~
pjc50
> a pure GUI for IP/TCP

What does that actually _mean_? There are all kinds of systems which use a TCP
link to produce a display on one end, with all kinds of different design
compromises, _made for different reasons and use cases_.

If people had, by some miracle, standardised the web as a graphical format
back in the early 90s by dictating that screens had to be 4:3 format with a
particular minimum resolution, what would have happened to smartphones?

~~~
WorldMaker
That brought back memories of trying to use AOL in the wrong screen
resolution.

------
tannhaeuser
The LISPers here around will miss DSSSL for sure ...

Me, I can't get over the point that CSS introduced a whole new syntax for
item/values when HTML/SGML attributes were _exactly_ designed for
presentational properties. The idea/dogma that content goes into HTML and
presentation into CSS, with completely separate syntax, didn't make any more
sense back then as it does now:

> _" Well, you get to learn this language to write your document, and then you
> get to learn that language for actually making your document look like you
> want it to."_

~~~
tarikjn
I am not sure I understand your point, how do you expect to be able to apply a
style across multiple elements in a HTML document using attributes of existing
elements?

Nevertheless you'd have to define selectors or use classes, even XPATH had to
come along for XML.

Then you would also have to define property names and value. And you pretty
much invented CSS. To apply it by classification, it has to be declared
independent from your document tree, then you might as well separate it.

~~~
saghm
From the example of FOSI in the article, it looks like the SGML elements
aren't directly contained within the elements they style but refer them them
from attributes (gi="h1", gi="h2", etc.), which is actually more similar in
functionality to having external CSS stylesheets than inline CSS (which is
what I think you're referring to).

~~~
tannhaeuser
FWIW, SGML also has LINKTYPEs (in addition to DOCTYPEs) for declaring
presentation properties using normal attribute declaration syntax. A LINKTYPE
can contain a state automaton assigning link attribute values to content
elements and for transitioning to other states, but, unlike CSS, doesn't use
regular patterns. This system makes sense for print, where a standard task is
to assign different horizontal margins on even and odd pages. Using SGML LINK,
this can be implemented by declaring two states transitioning to one another
over page elements. A regular expression pattern language like CSS, OTOH,
can't express the necesssary logic, hence CSS has a large number of extra
predicates.

~~~
Sharlin
Well, if CSS actually supported full regular expressions in selectors,
even/odd wouldn't need custom predicates.

~~~
tannhaeuser
Yes, but only if grouping of subexpressions or non-terminals in grammar
productions are allowed (they aren't in CSS).

To elaborate, the problem at hand is to assign different properties to the
even and odd elements, resp., of a sequence using just the sequence,
alternation, and Kleene star operators in two rules. For example, the rules
for the first few items (a _s_ ) are as follows:

    
    
        even -> a a | a a a a | ..
        odd  -> a | a a a | ..
    

A solution using grouping of subexpressions/non-terminal symbols in grammar
rules:

    
    
        even -> ( a a )*
        odd  -> even a

~~~
marcosdumay
That's a full logic language (like prolog) for selecting things. It's very
easy to mess up a prolog program and destroy its performance, so it's not a
good thing to have on a web standard.

Maybe something more functional instead of logic would be better.

~~~
zmonx
For comparison, it's also quite easy to mess up the performance of a
JavaScript program, and yet it's part of a web standard. My recommendation in
cases of poor performance is to improve Prolog systems by features that yield
better performance. Examples: better virtual machines, JIT indexing, tabling,
constraints, goal reordering as in Mercury etc., all of which are now becoming
part of modern Prolog systems.

Important advantages of logic programs over functional ones is that logic
programs are typically shorter and more general, and ideally well suited for
describing domain-specific knowledge (such as styles and layouts)
declaratively. Prolog is already part of the semantic web to considerable
extent, albeit disguised as RDF and complex query languages with a different
syntax than Prolog. It could have been Prolog all along, and some members of
the committees have suggested that in fact.

~~~
tannhaeuser
Fun to hear from another Prolog fan here. Like you, I came back to Prolog from
SPARQL/OWL2, and share your opinion. My upcoming SGML system (sgmljs.net) will
also feature a full ISO Prolog engine for querying over document metadata
(there's even a "tolog" Prolog profile for this, which at one point was
considered to become an ISO standard [1]).

Do you know of Prolog systems for layout computation of CSS or other layout
languages? I "know" Prince/PrinceXML (Mercury-based) and the begin of a formal
specification for CSS as logic/attribute grammar [2] (from 2009).

[1]:
[http://www.ontopia.net/section.jsp?id=specifications](http://www.ontopia.net/section.jsp?id=specifications)

[2]:
[https://lmeyerov.github.io/projects/pbrowser/pubfiles/extend...](https://lmeyerov.github.io/projects/pbrowser/pubfiles/extended.pdf)

~~~
zmonx
Awesome work and links! For dynamic layout generation with Prolog, I recommend
you start with the PhD thesis of Joost Geurts:

[https://pure.tue.nl/ws/files/2135764/200613391.pdf](https://pure.tue.nl/ws/files/2135764/200613391.pdf)

Joost uses Prolog CLP(FD) constraints and other declarative language features
for reasoning about multimedia data.

See also the following paper:

[https://espace.library.uq.edu.au/view/UQ:7851](https://espace.library.uq.edu.au/view/UQ:7851)

However, I must correct one misconception: I did not "come back from
SPARQL/OWL2" to Prolog. Rather, when the whole RDF/SPARQL hype started, I
could only hope that in due time, this will all stop again and turn back to
Prolog, which now, years later, is slowly happening. Prolog FTW! It's a great
language for formal specifications and declarative descriptions of all kinds
of data, including layouts. I hope your project becomes a great success. ISO
compliance is definitely a great benefit and will help adoption in large
organizations considerably.

------
Fifer82
To be honest, I still find CSS a mess. I really dislike it. I feel like JS and
HTML are pretty solid, then you have this CSS hacky shit with no decent docs
and I just didn't get it.

Recently I wanted to use Material Components, and the whole BEM thing makes my
eyes cry.

`custom-on-dark .mdc-icon-toggle.mdc-ripple-upgraded::before`

`custom-on-dark .mdc-icon-toggle.mdc-ripple-upgraded::after`

`mdc-toolbar__section mdc-toolbar__section--align-start`

I just am not going to work with that in my code and it screams to me
something is wrong.

~~~
girishso
I particularly liked the way tachyons does styling, in contrast to this.
([http://tachyons.io/](http://tachyons.io/))

".ba" to add border all or ".bt" for border top... then just add ".b--dashed"
for dashed border... ".georgia" will use Georgia font... ".red" will color it
red.

Though class names they used can be more uniform IMO.

~~~
plopz
Whats the benefit of tachyons over just writing inline styles?

~~~
losvedir
The author discusses it a bit here: [https://github.com/tachyons-
css/tachyons/issues/12](https://github.com/tachyons-css/tachyons/issues/12)

The key points from there, regarding your question specifically: 1) inline
styles can't use media queries, while there are tachyon classes for different
devices. 2) Ditto for pseudo classes. 3) The browser renders them faster.

But I think your _actual_ question was something more along the lines of
"isn't styling individual elements considered bad practice?" That has a bigger
answer and is more philosophical. I, too, recoil at it, but I'm open to best
practices changing or being considered differently in the context of web
applications vs web pages.

For example, react and JSX changed my mind about mixing JS and markup and even
styling to some extent.

~~~
SippinLean
>I, too, recoil at it

But you're recommending this? This has advantages over inline styles, but
doesn't avoid the main drawback of using them: difficulty to maintain and
change.

------
otto_ortega
I love CSS, I wonder why it is not an universal standard used to define GUIs
in other contexts like native mobile apps, or desktop apps.

Why did Android creators decided to define its own way to describe GUIs, when
CSS existed and could be used for that purpose?

Every time I have tried to create a decent GUI for the desktop I get
disappointed by the insane difficulty of the task, as with CSS you can make
something look good in a few minutes.

~~~
zackbloom
Perhaps not surprisingly there's a just as large cohort of people who love how
GUIs are defined in desktop and mobile applications and despise CSS. I've seen
someone go so far as to redefine the entire browser rendering system, drawing
every button and control onto one big HTML canvas element.

They're very different ways of building a UI, and it's hard to find people
with a ton of experience in both to provide perspective, much less an answer
as to which is 'better'.

------
kelvich
DSSSL is actually not that dead. Postgres documentation was built with use of
DSSSL until 2017.
[https://github.com/postgres/postgres/blob/REL9_6_STABLE/doc/...](https://github.com/postgres/postgres/blob/REL9_6_STABLE/doc/src/sgml/stylesheet.dsl)

~~~
smitherfield
Sounds kinda dead then.

------
zbraniecki
I strongly believe that we're currently in the early stage of the same cycle
with localization formats.

The most popular ones, like gettext, xliff, .properties are very limited,
while the most sophisticated one - MessageFormat - is stopping a few steps
short of having all needed capabilities and is very hard to read/write by
hand.

I'm very excited for the next 3-5 years where I believe we'll see more
development in this field and hopefully we'll end up with a good equivalent of
CSS for Web Localization.

Full disclosure: I work on a project that my team believes to be a good
contender for that - Project Fluent (
[http://projectfluent.io/](http://projectfluent.io/) ) I also work within TC39
on ECMA402 on APIs that will make coming up with new localization APIs much
easier (PluralRules API, language negotiation and selection etc.).

~~~
seanwilson
> I strongly believe that we're currently in the early stage of the same cycle
> with localization formats.

I was looking into this recently and I'm amazed how many different but very
similar formats there are. For example, Django uses gettext, JavaScript has
several different JSON formats (e.g. i18next, polyglot) and Go has its own
JSON/TOML/YAML format. Each format seems so similar I don't understand why
they didn't use an existing one. Usually you want your translators to use a
web interface to edit translations so different formats make this troublesome.

------
ue_
I am very interested in the s-expression stylesheet format. I think it would
be preferable for me at least to CSS, especially the code for alternating
rows; I imagine that people write programs in this language might have well
done away with the need for CSS preprocessors that we have today. This also
makes me ask a question - why are there no Lisp-like CSS preprocessors?

I am reminded of the proposal to markup webpages with s-expressions rather
than XML, though there are packages available (actually just macros) in CL
that let you write websites this awy.

~~~
pcwalton
Be careful what you wish for. The fact that CSS can be so easily declaratively
analyzed is the reason why it can be made reasonably fast at all. CSS has some
key restrictions—for instance, that attributes always inherit top-down and
never bottom-up—that makes it amenable to parallelism (which is no longer a
theoretical concern, as parallel CSS implementations are starting to ship).
Adding a full programming language would have the potential to make styling
much slower than it already is.

~~~
littlestymaar
> as parallel CSS implementations are

Is someone else outside mozilla ready to ship a parallel CSS engine any time
soon ?

~~~
pcwalton
Not that I'm aware of.

------
ajarmst
"Rather than using repeated selectors to handle the nesting, PWP used a
parenthesis system which is evocative of the indentation systems used by
languages like Stylus and SASS which are preferred by some developers to CSS
today.." Heh. So, do nested parentheses remind you of any other languages?

------
k__
I kinda dig the current CSS in JSX hype.

I think I never have been that fast building UIs.

I get the convenience of writing inline-styles like HTML attributes and not a
style string and in the background it gets compiled to CSS classes, with
deduplication and everything.

Since Flexbox and CSS-Grid, most CSS frameworks I used in the past also don't
have much value for me anymore.

------
13of40
I'm sure there's an article out there about "languages that almost became
html". Anyone have a link to it?

~~~
jccalhoun
This is not quite what you want but The History of the Web is a newsletter
that does stories on various topics. Here's the site with archives:
[http://thehistoryoftheweb.com/](http://thehistoryoftheweb.com/)

------
gattilorenz
> It also includes one of the best nonsensical infographics to ever exist on
> the web

While technically flowcharts could be defined infographics in the
broad/original sense, I still don't see why this is so nonsensical. It is
obviously targeted to someone who knows the subject and terminology involved,
but apart from that it looks OK to me.

/nitpick

------
limeblack
Surprised it didn't talk about how the box models worked orginally. IE 5 did
the box model differently including margin and padding in the width. Made CSS
very difficult to use.

~~~
freshyill
It was wrong, and required stupid workarounds, but it was better.

I hated those old IEs as much as anybody, but I admitted even back then that
IE's broken box model was much saner. We had to do stupid things with widths
and percentages just to make the browsers that worked _correctly_ work.

The fact that everybody uses box-model: border-box now is pretty much an
admission that the original box model was a bad idea.

~~~
wwweston
Agree with everything... except the idea that IE was wrong in this case. I
hated Microsoft as much as anybody during the overlong era of IE6, but even
back then, I had to admit that the W3C were the ones who got the box model
wrong.

The funny thing is that I've never heard _any_ rationale -- much less a
convincing rationale -- for the choice in the spec.

~~~
freshyill
Well only wrong in that they weren't following the W3C box model spec. That
single inconsistency was responsible for at least 50% of the extra work caused
by IE.

------
65827
Unfortunately the idea that you would just restyle the content a bit as needed
and viola website is redesigned never really worked. At any point in history.
I just wish you could get through a redesign without learning three new
languages nowadays.

~~~
adrianratnapala
Yes in my experience, we got the worst of both worlds.

We have people with a religion of separating style from content, so they
introduce the complexities necessary to do that. But because it is merely a
religion, they don't actually do it in a way that makes it possible to
actually change styling just through CSS.

~~~
tannhaeuser
Yes, and what's particularly irrational is that CSS found it necessary to
invent a new key/value syntax. Then developers wanted to make sense of the
mess by declaring "markup is for content, while CSS is for presentation". But
the "separation of concerns" argument is merely an after-the-fact
justification for the existence of the HTML/CSS separation. In the original
markup language concept, attributes were _specifically_ introduced to hold
presentation attributes, while content was encoded as element content.

The content/presentation dichotomy doesn't hold water in a philosophical sense
either. Many text pieces (such as poems, but also modern text forms) require
special presentation. But what was particularly absurd is to invent a new
_syntax_ for key/values.

------
cwmma
If you want more information, somebody wrote a PhD thesis on this very topic
[http://wiumlie.no/2006/phd/](http://wiumlie.no/2006/phd/)

------
bhaak
Minor nitpick: "As you may know, HTML as we know it was originally based on a
pre-Internet language called SGML."

It's "pre-world-wide-web". The internet was already alive and quite busy in
the 80s.

------
amelius
I wonder if any of the alternative languages, in contrast to CSS in the
beginning, _did_ provide a simple way to center content along the x and y
axes.

~~~
xxs
We did use <table> for this... nested tables, over nested tables; although
they were somewhat buggy in netscape 4

~~~
amelius
Yes, that's why I explicitly said "simple" :)

------
odammit
If CHSS with its percentage ownership had become CSS desk flipping would have
been invented way earlier.

