14 ms·

Languages Which Almost Became CSS

586 points by zackbloom 10y ago

koolba 10y ago
> 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.
Semiapies 10y ago
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 10y ago
  That's a good point, I'm working on adding something on that now. Edit: Done, should be live shortly!
  - Semiapies 10y ago
    Nice work!
- _greim_ 10y ago
  Ha, I'd totally forgotten about that! It seems like I remember Netscape 4 would actually convert CSS into JSS internally. It tried to comply to the standards but it always felt like the internal warts of the engine would poke through in myriad ways. Which was annoying because at Sun we had to make things work in Netscape 4 long after the rest of the world had moved onto IE6 and Mozilla.
Touche 10y ago
This is a fantastic lesson in history. I have nothing more to say than this is what I come to HN for.
throwanem 10y ago
Typo: > When HTML was announced by Tim Burners-Lee "Berners".
- zackbloom 10y ago
  Fixed, thanks!
  - colinramsay 10y ago
    While you're there: "fatal flaw which would plauge" -> plague Great article!
    - zackbloom 10y ago
      Got it, thanks!
dincer 10y ago
@fat's talk about this [42:07]: https://www.youtube.com/watch?v=iniwPUEbPUM https://www.youtube.com/watch?v=iniwPUEbPUM
freyfogle 10y ago
I've never understood why you need CSS, I just do it all in VRML
- zackbloom 10y ago
  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.html http://1997.webhistory.org/www.lists/www-talk.1993q1/0099.ht...
schmudde 10y ago
"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. /ü
- digi_owl 10y ago
  Quite. I strongly dislike sites that cram the article content into 1/3 of the screen, while the other 2/3 is taken up by ads and previews of "relevant" content. Reader mode may well be the best thing to come to Firefox in ages...
- zackbloom 10y ago
  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.
  - marssaxman 10y ago
    I suppose this explains why I've never really liked CSS or the design-heavy web: I was never willing to give up that control over my machine. I still resent the way modern "user-agents" aka browsers give every jackass designer out there more control over what my machine is doing than they retain for me.
Grue3 10y ago
DSSSL looks amazing. Truly a shame it didn't catch on. Maybe we'd have a client-side Lisp instead of Javascript too.
- agumonkey 10y ago
  When I die, my first question to god will be 'sir, why the hate on lisp?'. I expect the answer to involve testing of some kind.
  - marcosdumay 10y ago
    My take is that metaprogramming does not scale to teams. Or maybe it's just the historical artifact that everybody claims to be, and if the PDP-10 supported a lisp environment, things would be different. But if I had to bet, I'd bet on metaprogramming not scaling.
    - agumonkey 10y ago
      Possible that most people really like to have distinct level encoded as syntax.
    - mordocai 10y ago
      Ruby and Clojure are doing decently (though obviously not as popular as say C and Java) and have pretty advanced metaprogramming. For that matter C++ templates are metaprogramming from what I understand, and C macros are a really really primitive form of metaprogramming. Java also has reflection which is metaprogramming-ish. I don't think the problem was metaprogramming.
      - agumonkey 10y ago
        Not the same level of metaprogramming. Ruby Python try but it's less idiomatic or batshit crazy. C macros are glorified sed scripts, you're at the byte buffer level; it's cute but not good either. To me lisps sit at a nice middle ground where metalevels are as close as possible while still being usable. That's my take based on what people said in the 60s, after all sexps weren't supposed to be used.
intrasight 10y ago
And several years before that, there was Motif Toolkit.
frik 10y ago
> 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 10y ago
  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 10y ago
    Is the original source code that Tim Berners-Lee wrote available anywhere? I would think it would be an interesting read.
    - zackbloom 10y ago
      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."
Animats 10y ago
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.
- edvinbesic 10y ago
  There is always Grid Style Sheets[1] if you want to try it out. It is based on the same algorithms as iOS constraint engine[2] AFAIK. Unfortunately it has to compute the constraints using javascript as its not native. [1]: https://gridstylesheets.org/ https://gridstylesheets.org/ [2]: https://en.wikipedia.org/wiki/Cassowary_(software) https://en.wikipedia.org/wiki/Cassowary_(software)
  - Kinnard 10y ago
    WebAssembly should be able to help with that, no?
    - izym 10y ago
      I think so, yes. Personally I'm really looking forward to seeing what people are going to implement with WebAssembly. Another possibility would be virtual DOM diffing.
  - deleted 10y ago
    [deleted]
- 10y ago
ergothus 10y ago
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 10y ago
  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.
kowdermeister 10y ago
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.
martyalain 10y ago
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 10y ago
  https://xkcd.com/927/ https://xkcd.com/927/
  - unimpressive 10y ago
    And yet, if everybody followed this logic we would never get new standards.
zackbloom 10y ago
If anyone missed it, there's a discussion with Robert Raisch, the developer who made the first stylesheet proposal, in the article's comments.
paragraft 10y ago
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 10y ago
  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.
inopinatus 10y ago
Love the RELEVANCE selector in CHSS. Could use that today.
pablovidal85 10y ago
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 10y ago
  Jade comes somewhat close but opts for the offside rule rather than brackets and abbreviates class and id with . and # respectively.
  - pablovidal85 10y ago
    Exactly, I'm looking for one that uses brackets instead indentation and the rest is left untouched (no abbreviations or at least not mandatory). I can't find anything already done but at the same time is hard to believe is not done already.
  - jjcm 10y ago
    Just FYI, Jade has been renamed as Pug, for whatever reason. https://github.com/pugjs https://github.com/pugjs
    - montogeek 10y ago
      Legal reasons :)
- nbclark 10y ago
  It's kind of like HAML: http://haml.info/ http://haml.info/
  - pablovidal85 10y ago
    More like SASS, HAML introduces a lot of syntax and is indentation-based right?
FuturePromise 10y ago
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.
- Semiapies 10y ago
  Did a little of that, myself. A lot of the fundamental premise there did actually happen, just with different technologies. Today, there's a lot of sending structured data (in forms like JSON) to server- or client-side templates and components that render in a declarative way.
- Mikhail_Edoshin 10y ago
  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.
petetnt 10y ago
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/

586 points by zackbloom 10y ago

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

Semiapies 10y ago

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 10y ago
That's a good point, I'm working on adding something on that now. Edit: Done, should be live shortly!
- Semiapies 10y ago
  Nice work!
_greim_ 10y ago
Ha, I'd totally forgotten about that! It seems like I remember Netscape 4 would actually convert CSS into JSS internally. It tried to comply to the standards but it always felt like the internal warts of the engine would poke through in myriad ways. Which was annoying because at Sun we had to make things work in Netscape 4 long after the rest of the world had moved onto IE6 and Mozilla.

Touche 10y ago

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

throwanem 10y ago

Typo: > When HTML was announced by Tim Burners-Lee "Berners".

zackbloom 10y ago
Fixed, thanks!
- colinramsay 10y ago
  While you're there: "fatal flaw which would plauge" -> plague Great article!
  - zackbloom 10y ago
    Got it, thanks!

dincer 10y ago

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

freyfogle 10y ago

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

zackbloom 10y ago
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.html http://1997.webhistory.org/www.lists/www-talk.1993q1/0099.ht...

schmudde 10y ago

"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. /ü

digi_owl 10y ago
Quite. I strongly dislike sites that cram the article content into 1/3 of the screen, while the other 2/3 is taken up by ads and previews of "relevant" content. Reader mode may well be the best thing to come to Firefox in ages...
zackbloom 10y ago
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.
- marssaxman 10y ago
  I suppose this explains why I've never really liked CSS or the design-heavy web: I was never willing to give up that control over my machine. I still resent the way modern "user-agents" aka browsers give every jackass designer out there more control over what my machine is doing than they retain for me.

Grue3 10y ago

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

agumonkey 10y ago
When I die, my first question to god will be 'sir, why the hate on lisp?'. I expect the answer to involve testing of some kind.
- marcosdumay 10y ago
  My take is that metaprogramming does not scale to teams. Or maybe it's just the historical artifact that everybody claims to be, and if the PDP-10 supported a lisp environment, things would be different. But if I had to bet, I'd bet on metaprogramming not scaling.
  - agumonkey 10y ago
    Possible that most people really like to have distinct level encoded as syntax.
  - mordocai 10y ago
    Ruby and Clojure are doing decently (though obviously not as popular as say C and Java) and have pretty advanced metaprogramming. For that matter C++ templates are metaprogramming from what I understand, and C macros are a really really primitive form of metaprogramming. Java also has reflection which is metaprogramming-ish. I don't think the problem was metaprogramming.
    - agumonkey 10y ago
      Not the same level of metaprogramming. Ruby Python try but it's less idiomatic or batshit crazy. C macros are glorified sed scripts, you're at the byte buffer level; it's cute but not good either. To me lisps sit at a nice middle ground where metalevels are as close as possible while still being usable. That's my take based on what people said in the 60s, after all sexps weren't supposed to be used.

intrasight 10y ago

And several years before that, there was Motif Toolkit.

frik 10y ago

> 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 10y ago
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 10y ago
  Is the original source code that Tim Berners-Lee wrote available anywhere? I would think it would be an interesting read.
  - zackbloom 10y ago
    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."

Animats 10y ago

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.

edvinbesic 10y ago
There is always Grid Style Sheets[1] if you want to try it out. It is based on the same algorithms as iOS constraint engine[2] AFAIK. Unfortunately it has to compute the constraints using javascript as its not native. [1]: https://gridstylesheets.org/ https://gridstylesheets.org/ [2]: https://en.wikipedia.org/wiki/Cassowary_(software) https://en.wikipedia.org/wiki/Cassowary_(software)
- Kinnard 10y ago
  WebAssembly should be able to help with that, no?
  - izym 10y ago
    I think so, yes. Personally I'm really looking forward to seeing what people are going to implement with WebAssembly. Another possibility would be virtual DOM diffing.
- deleted 10y ago
  [deleted]
10y ago

ergothus 10y ago

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 10y ago
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.

kowdermeister 10y ago

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.

martyalain 10y ago

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 10y ago
https://xkcd.com/927/ https://xkcd.com/927/
- unimpressive 10y ago
  And yet, if everybody followed this logic we would never get new standards.

zackbloom 10y ago

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

paragraft 10y ago

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 10y ago
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.

inopinatus 10y ago

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

pablovidal85 10y ago

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 10y ago
Jade comes somewhat close but opts for the offside rule rather than brackets and abbreviates class and id with . and # respectively.
- pablovidal85 10y ago
  Exactly, I'm looking for one that uses brackets instead indentation and the rest is left untouched (no abbreviations or at least not mandatory). I can't find anything already done but at the same time is hard to believe is not done already.
- jjcm 10y ago
  Just FYI, Jade has been renamed as Pug, for whatever reason. https://github.com/pugjs https://github.com/pugjs
  - montogeek 10y ago
    Legal reasons :)
nbclark 10y ago
It's kind of like HAML: http://haml.info/ http://haml.info/
- pablovidal85 10y ago
  More like SASS, HAML introduces a lot of syntax and is indentation-based right?

FuturePromise 10y ago

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.

Semiapies 10y ago
Did a little of that, myself. A lot of the fundamental premise there did actually happen, just with different technologies. Today, there's a lot of sending structured data (in forms like JSON) to server- or client-side templates and components that render in a declarative way.
Mikhail_Edoshin 10y ago
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.

petetnt 10y ago

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/