Comment by inopinatus | Hacker News Reader

Comment by inopinatus | Hacker News Reader

This is a somewhat superficial list that omits discussing the fundamental idea behind CSS, viz. the semantic model; from which everything else is, directly or otherwise, a consequence.

Two decades ago I was overjoyed to discover that Scheme was finally going to have a useful application beyond illustrating SICP and writing koans to amuse myself, because DSSSL was on the cusp of evolving into the last document styling language anyone would ever need.

Unfortunately following an incident with a broken Lisp machine, a liquid lunch, and an unlicensed particle accelerator, I became trapped in a parallel universe where the HTML ERB anointed CSS by mistake during a drunken night out in Oslo.

The primordial concept of CSS (best revealed by H.W.Lie's thesis IMO[1]) was to create a rich and versatile and (crucially) non-Turing-complete set of structural selectors in lieu of DSSSL's recursive expressions, and to allow styles to overlay one another (the "cascade"); two design choices that only by the application of gallons of irony can explain why most web pages are composed of a bunch of nested DIV elements with hashed IDs and overloaded semantic class attributes, and everyone compiles their assets into a static file.

[1] https://www.wiumlie.no/2006/phd/css.pdf

Non-Turing-completeness is a plausible goal if and only if you enumerate and hold up all use cases against their realization for weighing idioms vs idiosyncrasies. However, if you just can't stop extending CSS' basic mechanism of property-value assertions with ever more layout model magic, exceptions, and microsyntax, then you get the clusterfuck that is CSS today, where any semblance of intent, locality, or other cognitive aid whatsoever is lost in the written code artifact.

Drunken or not, I can't also really fathom the primordial mindset of looking at HTML (eg. SGML's already heavy attribute and element syntax infrastructure), then come up with a completely redundant syntax out of nowhere for holding the exact same thing that went into attributes yet with weaker type checks.

The result is the write-only mess that is CSS today, unusable without CSS debuggers, inaccessible to most devs and traditional graphic designers let alone laymen, yet always insufficient for innovators, seemingly perpetuated only by folks who mistake their huge effort into learning CSS with its merit (aka Stockholm syndrome).

> The result is the write-only mess that is CSS today, unusable without CSS debuggers, inaccessible to most devs and traditional graphic designers let alone laymen, yet always insufficient for innovators, seemingly perpetuated only by folks who mistake their huge effort into learning CSS with its merit (aka Stockholm syndrome).

I dunno, much as I dislike CSS and its lack of useful modularity, it's never something I'd describe as "write-only" or "unusable". The selector syntax is fairly nice and concise and the cascade of properties works as one would expect (most of the time). I doubt CSS would benefit from throwing some SGML at it, because CSS is fundamentally just a list of selector-property pairs and not a mixed-content document.

The real problem with CSS is two-fold: first, the users of CSS have turned the class= attribute of HTML into an awful ad-hoc inline styling language (with the requisite awful and nightmarish stylesheets). And second, there is a huge amount of legacy cruft because it took 20 years of evolution for us to finally figure out a sane document layout model.

The non-Turing-completeness of CSS has a very very useful attribute: given a parsed stylesheet (a styling tree where selectors are nodes and properties are leaves) it is possible to annotate an HTML document with the correct style properties in a single forward pass without backtracking! That's because everything in CSS is done strictly in accordance with document order. It's not possible for an element to change the styling applied to any elements that precede it in the document.

I've clicked the first five google search results for "DSSSL" and not one of them dares to show an actual example of DSSSL code. I think that says enough.

I searched for "DSSSL example" and found this:

https://www.mulberrytech.com/dsssl/dsssldoc/cookbook/cookboo...

It, uh... does not make me pine for lost opportunities of DSSSL.

It seems like similar to folks wanting something like XSL (or is it XSLT?) for certain uses, but CSS seems fine for just styling.

There's XSL:FO which allows you to transform XML into PDF documents, and you would not want to be writing that every time you wanted to add some basic styling to a webpage:

https://en.wikipedia.org/wiki/XSL_Formatting_Objects

Well, it's a Lisp. Complaining about the syntax tends to suggest less about the Lisp than about the person complaining, viz. that they have not learned Lisp, or that they have and did not enjoy the experience.

By the same token, if we go searching for code in a 20-years-dead language and make wisecracks comparing some random sample, to something that's had many years of development since; irrespective of whether it is representative (and it isn't, particularly), this still doesn't say much about what might've been. As a more equal basis of comparison, I remember working with the CSS and HTML of twenty years ago, and this was invariably excruciating. The CSS we work with today is the result of two decades of polishing, and it's still mediocre, inconsistently implemented, and still riddled with issues and oh-for-heavens-sake-why-can't-it-just-do-X moments.

Back to the point, however; the canonical DSSSL application was DocBook, and we can still visit the much more lovely DSSSL source at its resting place in https://github.com/docbook/dsssl.

It's not so much the syntax as that I have never once thought that I wanted an imperative stateful language with variables and loops (!) for applying styles to the DOM, instead of a declarative one. And it seems like a disastrous idea to me.

And I haven't been thinking this for 20 years or something set in my ways, I was previously only vaguely aware of this "controversy". In fact, while you suggest the unfamiliarity or dislike of Lisp syntax is behind opposition, I think it's probably the reverse, most of the people (especially in 2020) pining over DSSSL are specifically those in love with Lisp who were hoping it would make it an again mainstream technology -- I'm going to reverse it and say your advocacy is less about the idea of using a full programming language for HTML styling and more about just liking Lisp and wanting an application for it.

But also, sure, syntax matters for technology accessibility. It is arguably inappropriate to require someone to "learn Lisp" in order to style HTML.

(I did learn and enjoy Scheme in undergrad CS curriculum long ago, I admittedly haven't used it since).

> less about the idea of using a full programming language for HTML styling

And yet, here I am in 2021 writing an execjs wrapper to compile Tailwind via Sprockets because of how much I've come to loathe Webpack.

> more about just liking Lisp and wanting an application for it

Well, yes, or rather more specifically Scheme, and I do believe that was my opening confession in the top level comment.

> It is arguably inappropriate to require someone to "learn Lisp" in order to style HTML

And it never should've been so, and it didn't need to be so with DSSSL either, because how much further might we have come in twenty years with an underlying language that wasn't basically hobbled out of the gate? Yet styling HTML with raw CSS is still programming, requiring knowledge of tree structures, a vast and ever-growing array of selectors and pseudo-classes and properties, recursion, priority ordering, an expression syntax not a million miles from S-expressions, the HTML DOM, four or five different box & layout models, and typography, not to mention all the browser quirks; oh, and - in practice, let's face it - Javascript; and yet 2 out of 3 major browsers still can't consistently size & center a top-level absolute block element, !important is the standard voodoo prayer for many, and fixing misbehaving CSS is basically debugging but in a language that lacks almost any first-class construct that might help.

So after all this further reflection, and notwithstanding that I've built up tons of valuable-in-practice crystallized experience in bending CSS to my will, I'm even more irked about the way things turned out.

> It is arguably inappropriate to require someone to "learn Lisp" in order to style HTML.

It's entirely appropriate to require people to learn something new, like a Lisp-based template language instead of HTML, if you're paying them to do a job.

Requiring people to learn stuff for a job is one way that shit languages proliferate; why deny that advantage to others?

Reply on news.ycombinator.com