:root { --color: blue; }
div { --color: green; }
#alert { --color: red; }
* { color: var(--color); }
<p>I inherited blue from the root element!</p>
<div>I got green set directly on me!</div>
<div id='alert'>
While I got red set directly on me!
<p>I’m red too, because of inheritance!</p>
</div>
Excuse my negativity, but this is messed up. I am trying to rationalize whyyyy???.
It seems every object is given variables (--abc). And then there are global variables and local variables. I guess this is the "cascading" feature. var is a function computed at the time of instantiation. And refers to local variables first. Then looks at global variable. Inheritance comes from ?? The p tag seems it is not root so therefore it is not blue.
Having explained it, I think about it better, but this really messes up how I thought of CSS. CSS is where the second stanza overwrites the first stanza. Yet global and local variables really hurts my head. A few complex CSS files later, it is bound to be unusable to determine result without getting a computer program to help.
I think you are demonstrating the title of this article. The --color variable is inherited through your style sheet cascade, just like any built-in property would be. In other words, CSS variables are pretty much custom properties.
In the last line of CSS, you went on to equate a built-in property with the value of the variable everywhere. So you’ve essentially made a new “property” that works just like the builtin color property.
(Disclaimer: I’m not an expert in modern CSS, so this could be imprecise.)
In OP's example, the <p> would be colored blue, because the * selector directly targets it, taking priority over the inherited value from the #alert parent element if the CSS had been normal assignment:
#alert { color: red }
* { color: blue }
Variables behave slightly differently, in that they don't follow specificity rules. The definition of the variable / property behaves like a scope, and affects everything within it, hence the <p> being colored red instead of blue.
* directly targets elements and assigns to them `color: var(--color)` and is not overwritten by anything. It is normal CSS assignment. Variables aren't macros or templates or rewrite rules. They are simply properties.
Variables don't follow specificity in the same sense that other properties don't follow specificity. Specificity only applies to rules in the first place, not to properties.
The variables behave the same as inline styles on the elements would, though, right? And you can do variable assignments in style rules, and they follow specificity as usual?
I am out of my comfort zone here, but if that were true then at least I’d find it understandable. Variables act like properties and rules still act like rules.
this would be preferable to what was done variables because it is more straightforward. The dumb example of custom property using you highlight does not help make clearer code, nor does it help make css easier to understand, but I guess they were hoping people would see that custom properties inherit basically the same way that other properties inherit, except that there is this freaky :root context instead of using body.
obviously things can be complicated because only some properties inherit, but the claim holds. CSS properties are set by context.
The <p> tag is red because it is inside of #alert. Anything inside of #alert has the color variable set to red.
Variables don't use specificity like CSS selectors. I prefer to create a few layers for variables; one for color names, one that maps color name variables to global semantic names (i.e. --primary-cta-color: var(--blue-50) or something), and maybe go so far as to add another that maps component-specific semantics to global specific semantics (i.e. --date-picker-hover-color: var(--primary-cta-color)).
Do CSS variables let you count arbitrarily-deep nesting levels? That is, can a rule for `x` defined a variable that matches the number in the immediate text here?
Not by themselves, at least today, as we can't currently modify the value of a custom property by using itself in the calculation. But in the future we will have an `inherit()` functional notation that will unlock this (and at least Chrome implemented it in Canary already — https://blog.kizu.dev/play-with-inherit-function/).
It is possible to use style queries and some hacks (https://kizu.dev/self-modifying-variables/) to achieve this today, but that doesn't bring this closer to production, as Firefox still does not support them (but will be soon).
Variables are defined and cascade the same as any other property. You can define variables and other properties on the third-level x element in your markup like so:
x > x > x {
--my-variable: 'my-value';
display: inline;
/* etc. */
}
It would be used by defining the value of another property as the value of the variable. Note the selectors don't have to match; in this case all x elements will have their content properties set to the --my-variable value but only the third-nested x element will have a --my-variable value set.
x {
content: var(--my-variable);
}
Not that this is a particularly coherent example but hopefully you get the idea.
Why so? By adding --foo: bar to a selector, you’re actually adding a new, custom, property named --foo to it, just as the display in display: block would be another property.
It’s not a bad analogy, but how the spec intends it to work.
This topic always tickles the pedantic part of my brain. If I may assume that the reader would agree that JS is a programming language, what makes it a programming language and not HTML? What makes a static .js file a program and a static .html file not a program?
Generally speaking, HTML doesn't have the constructs necessary to actually compute things. There's no way to declare variables, and there are no conditionals, jumping, or mathematical operations. All you can do is specify a fixed set of page elements.
Embedded JS within HTML doesn't count here, as that's essentially no different than a linked script file.
To be fair, there are some exceptions to this; there are some very hacky and convoluted ways you might be able to get some programmatic behavior out of pure HTML (I remember hearing about a weird example in part of Wikipedia's codebase).
HTML literally means hypertext markup language. It's more like TeX or Markdown, in that it's used to store and represent data, not to manipulate it.
> All you can do is specify a fixed set of page elements.
I'm not denying this but rather questioning why this means the document which specifies this is not a program. The previous sentences describe why it's not Turing-complete, which is moot to whether it's a programming language.
> HTML literally means hypertext markup language. It's more like TeX or Markdown, in that it's used to store and represent data, not to manipulate it.
I disagree that HTML is not used to manipulate data. Unless you mean to say that it doesn't manipulate it directly but I think that's also moot. My day job is to use HTML to build forms that are used to accept user input for data manipulations. It seems to me that I'm programming the browser to render the correct form and the language I'm using for the programming is HTML.
Besides, being used only to store and represent data does not seem to necessarily preclude it being a programming language. "Program" is a word that's used to describe a presentation of some kind. A wind ensemble might perform a "program" of pieces on concert night.
Well, if you'll pardon the tautology, it's a language that's used for precisely expressing programs. Of course, that just shifts the question. What's a program?
It's a set of instructions for a computer to execute. Hopefully that's not controversial. But isn't `<input type="text">` an instruction to render a text input?
It is "controversial" because it's way too vague, which the pedant part should recognize (is a mouse click not an instruction for a computer to execute?), so of course you won't be able to differentiate at this level.
It's overly simplified to the point of being meaningless. A .js file is a document that presents information to me when I open it using a text editor. So is a .html file, for that matter. Something different happens when they're opened in a browser and, for that reason, they both seem to be programs as well.
you can ignore the fact that they look like text. look past that
program and document just are different things. (I gave a simplified definition). if they both are represented using text when creating, it doesn't make them the same. because some text is a programming language and can create program, and some text use markup language and can create document.
it's like humans and worms are carbon life, if you only look at that you can't tell difference between humans and worms. you need to look what kinds of cells are in them or even better what they do
It seems like you want to intentionally not understand this?
Why is that a better descriptor? I don't understand this desire to demarcate between programming languages and whatever a "syntax" language is. All languages have syntax, even natural languages - it's one of the terms we've borrowed from linguists.
HTML is one of the languages I use when I am programming. In the sense, I really struggle to see the argument that it isn't a programming language, unless someone is using a very precise definition of "programming language" that I'm not privy to. There's a bunch of well-defined stuff it _isn't_ (e.g. Turing-complete), and a bunch of well-defined stuff that it is (e.g. declarative, or a markup language), but as far as I can tell there's no better definition of "programming language" than "language used for programming", and it certainly seems to fit that bill.
I've seen HTML and CSS being denied status as a programming language many, many times. It is a signal that the person making the claim hasn't encountered one of these debates before.
Yes, it is a programming language. And so is HTML, LaTeX, heck even Markup is a programming language. The shapes of discs you put into your 1950s Elna Supermatic sewing machine that alters the stitch, also a programing language.
The only requirements is that it compiles into a set of instructions which computers (or sewing machines, etc.) know how to read and execute into a predictable (preferably desired) outcome.
A programming language does not need to be Turing complete to be a programming language.
Then they drag-and-drop the project folder into FileZilla connected to their FTP shared hosting and send the invoice to the client.
Although... while this seems like heaven at first, seeing this being done in practice, it is hell. It's just people don't know they are in hell. They got used to it.
Hell is being the sys admin at a web hosting company.
You can either pay a web developer to update your fully static site once a year, or you can pay them five times a year to clean up your Wordpress install when it inevitably gets popped because that one mailback form plugin you demanded... you know the one that has never received a single non-spam submission... hasn't been updated in ten years... and also you're too cheap to pay someone to maintain your Wordpress site because "why would I do that the site is finished?"
My job requires the whole modern pipeline with Vue front ends, Quarkus services and k8s deployments and it's suitable for what we do in our teams.
But I have dozens of websites I built and am still building today in the way described and it works just as well for me. As a single developer with "simple" websites it's just great to have so little mental load when fixing some small things.
Admittedly I have a small script to upload stuff via ftp (if ssh/rsync is not available), so no FileZilla anymore :)
I, too, settled on a minimalist process for deploying my blog, just build it with a Hugo, copy the files over to a cheap server, and there you go, deployed. It's the right tool for the job (for me).
I thought about that process, too, but it’s more convenient to skip the whole “lots of commits” and GHA loop.
At the moment I’m still mainly fixing and customizing the theme, but I expect that once I actually start blogging instead of fixing the theme and learning Hugo, GitHub actions would make sense again.
> I, too, settled on a minimalist process for deploying my blog, just build it with a Hugo, copy the files over to a cheap server, and there you go, deployed.
Meh. That's over-engineered[1] /s :-)
--------------------
[1] I have a bash script that produces the site from markdown snippets, commits it to a repo and the VPS pulls master periodically.
Don't believe all the horror stories on HN are necessarily representative without trying it yourself. People generally came up with these newfangled things for a reason. I personally very much appreciate having CI/CD that deploys my changes every time I push.
Then again, writing stylesheets is still one of those things where, if you're not careful, everything spirals out of control. Often I'll make changes and wonder why nothing's happening and realize something was overridden by another rule somewhere, or I was mixing up two properties, or some other silly thing...
I also find it's a bit awkward to write var(--foo) every time... I wish I could just write --foo... I suppose there's a grammar issue somewhere, or maybe it would have increased the complexity of implementations of CSS.
> Then again, writing stylesheets is still one of those things where, if you're not careful, everything spirals out of control. Often I'll make changes and wonder why nothing's happening and realize something was overridden by another rule somewhere…
It doesn't have to be this way; just write your CSS using Inverted Triangle CSS (ITCSS) [1] and these issues go away.
`attr()` is being updated to basically do that, the modern spec lets you specify a datatype and access any attribute (with some exceptions, you can't get URL types for security reasons), then use it generally.
To a large degree yes, but it blows my mind how complex some of the new features are when what seems like basics are still nonexistent. Root level variables for example (think media queries).
No way. There have been so many nice improvements to all of those languages over the last two decades that make development so much safer to implement, faster to code, and easier to test. I personally would lose my mind if I had to go back to the way things were running 20 years ago
Eh. I've found that increasing use of CSS variables / custom properties has made me a much happier developer. Sometimes new things aren't necessarily bad.
I would say that is all the more reason for writing HTML and CSS with a sprinkling of JS - you need less JS for the same result, you need CSS frameworks less.
I am not so sure about PHP, but I think the intent is more "do it in the backend where possible" which i agree with.
Have you ever actually met backend Linux engineers? They are, typically anyways, a very salty and unhappy bunch. I definitely include myself in that lot as something I'm working on.
yeah, I work on commandline based compilers and code analysis tools and I'm very happy doing it! apart from the work itself being interesting, I find it really nice to just have to care about stdin, stdout, and filesystem access. I enjoy working on desktop gui apps too, but at least to my mind IPC and networking add a layer of unpleasantly error-prone concerns to deal with, and web apps dial that up to eleven.
Hear, hear. Compilers are so much fun: you get data in, you put data out, and in between it's all algorithms and data structures. Nothing but the good stuff.
Given the ageist in tech, I would guess most devs actually writing code were still children 20 years ago and some were still babies so I don't think they are used to life before build tool JS. And writing plain js is outrageous like stepping outside in your underwear.
Browser idiosyncrasies, horrendous security vulnerabilities, the blood sacrifices to do basic things with CSS, trying to debug in IE, the daily “maybe Flash isn’t that bad” introspection.
There really aren't browser idiosyncrasies to worry about today. In fact, if you're concerned about rendering differences between Chrome and Safari, you're probably worrying too much about the exact presentation details.
I'd also say HTML4 is much nicer to write than HTML5. I know it's technically "obsolete", but it was more pleasant to work with (and allows your site to be accessible on almost every browser/version).
There must be some confusion here. HTML 5 simplified doctypes, codified rules for interpreting malformed HTML, and added some new tags. Unless you’re using some crazy deprecated tags, you should just be able to write HTML4 and update the doctype.
By HTML4 I mean non-use of HTML5/CSS3 features. I'd also add that, while still supported by browsers, HTML5 deprecated lots of elements and parameters that I find handy.
"Web Components" is a term I do try to avoid though. "Components" is a word loaded with very specific meaning to a lot of JS folk, and it can be really hard to describe the ways in which a "Web Component" does not behave like a "React Component" for example. "Custom Elements" is meaningfully useful to push for!!
Looking at example 5:
Excuse my negativity, but this is messed up. I am trying to rationalize whyyyy???.It seems every object is given variables (--abc). And then there are global variables and local variables. I guess this is the "cascading" feature. var is a function computed at the time of instantiation. And refers to local variables first. Then looks at global variable. Inheritance comes from ?? The p tag seems it is not root so therefore it is not blue.
Having explained it, I think about it better, but this really messes up how I thought of CSS. CSS is where the second stanza overwrites the first stanza. Yet global and local variables really hurts my head. A few complex CSS files later, it is bound to be unusable to determine result without getting a computer program to help.
I think you are demonstrating the title of this article. The --color variable is inherited through your style sheet cascade, just like any built-in property would be. In other words, CSS variables are pretty much custom properties.
In the last line of CSS, you went on to equate a built-in property with the value of the variable everywhere. So you’ve essentially made a new “property” that works just like the builtin color property.
(Disclaimer: I’m not an expert in modern CSS, so this could be imprecise.)
> just like any built-in property would be
Nit: only inherited properties are inherited.
For example color and font-family are, while padding and background-color are not.
One of the special rules you kind of just need to get a feel for that makes CSS a little inscrutable to those who don’t practise it every day.
In OP's example, the <p> would be colored blue, because the * selector directly targets it, taking priority over the inherited value from the #alert parent element if the CSS had been normal assignment:
Variables behave slightly differently, in that they don't follow specificity rules. The definition of the variable / property behaves like a scope, and affects everything within it, hence the <p> being colored red instead of blue.* directly targets elements and assigns to them `color: var(--color)` and is not overwritten by anything. It is normal CSS assignment. Variables aren't macros or templates or rewrite rules. They are simply properties.
Variables don't follow specificity in the same sense that other properties don't follow specificity. Specificity only applies to rules in the first place, not to properties.
The variables behave the same as inline styles on the elements would, though, right? And you can do variable assignments in style rules, and they follow specificity as usual?
I am out of my comfort zone here, but if that were true then at least I’d find it understandable. Variables act like properties and rules still act like rules.
I agree it's messed up but programming examples often are in order to convey some information.
A css property is set at a context, for example
body {color: blue}
div { color: green }
#alert {color: red}
https://codepen.io/bryanrasmussen/pen/PwNQyOm
this would be preferable to what was done variables because it is more straightforward. The dumb example of custom property using you highlight does not help make clearer code, nor does it help make css easier to understand, but I guess they were hoping people would see that custom properties inherit basically the same way that other properties inherit, except that there is this freaky :root context instead of using body.
obviously things can be complicated because only some properties inherit, but the claim holds. CSS properties are set by context.
The <p> tag is red because it is inside of #alert. Anything inside of #alert has the color variable set to red.
Variables don't use specificity like CSS selectors. I prefer to create a few layers for variables; one for color names, one that maps color name variables to global semantic names (i.e. --primary-cta-color: var(--blue-50) or something), and maybe go so far as to add another that maps component-specific semantics to global specific semantics (i.e. --date-picker-hover-color: var(--primary-cta-color)).
That way, you can add something like
and / or as a purely hypothetical example. Slap the class name your user wants on the body tag, and you're good to go.It's very straightforward. It doesn't matter whether the property name starts with -- or not, it behaves exactly the same way in terms of inheritance.
wow great example - I'm also baffled by this. is this just not a great example because it seems like it's reinventing the wheel
Do CSS variables let you count arbitrarily-deep nesting levels? That is, can a rule for `x` defined a variable that matches the number in the immediate text here?
Not by themselves, at least today, as we can't currently modify the value of a custom property by using itself in the calculation. But in the future we will have an `inherit()` functional notation that will unlock this (and at least Chrome implemented it in Canary already — https://blog.kizu.dev/play-with-inherit-function/).
It is possible to use style queries and some hacks (https://kizu.dev/self-modifying-variables/) to achieve this today, but that doesn't bring this closer to production, as Firefox still does not support them (but will be soon).
Variables are defined and cascade the same as any other property. You can define variables and other properties on the third-level x element in your markup like so:
It would be used by defining the value of another property as the value of the variable. Note the selectors don't have to match; in this case all x elements will have their content properties set to the --my-variable value but only the third-nested x element will have a --my-variable value set. Not that this is a particularly coherent example but hopefully you get the idea.So, the answer is "no", since that's just old-school finite depth counting.
The idea of naming the stuff you use with a "var" keyword as "properties" is really bad.
Why so? By adding --foo: bar to a selector, you’re actually adding a new, custom, property named --foo to it, just as the display in display: block would be another property.
It’s not a bad analogy, but how the spec intends it to work.
If you don't want people to universally call them "variables", you should use another keyword. Or you can keep the keyword and change the name.
Either one is fine, the combination is bad.
and the name of the function we use to access them is var()! Not customProperty().
I've just been calling them that anyway since I found out they existed.
Also, this guy is calling HTML a programming language. Make of that what you will...
It is a language, just not a turing complete one.
Pidgen is a type of language, too, but you wouldn't be writing Shakespeare in it.
There's nothing to be pedantic about HTML here, and it just seems so absolutely pointless to me that people try to find a way to be.
It's not that it's not a language, it's that it's not a programming language. You don't write programs in it.
This topic always tickles the pedantic part of my brain. If I may assume that the reader would agree that JS is a programming language, what makes it a programming language and not HTML? What makes a static .js file a program and a static .html file not a program?
Generally speaking, HTML doesn't have the constructs necessary to actually compute things. There's no way to declare variables, and there are no conditionals, jumping, or mathematical operations. All you can do is specify a fixed set of page elements.
Embedded JS within HTML doesn't count here, as that's essentially no different than a linked script file.
To be fair, there are some exceptions to this; there are some very hacky and convoluted ways you might be able to get some programmatic behavior out of pure HTML (I remember hearing about a weird example in part of Wikipedia's codebase).
HTML literally means hypertext markup language. It's more like TeX or Markdown, in that it's used to store and represent data, not to manipulate it.
> All you can do is specify a fixed set of page elements.
I'm not denying this but rather questioning why this means the document which specifies this is not a program. The previous sentences describe why it's not Turing-complete, which is moot to whether it's a programming language.
> HTML literally means hypertext markup language. It's more like TeX or Markdown, in that it's used to store and represent data, not to manipulate it.
I disagree that HTML is not used to manipulate data. Unless you mean to say that it doesn't manipulate it directly but I think that's also moot. My day job is to use HTML to build forms that are used to accept user input for data manipulations. It seems to me that I'm programming the browser to render the correct form and the language I'm using for the programming is HTML.
Besides, being used only to store and represent data does not seem to necessarily preclude it being a programming language. "Program" is a word that's used to describe a presentation of some kind. A wind ensemble might perform a "program" of pieces on concert night.
What's the definition of a programming language in the tickling part of your brain?
Well, if you'll pardon the tautology, it's a language that's used for precisely expressing programs. Of course, that just shifts the question. What's a program?
It's a set of instructions for a computer to execute. Hopefully that's not controversial. But isn't `<input type="text">` an instruction to render a text input?
It is "controversial" because it's way too vague, which the pedant part should recognize (is a mouse click not an instruction for a computer to execute?), so of course you won't be able to differentiate at this level.
programming language makes program
markup language makes document
program does things. document presents info.
we use program to render document.
Thanks for your input but your answers still leave me with questions.
> programming language makes program
What makes a static .js file a program, not a document, and a static .html file a document, not a program?
> we use program to render document.
Is this like how node is a program that's used to render JS documents?
you should start with definitions of program and document and you'll have your answer. in a simplified way, as i said:
program does things. document presents info.
> in a simplified way, as i said:
It's overly simplified to the point of being meaningless. A .js file is a document that presents information to me when I open it using a text editor. So is a .html file, for that matter. Something different happens when they're opened in a browser and, for that reason, they both seem to be programs as well.
you can ignore the fact that they look like text. look past that
program and document just are different things. (I gave a simplified definition). if they both are represented using text when creating, it doesn't make them the same. because some text is a programming language and can create program, and some text use markup language and can create document.
it's like humans and worms are carbon life, if you only look at that you can't tell difference between humans and worms. you need to look what kinds of cells are in them or even better what they do
It seems like you want to intentionally not understand this?
That's where I'm coming from.
It is just a syntax language, used in programming web pages. that would be a better descriptor
Why is that a better descriptor? I don't understand this desire to demarcate between programming languages and whatever a "syntax" language is. All languages have syntax, even natural languages - it's one of the terms we've borrowed from linguists.
HTML is one of the languages I use when I am programming. In the sense, I really struggle to see the argument that it isn't a programming language, unless someone is using a very precise definition of "programming language" that I'm not privy to. There's a bunch of well-defined stuff it _isn't_ (e.g. Turing-complete), and a bunch of well-defined stuff that it is (e.g. declarative, or a markup language), but as far as I can tell there's no better definition of "programming language" than "language used for programming", and it certainly seems to fit that bill.
I've seen HTML and CSS being denied status as a programming language many, many times. It is a signal that the person making the claim hasn't encountered one of these debates before.
Yes, it is a programming language. And so is HTML, LaTeX, heck even Markup is a programming language. The shapes of discs you put into your 1950s Elna Supermatic sewing machine that alters the stitch, also a programing language.
The only requirements is that it compiles into a set of instructions which computers (or sewing machines, etc.) know how to read and execute into a predictable (preferably desired) outcome.
A programming language does not need to be Turing complete to be a programming language.
It is one...
The happiest software developers are those who write HTML, CSS, PHP, and just a sprinkle of JS like they used to do 20 years ago.
Then they drag-and-drop the project folder into FileZilla connected to their FTP shared hosting and send the invoice to the client.
Although... while this seems like heaven at first, seeing this being done in practice, it is hell. It's just people don't know they are in hell. They got used to it.
Hell is being the sys admin at a web hosting company.
You can either pay a web developer to update your fully static site once a year, or you can pay them five times a year to clean up your Wordpress install when it inevitably gets popped because that one mailback form plugin you demanded... you know the one that has never received a single non-spam submission... hasn't been updated in ten years... and also you're too cheap to pay someone to maintain your Wordpress site because "why would I do that the site is finished?"
I know, right, it's not like, like software rots or whatever.
My job requires the whole modern pipeline with Vue front ends, Quarkus services and k8s deployments and it's suitable for what we do in our teams.
But I have dozens of websites I built and am still building today in the way described and it works just as well for me. As a single developer with "simple" websites it's just great to have so little mental load when fixing some small things.
Admittedly I have a small script to upload stuff via ftp (if ssh/rsync is not available), so no FileZilla anymore :)
I, too, settled on a minimalist process for deploying my blog, just build it with a Hugo, copy the files over to a cheap server, and there you go, deployed. It's the right tool for the job (for me).
Or, for that matter, using GitHub Actions to do the final Hugo build and remote deployment when you do a git push.
I thought about that process, too, but it’s more convenient to skip the whole “lots of commits” and GHA loop.
At the moment I’m still mainly fixing and customizing the theme, but I expect that once I actually start blogging instead of fixing the theme and learning Hugo, GitHub actions would make sense again.
Bro, if you want to start blogging, just do it and get rid of all these dev stuff and focus on blogging.
I suggest you use a platform like justblogged.com.
Shameless plug, yes I built it.
> I, too, settled on a minimalist process for deploying my blog, just build it with a Hugo, copy the files over to a cheap server, and there you go, deployed.
Meh. That's over-engineered[1] /s :-)
--------------------
[1] I have a bash script that produces the site from markdown snippets, commits it to a repo and the VPS pulls master periodically.
I still think about the person on Mastodon I saw months ago: "My deployment pipeline is to click FILE->SAVE"
A workflow that sounds a lot better than 99% of what I read goes on in modern web development from comments on HN.
Don't believe all the horror stories on HN are necessarily representative without trying it yourself. People generally came up with these newfangled things for a reason. I personally very much appreciate having CI/CD that deploys my changes every time I push.
Never a git history rewrite after a declined pull request, pure “index.html_previous_3” bliss
and then they wake up and go "oh, aw crap!"
CSS has been steadily improving across browsers, addressing pain points and real world scenarios.
CSS grid and subgrid, nesting, variables, container queries, css layers…
In 2025 it’s a pleasure to work with. Props to the amazing people involved in pushing the standards forward.
I can't argue with this.
Then again, writing stylesheets is still one of those things where, if you're not careful, everything spirals out of control. Often I'll make changes and wonder why nothing's happening and realize something was overridden by another rule somewhere, or I was mixing up two properties, or some other silly thing...
I also find it's a bit awkward to write var(--foo) every time... I wish I could just write --foo... I suppose there's a grammar issue somewhere, or maybe it would have increased the complexity of implementations of CSS.
> Then again, writing stylesheets is still one of those things where, if you're not careful, everything spirals out of control. Often I'll make changes and wonder why nothing's happening and realize something was overridden by another rule somewhere…
It doesn't have to be this way; just write your CSS using Inverted Triangle CSS (ITCSS) [1] and these issues go away.
[1]: https://matthiasott.com/notes/how-i-structure-my-css
I dont mind the var(--foo) but I wish I could do var(attr(foo)) to use a var defined in the attribute foo.
`attr()` is being updated to basically do that, the modern spec lets you specify a datatype and access any attribute (with some exceptions, you can't get URL types for security reasons), then use it generally.
E.g: aspect-ratio: attr(width px) / attr(height px);
Interestingly, the bug for this feature is already 17 years old (https://bugzilla.mozilla.org/show_bug.cgi?id=435426).
To a large degree yes, but it blows my mind how complex some of the new features are when what seems like basics are still nonexistent. Root level variables for example (think media queries).
Totally agree. There's no real complaints, and the coalescing around the Chrome layout engine means far less compatibility issues in general.
No way. There have been so many nice improvements to all of those languages over the last two decades that make development so much safer to implement, faster to code, and easier to test. I personally would lose my mind if I had to go back to the way things were running 20 years ago
Swap PHP with C# and we're in full agreement.
I'm not a CSS expert but being able to do so much with it before having to reach for JS is fantastic.
And with Blazor, some of that JS sprinkle isn't even needed anymore.
Eh. I've found that increasing use of CSS variables / custom properties has made me a much happier developer. Sometimes new things aren't necessarily bad.
I would say that is all the more reason for writing HTML and CSS with a sprinkling of JS - you need less JS for the same result, you need CSS frameworks less.
I am not so sure about PHP, but I think the intent is more "do it in the backend where possible" which i agree with.
Because you can actually parameterize things. It's wonderful!
the happiest software developers are those who write apps that run in a single command line process on a local linux machine (:
Have you ever actually met backend Linux engineers? They are, typically anyways, a very salty and unhappy bunch. I definitely include myself in that lot as something I'm working on.
yeah, I work on commandline based compilers and code analysis tools and I'm very happy doing it! apart from the work itself being interesting, I find it really nice to just have to care about stdin, stdout, and filesystem access. I enjoy working on desktop gui apps too, but at least to my mind IPC and networking add a layer of unpleasantly error-prone concerns to deal with, and web apps dial that up to eleven.
Hear, hear. Compilers are so much fun: you get data in, you put data out, and in between it's all algorithms and data structures. Nothing but the good stuff.
Given the ageist in tech, I would guess most devs actually writing code were still children 20 years ago and some were still babies so I don't think they are used to life before build tool JS. And writing plain js is outrageous like stepping outside in your underwear.
Funnily enough, I did all that.
And it made me want to claw my eyes out.
Browser idiosyncrasies, horrendous security vulnerabilities, the blood sacrifices to do basic things with CSS, trying to debug in IE, the daily “maybe Flash isn’t that bad” introspection.
There are many good things about this world.
2005 web dev is not among them.
There really aren't browser idiosyncrasies to worry about today. In fact, if you're concerned about rendering differences between Chrome and Safari, you're probably worrying too much about the exact presentation details.
I very often find websites broken in Safari that work in Chrome.
> Browser idiosyncrasies, horrendous security vulnerabilities, the blood sacrifices to do basic things with CSS,
...
> There are many good things about this world. 2005 web dev is not among them.
Maybe, but the 2005 process will work better now, because the current process was started as a way to paper over all those
> Browser idiosyncrasies, horrendous security vulnerabilities, the blood sacrifices to do basic things with CSS,
Now that those things are smaller issues, "Write JS, copy it to the server" is not so stupid. Especially if you've got mostly web components.
You can pry flexbox out my cold dead hands.
Go and vertically center a div in whatever way you see fit.
That was my point, with the tech improvements we now have in frontend many of the reasons for abandoning the 2005 process becomes moot.
New tech makes the old process more viable, not less.
[dead]
I'd also say HTML4 is much nicer to write than HTML5. I know it's technically "obsolete", but it was more pleasant to work with (and allows your site to be accessible on almost every browser/version).
There must be some confusion here. HTML 5 simplified doctypes, codified rules for interpreting malformed HTML, and added some new tags. Unless you’re using some crazy deprecated tags, you should just be able to write HTML4 and update the doctype.
By HTML4 I mean non-use of HTML5/CSS3 features. I'd also add that, while still supported by browsers, HTML5 deprecated lots of elements and parameters that I find handy.
Which deprecated HTML4 features do you use? Also, what do you think of the more semantic elements in HTML5 such as <date>?
I occasionally use font tags. As an example, this:
<p><font face="font">Your text here</font></p>
Looks way better than:
<p style="font-family: 'font', sans-serif;"></p>
to me.
CSS variables = custom properties
Web components = custom elements
:shrug:
"Web Components" is a term I do try to avoid though. "Components" is a word loaded with very specific meaning to a lot of JS folk, and it can be really hard to describe the ways in which a "Web Component" does not behave like a "React Component" for example. "Custom Elements" is meaningfully useful to push for!!
The same for Web Components (in place of Custom Elements).
This would make sense if we defined them by inheriting `HTMLComponent` (https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement) and registered them with the DOM using `document.createComponent` (https://developer.mozilla.org/en-US/docs/Web/API/Document/cr...).