3 ms·

If you are thinking about CSS, in terms of state, mutability, variable names and programming, you are already down a very wrong path and you won't have a lot of

If you are thinking about CSS, in terms of state, mutability, variable names and programming, you are already down a very wrong path and you won't have a lot of luck. CSS is about rules, selectors and cascading, hence Css. Abstractions matter, and using procedural programming abstractions on a declarative styling language only gets in your way. Writing CSS is not programming.

oneeyedpigeon 10mo ago
Absolutely agree, although CSS has slowly become more and more like a programming language over time, so it's understandable that people have this confusion.
- marcosdumay 10mo ago
  CSS isn't "like" a programming language. It is a programming language. It's just not one based on states, mutability, and variables. Even the things that use the `var` keyword are constants, not variables. (But then, don't read that as being against scoped rules. The fact that all rules are global to the document is bad. We can emulate scopes with specific selectors, but that's the kind of thing a language is supposed to help with.)
  - the_other 10mo ago
    > constants Constants which you can redefine/shadow in scopes, and change the values of at runtime via JS. They seem like variables to me.
    - marcosdumay 10mo ago
      > and change the values of at runtime via JS No, you can't. You can set a new value and reevaluate everything.
      - the_other 10mo ago
        I’m dumb and don’t understand the distinction you’re making. elem.style.setProperty(‘—var-name’, newValue); … will set a new value for the “constant”. The element will rerender with the new value. You can animate/automate these changes and the element will continue to rerebder with the updated value. To me, that justifies the name “variable” from the perspective of the CSS.
IshKebab 10mo ago
Sure but things like scoping and shadowing are still relevant to CSS. The fact that it's declarative doesn't give it an excuse for the poor scoping design.
- throwawayffffas 10mo ago
  In the initial conception pages have their own stylesheet, that solves the scoping issues. It's our fault we pack all the rules in one file and ship it to all our pages. "Shadowing" is on purpose it's the cascading part of the cascading style sheets. There are rules around which rule has priority read about selector specificity.
bigbadfeline 10mo ago
> Writing CSS is not programming. We've heard that one before, haven't we? HTML was supposed to be a declarative language, not a vanilla programming one. And look where we are... the biggest mess of a programming language the world has ever seen. What's the wisdom of randomly inserting cutesy "declarative" bits in a world infused with programming-oriented infrastructure... It doesn't make any sense.
- pjaoko 10mo ago
  HTML (Hyper-Text Markup Language) is a specific kind programming language, a markup language. It is nowhere close to a general purpose (Turing complete) programming language. Maybe you meant the web stack (HTML, JavaScript, CSS)?
  - bigbadfeline 10mo ago
    > Maybe you meant the web stack (HTML, JavaScript) HTML5 doesn't refer specifically to HTML, rather it's "HTML + JavaScript + CSS". There's hardly a website nowadays that can be used without JS. By using the name HTML5 as an umbrella name for a programming language API plus some declarative bits, the W3C tacitly admitted that the declarative push has been a mistake - I explained "why" in my previous comment.
    - 1718627440 10mo ago
      On a technical forum in a post that contains, both the words "CSS" and "HTML"? Sorry, but no "HTML5" refers to the version 5 of the Hypertext Markup Language.
      - bigbadfeline 10mo ago
        HTML5 is the HTML of today, that's what I meant originally. I'm not sure what you're afraid of, nobody is attacking you, I'm simply explaining what I had in mind, and why it's not unreasonable to use words in a more inclusive, close to contemporary practice meaning. The fact is, JavaScript is ubiquitous in web programing and the web is unthinkable without it, it's so pervasive on the front end that it's been repurposed for backend use precisely because it makes a lot of sense to use one programming language for one project. Pure HTML is unsuitable for backend use and it sticks like a sore thumb in the front end. Younger developers are likely missing on the history of the entire web endeavor but in order to get a feel for it, I'd recommend to focus on practical meaning rather than on trivial semantics. The big point I was driving at is this: The damage has been done, instead of a clean rendering API we've got this hybrid monstrosity which locked us to a couple / triple browser rendering engines which, due to cutesy BS, are complex beyond comprehension, beyond security analysis or normal competition. This is what an obsession with fancy names leads to.

oneeyedpigeon 10mo ago

Absolutely agree, although CSS has slowly become more and more like a programming language over time, so it's understandable that people have this confusion.

marcosdumay 10mo ago
CSS isn't "like" a programming language. It is a programming language. It's just not one based on states, mutability, and variables. Even the things that use the `var` keyword are constants, not variables. (But then, don't read that as being against scoped rules. The fact that all rules are global to the document is bad. We can emulate scopes with specific selectors, but that's the kind of thing a language is supposed to help with.)
- the_other 10mo ago
  > constants Constants which you can redefine/shadow in scopes, and change the values of at runtime via JS. They seem like variables to me.
  - marcosdumay 10mo ago
    > and change the values of at runtime via JS No, you can't. You can set a new value and reevaluate everything.
    - the_other 10mo ago
      I’m dumb and don’t understand the distinction you’re making. elem.style.setProperty(‘—var-name’, newValue); … will set a new value for the “constant”. The element will rerender with the new value. You can animate/automate these changes and the element will continue to rerebder with the updated value. To me, that justifies the name “variable” from the perspective of the CSS.

IshKebab 10mo ago

Sure but things like scoping and shadowing are still relevant to CSS. The fact that it's declarative doesn't give it an excuse for the poor scoping design.

throwawayffffas 10mo ago
In the initial conception pages have their own stylesheet, that solves the scoping issues. It's our fault we pack all the rules in one file and ship it to all our pages. "Shadowing" is on purpose it's the cascading part of the cascading style sheets. There are rules around which rule has priority read about selector specificity.

bigbadfeline 10mo ago

> Writing CSS is not programming. We've heard that one before, haven't we? HTML was supposed to be a declarative language, not a vanilla programming one. And look where we are... the biggest mess of a programming language the world has ever seen. What's the wisdom of randomly inserting cutesy "declarative" bits in a world infused with programming-oriented infrastructure... It doesn't make any sense.

pjaoko 10mo ago
HTML (Hyper-Text Markup Language) is a specific kind programming language, a markup language. It is nowhere close to a general purpose (Turing complete) programming language. Maybe you meant the web stack (HTML, JavaScript, CSS)?
- bigbadfeline 10mo ago
  > Maybe you meant the web stack (HTML, JavaScript) HTML5 doesn't refer specifically to HTML, rather it's "HTML + JavaScript + CSS". There's hardly a website nowadays that can be used without JS. By using the name HTML5 as an umbrella name for a programming language API plus some declarative bits, the W3C tacitly admitted that the declarative push has been a mistake - I explained "why" in my previous comment.
  - 1718627440 10mo ago
    On a technical forum in a post that contains, both the words "CSS" and "HTML"? Sorry, but no "HTML5" refers to the version 5 of the Hypertext Markup Language.
    - bigbadfeline 10mo ago
      HTML5 is the HTML of today, that's what I meant originally. I'm not sure what you're afraid of, nobody is attacking you, I'm simply explaining what I had in mind, and why it's not unreasonable to use words in a more inclusive, close to contemporary practice meaning. The fact is, JavaScript is ubiquitous in web programing and the web is unthinkable without it, it's so pervasive on the front end that it's been repurposed for backend use precisely because it makes a lot of sense to use one programming language for one project. Pure HTML is unsuitable for backend use and it sticks like a sore thumb in the front end. Younger developers are likely missing on the history of the entire web endeavor but in order to get a feel for it, I'd recommend to focus on practical meaning rather than on trivial semantics. The big point I was driving at is this: The damage has been done, instead of a clean rendering API we've got this hybrid monstrosity which locked us to a couple / triple browser rendering engines which, due to cutesy BS, are complex beyond comprehension, beyond security analysis or normal competition. This is what an obsession with fancy names leads to.