And not having variables in CSS is more harmful than having them. In the form of a dozen preprocessors and alternative CSS languages that compile to CSS.
I think he's wrong here: requiring that folks preprocess some CSS-variant-with-constants into CSS-without-constants just multiplies the number of entities (by however many CSS variants are then introduced). CSS's lack of constants is a glaring design error.
If we want to reduce the total number of entities, then we should examine unifying HTML, CSS & scripting. As I've indicated elsewhere, I think that something like this would be awesome:
;; adapted from https://www.w3schools.com/howto/howto_css_modals.asp
(html
(head
(title "modal-box-example")
(style
;; The Modal (background)
(.modal
;; Hidden by default
(display none)
;; Stay in place
(position fixed)
;; Sit on top
(z-index 1)
(left 0)
(top 0)
;; Full width
(width "100%")
;; Full height
(height "100%")
;; Enable scroll if needed
(overflow: auto)
;; Fallback color
(background-color (rgb 0 0 0))
;; Black w/ opacity
(background-color (rgba 0 0 0 0.4)))
;; Modal Content/Box
(.modal-content
(background-color #x"fefefe")
;; 15% from the top and centered
(margin "15%" auto)
(padding 20px)
(border 1px solid #x"888")
;; Could be more or less, depending on screen size
(width "80%"))
;; The Close Button
(.close
(color #aaa)
(float right)
(font-size 28px)
(font-weight bold))
((.close:hover .close:focus)
(color black)
(text-decoration none)
(cursor pointer)))
(script
(with-elements-by-id
((modal "myModal") (btn "myBtn")) document
(let ((span (aref (get-elements-by-class-name document "close") 0)))
(setf (on-click btn) (lambda () (setf (display (style modal)) "block"))
(on-click span) (lambda () (setf (display (style modal)) "none"))
(on-click window) (lambda (event)
(declare (ignorable event))
(setf (display (style modal)) "none")))))))
(body
;; Trigger/Open The Modal
((button id "myBtn") "Open Modal")
;; The Modal
((div id "myModal" class "modal")
;; Modal content
((div class "modal-content")
((span class "close") ×)
(p "Some text in the Modal..")))))
The syntax itself may be a big deal. With a unified syntax like the above LISP-like example, you can meta-program all content, structure and style with the same scripts, and manipulate them inside the same generic tools.
This could be used to reduce the number of entities in the system, in special those for logic expressions and control flow.
I especially dislike this type of pairing because it makes it an explicit requirement for the content and presentation to be together. I prefer content to be separate from styling, as intended by CSS, simply because we can't predict what the future will bring. Content will always remain content when it's semantic but presentation can and will change as time goes on.
Content and presentation both change, and together. That's how it's always been for every type of media. How much space you have on the newspaper determines what your article's title is, but what the title is also determines how much space you have.
No they don't. I can write a paper or a thesis without any worry about how it's going to look visually to the person consuming it. I can post a video of something without any kind of concern for what size, container, or surrounding content might accompany it.
Content is content. Presentation is how that content is displayed. While they can work together, the content is the most important thing and presentation should always be secondary to it.
Sure. I was just commenting on the fact that I've seen this type of setup everywhere lately and the content and presentation are inextricably linked. To me, that's a major problem.
I shudder at the thought of this syntax being used for anything longer than that example. “)))))))” everywhere. Not sure why you would want your css to not be declarative
The author says that a constant lookup table is extra implementation complexity while also saying it's simple and something every programmer should have done as an educational exercise. Considering the density of browser specifications, talking about symbolic constants as feature bloat is some serious windmill-tilting.
They then say that named constants make code harder to understand -- which is obviously an opinion, but one that goes against almost all standard practice. The benefits of naming constants and avoiding magic numbers are well documented, I think. Yes people can go overboard with this, but the solution isn't to not have named constants as an option at all.
The kicker I think is the sheer popularity of CSS preprocessors. When people are compiling to something you designed as an end-user interface, you've failed.
The problem with CSS variables isn't the concept, its that --this-syntax is ugly and unreadable af (admittedly bikeshedding here).
> When people are compiling to something you designed as an end-user interface, you've failed.
CSS is a good end-user interface for many things without variables.
And people will use preprocessors for CSS no matter how many features it will have because of many reasons including "ugly and unreadable" syntax.
It's better to leave CSS and HTML as simple primitive bytecode for web UI with powerful compilers instead of developing epic w3 specs leading to numerous bugs in browser implementations.
The arguments would seem more powerful if the author was aware of today’s preprocessing stack. I expanded references to “constants” to mean any additional language features, and it was a better argument, but I have no problem with improving CSS usability with nesting and variables. If it had those I wouldn’t use SCSS at all, just autoprefixer. It’s probably harder to write a buggy implementation of them than a correct one.
> It's better to leave CSS and HTML as simple primitive bytecode for web UI with powerful compilers instead of developing epic w3 specs leading to numerous bugs in browser implementations.
Haven't we pretty much already crossed that bridge? I recall quite a few bugs in CSS specs.
I'd take most arguments in this with a grain of salt, as it predates much of the progress that CSS (and things like Sass/Less/PostCSS) have made over the past decade.
> On the other hand, CSS style sheets are short. They are not much bigger than one editor window. Very few people (only professional designers, it seems) write style sheets longer than a hundred lines.
Even for 2008 this is just wrong. Very few people write any kind of CSS at all. But those who do surely write more.
I've been hand rolling CSS for pretty much every site I've built since 2001. I can't think of a single site with more than a few hundred lines. Most of the time I use a reset which adds more, but the actual site specific stuff has always been relatively small. Anecdata… mumble, mumble.
With respect to the premise of the article: I appreciate having variables because it allows more specificity about what a color or unit is supposed to mean in a given context, which I find valuable.
I get that this article is 10 years old now but I like the principle of it, to a certain extent. My biggest gripe with some of the newer usage of CSS (including BEM and SMACSS) is that it loses the separation of concerns that is supposed to make HTML/CSS modular. The intent of the web was for content and we're getting farther and farther away from that to the point where now even CSS can cause bit-rot. People are using CSS for everything as tightly-packaged modules that look great when the CSS is loaded correctly but that don't really function without the CSS/HTML as explicitly paired. I know that's what some people want now but I can't help but feel like this is contributing to the mess.
That being said, variables are useful. I have no problem using variables in a CSS preprocessor and don't really care one way or the other whether it's included in the CSS spec.
The HTML/CSS/JS split is great ideologically, but have you looked at the source code of any web app lately? It’s a jumble of all 3, with modern frameworks like react encouraging you to work with the whole, injecting things as needed here and there.
I remember learning CSS in the early 2000s, with the book showing how one could have separate stylesheets for on screen display vs printing. You’d think this approach would have aged nicely, now that websites need to render on a large variety of screen densities/sizes/aspect ratios/etc. Well no, now we have huge bloated CSS files full of media queries and weird things that are impossible to make sense of unless you’ve spent a few weeks in the codebase.
So yes, nice in theory but completely outdated in practice given the horrible Beast DOM has become.
Perhaps that approach was too idealistic all along, and only sort of worked in the beginning, when the web was really basic and most people were on a 1024x768 display. The form is the function and also the medium and the message, and it’s impossible to place abstract boundaries on where the content vs presentation vs interaction lie.
I work with rails basically every day, and your experience does not match mine. In the codebases I've worked with, almost all of them are cleanly and clearly separated. HTML is in one directory, css and js in another. It's true react has a... different approach, but it's certainly not the only way to do it.
"separations of concerns" is not about putting things in different folders or files.
It is about those things not being entangled as spaghetti with each other.
Reacts Philosophy is that everybody's css/js/html is tightly coupled and therefor using different languages with different semantics and scoping rules increase the cognitive complexity without providing any advantage.
Can I break your app by just touching the CSS? Does any cosmetic change at any point require that I touch the html? Can I write a new style sheet for your app without knowing the JS or HTML? Can I plug in a new style sheet of one application into another? Can people work on the JS/HTML/CSS separately and independently?
Putting your spaghetti in separate folders doesn't make it less spaghetti.
And the market knows it's tightly coupled spaghetti for everyone. Thats why you don't see different job adverts for your three different folders.
The goal was to have a world where the designer would know CSS but zero JavaScript and zero HTML. This goal has completely failed.
I think web apps are a little unique because there's huge parts of them that are not content and that's where the separation of concerns originally came to be. I vehemently disagree with you that all of these things have to be entangled and tightly coupled. I think they just end up that way because it's the easy way to get through a problem and people who do things like that are, generally, lazy or on a tight deadline (for no reason that to have a deadline) or stressed or any number of things. Unfortunately, if all you're given is noodles, sauce, and meatballs, you're probably going to make spaghetti.
I don't mean to simplify your argument so much but is it essentially "well, some web apps don't follow that ideology so no one should"? I work regularly with codebases that have definite separations of concerns. Granted, I don't use react much.
I think that semantic design/development is hard and that's why people end up with jumbled messes of things. Commenting code is hard too, that's why most developers don't do it. We're not here because the DOM is crazy. We're here because the DOM is crazy and developers are too lazy/taxed/forced to do it the quick and dirty way instead of the way that works ideologically and is generally accepted as a best practice.
I agree that this is a realist vs. an idealist discussion, though. It's a very mild version of the gun control argument - the idealist in me thinks nobody should need guns, the realist in me realizes that people should be able to have them.
I like reading opinions and ideas on programming from the past and contrasting them to the current state of things. I wonder how the author sees things 10 years later.
CSS is getting variables: https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_v... and I cannot wait to use them. This is the main reason I will be pushing to stop supporting all versions of IE. If you don't like them, you don't have to use them. But I'll give an example of why they are super super handy and long overdue.
Let's say I want to enforce a color palette across my app. I define color variables, and only use those predefined color variables. If the palette changes, I just change the variable, and everything changes. Great, an easy way to have simple and consistent colors on a large project with multiple devs. Even better, I can do this now, with prepocessors like SCSS. After years of using it in an increasingly large project I have zero regrets, I only wish we did it sooner.
But think of this further use case: we want to have different color palettes based on different situations. For the same markup. We want the user to be able to toggle between dark mode and light mode. We want to change the colors when the user is printing something (especially in dark mode). I can't do this in SCSS directly without native CSS variables. I have to compile multiple CSS files from our source ahead of time, and dynamically switch between them, which feels like a hack and causes a lag while the files are fetched.
With CSS variables, I can change the variable to another value inside a certain class. So to toggle between light or dark mode I can just add a class to the body element on the page. I can use the print @media rule to change the variable values when printing. I can do the same with sizes based on the screen dimensions.
This is so simple and clear. When devs are maintaining or adding code they don't need to think about it. Just use the right variable and everything will work out. The alternative to using variables (the new CSS ones or by generating multiple stylesheets using CSS preprocessor variables) is to redefine all the styling that you need to change under a new class. So I have a stylesheet for a feature, then a smaller one that changes all the colors for that feature when the "dark-mode" class is on the body tag, and another for @media print. And then every dev needs to be aware of that and maintain and check all 3 versions whenever they make a change.
Needless to say, I entirely disagree with this article :) I don't think I am the only one who has struggled to understand why CSS is so difficult to use. We've had a few decades to refine it, we should be in a better place by now.
CSS variables are useful if you're a professional web developer. But I would say websites are excessively designed now, especially the kind of ones I visit (other than this).
It's pretty incredible just what an arms race web design is. Web browsers should really not be chugging, ever, in 2018.
49 comments
[ 2.7 ms ] story [ 60.5 ms ] threadAnd not having variables in CSS is more harmful than having them. In the form of a dozen preprocessors and alternative CSS languages that compile to CSS.
If we want to reduce the total number of entities, then we should examine unifying HTML, CSS & scripting. As I've indicated elsewhere, I think that something like this would be awesome:
This could be used to reduce the number of entities in the system, in special those for logic expressions and control flow.
Content is content. Presentation is how that content is displayed. While they can work together, the content is the most important thing and presentation should always be secondary to it.
The author says that a constant lookup table is extra implementation complexity while also saying it's simple and something every programmer should have done as an educational exercise. Considering the density of browser specifications, talking about symbolic constants as feature bloat is some serious windmill-tilting.
They then say that named constants make code harder to understand -- which is obviously an opinion, but one that goes against almost all standard practice. The benefits of naming constants and avoiding magic numbers are well documented, I think. Yes people can go overboard with this, but the solution isn't to not have named constants as an option at all.
The kicker I think is the sheer popularity of CSS preprocessors. When people are compiling to something you designed as an end-user interface, you've failed.
The problem with CSS variables isn't the concept, its that --this-syntax is ugly and unreadable af (admittedly bikeshedding here).
CSS is a good end-user interface for many things without variables.
And people will use preprocessors for CSS no matter how many features it will have because of many reasons including "ugly and unreadable" syntax.
It's better to leave CSS and HTML as simple primitive bytecode for web UI with powerful compilers instead of developing epic w3 specs leading to numerous bugs in browser implementations.
Haven't we pretty much already crossed that bridge? I recall quite a few bugs in CSS specs.
It's because CSS syntax has no changes for almost 20 years and even IE managed to clean up mess. New syntax -> new bugs in browsers.
I'd take most arguments in this with a grain of salt, as it predates much of the progress that CSS (and things like Sass/Less/PostCSS) have made over the past decade.
Even for 2008 this is just wrong. Very few people write any kind of CSS at all. But those who do surely write more.
With respect to the premise of the article: I appreciate having variables because it allows more specificity about what a color or unit is supposed to mean in a given context, which I find valuable.
https://web.archive.org/web/20080306220511/http://news.bbc.c...
That being said, variables are useful. I have no problem using variables in a CSS preprocessor and don't really care one way or the other whether it's included in the CSS spec.
I remember learning CSS in the early 2000s, with the book showing how one could have separate stylesheets for on screen display vs printing. You’d think this approach would have aged nicely, now that websites need to render on a large variety of screen densities/sizes/aspect ratios/etc. Well no, now we have huge bloated CSS files full of media queries and weird things that are impossible to make sense of unless you’ve spent a few weeks in the codebase.
So yes, nice in theory but completely outdated in practice given the horrible Beast DOM has become.
Perhaps that approach was too idealistic all along, and only sort of worked in the beginning, when the web was really basic and most people were on a 1024x768 display. The form is the function and also the medium and the message, and it’s impossible to place abstract boundaries on where the content vs presentation vs interaction lie.
It is about those things not being entangled as spaghetti with each other.
Reacts Philosophy is that everybody's css/js/html is tightly coupled and therefor using different languages with different semantics and scoping rules increase the cognitive complexity without providing any advantage.
Can I break your app by just touching the CSS? Does any cosmetic change at any point require that I touch the html? Can I write a new style sheet for your app without knowing the JS or HTML? Can I plug in a new style sheet of one application into another? Can people work on the JS/HTML/CSS separately and independently?
Putting your spaghetti in separate folders doesn't make it less spaghetti.
And the market knows it's tightly coupled spaghetti for everyone. Thats why you don't see different job adverts for your three different folders.
The goal was to have a world where the designer would know CSS but zero JavaScript and zero HTML. This goal has completely failed.
I think that semantic design/development is hard and that's why people end up with jumbled messes of things. Commenting code is hard too, that's why most developers don't do it. We're not here because the DOM is crazy. We're here because the DOM is crazy and developers are too lazy/taxed/forced to do it the quick and dirty way instead of the way that works ideologically and is generally accepted as a best practice.
I agree that this is a realist vs. an idealist discussion, though. It's a very mild version of the gun control argument - the idealist in me thinks nobody should need guns, the realist in me realizes that people should be able to have them.
Let's say I want to enforce a color palette across my app. I define color variables, and only use those predefined color variables. If the palette changes, I just change the variable, and everything changes. Great, an easy way to have simple and consistent colors on a large project with multiple devs. Even better, I can do this now, with prepocessors like SCSS. After years of using it in an increasingly large project I have zero regrets, I only wish we did it sooner.
But think of this further use case: we want to have different color palettes based on different situations. For the same markup. We want the user to be able to toggle between dark mode and light mode. We want to change the colors when the user is printing something (especially in dark mode). I can't do this in SCSS directly without native CSS variables. I have to compile multiple CSS files from our source ahead of time, and dynamically switch between them, which feels like a hack and causes a lag while the files are fetched.
With CSS variables, I can change the variable to another value inside a certain class. So to toggle between light or dark mode I can just add a class to the body element on the page. I can use the print @media rule to change the variable values when printing. I can do the same with sizes based on the screen dimensions.
This is so simple and clear. When devs are maintaining or adding code they don't need to think about it. Just use the right variable and everything will work out. The alternative to using variables (the new CSS ones or by generating multiple stylesheets using CSS preprocessor variables) is to redefine all the styling that you need to change under a new class. So I have a stylesheet for a feature, then a smaller one that changes all the colors for that feature when the "dark-mode" class is on the body tag, and another for @media print. And then every dev needs to be aware of that and maintain and check all 3 versions whenever they make a change.
Needless to say, I entirely disagree with this article :) I don't think I am the only one who has struggled to understand why CSS is so difficult to use. We've had a few decades to refine it, we should be in a better place by now.
You could also use them natively if you don't care about IE, which is becoming more and more reasonable.
It's pretty incredible just what an arms race web design is. Web browsers should really not be chugging, ever, in 2018.