> Selectors are a global namespace. Imagine if every variable and function in your favorite programming languages were global and so had to be unique.
A selector is not not a variable or a function. CSS has functions (e.g translate) and it has variables, which are both distinct concepts in the language from selectors.
> No modules or namespaces.
CSS is not supposed to be a turing complete general purpose programming language. Why would you need namespaces and modules to style up HTML tags?
Because many web sites and apps aren't as simple as "my first homepage" and don't only consist of first-party code. Think component libraries. Reusable code. Content management systems. Third-party SDKs (chat widgets, support widgets, payment widgets like Stripe, etc.).
One of my earliest webdev jobs was at a company whose product was a widget you could add to your site by adding our `<script>` tag. Thus, our CSS needed to coexist with the first-party site's, not to mention any other third-party widgets on there. In other words: the same exact reason you need modules in traditional languages.
It's true in a case where you are doing the described thing you will need to come up with your own module system and ways to not step on other people's stuff but it isn't actually difficult. Although I have noticed some stories recently were quite big companies evidently didn't put in the work to keep from messing up other people's stuff.
Of course one drawback with that is you are also depending on developers and content managers at sites following your documentation on how to use your products, which is a different problem.
on edit: obviously if you have been writing css since 1997 and one of your first webdev jobs was this kind of thing, things were much more difficult back then. I did the same sort of thing in 2014-2015, not particularly difficult to make work. I worked web dev since 1999, first job was dynamic generation of web sites and other media from single source data.
> Because many web sites and apps aren't as simple as "my first homepage" and don't only consist of first-party code.
CSS is there to style HTML tags. Yes, your complex webb app is dealing with a lot of third party code and whatnot... but CSS is just there to style your HTML tags. Why is it so hard to get that?
Because that third-party code adds its own HTML tags.
Because that third-party code adds its own CSS.
Because my HTML and the third-party HTML live in the same document. Thus, my CSS could target their HTML, and their CSS could target my HTML. There are no modules and therefore no module boundaries.
Because my CSS and the third-party CSS share a global namespace. Thus, their CSS selectors might overlap with my CSS selectors. Hopefully nobody called anything ".container" or ".wrapper" or ".button" since there's no namespacing, right?
Keep in mind these components might be arbitrarily nestable. Maybe my elements can be a child of theirs? Maybe theirs can be a child of mine? Can I opt out of the cascade? Should I?
Maybe we could all use the Shadow DOM? I don't really have control over what third-parties do, but let's say I dig into their implementation (what fun) and choose only ones that use the Shadow DOM. Now I've massively bumped up the complexity and ensured my document can't render without JavaScript; lots of user-agents go right out the window and see nothing.
Let's reduce it to the simplest possible case: you and I are working on the same website, but I'm responsible for the header and you're responsible for the footer. We even have our own separate .css files. Yay, no merge conflicts.
Can you and I safely write our selectors without coordinating with each other?
(If you think the answer is yes... you're wrong.)
Now add a few dozen more team members and several third-parties who we in fact CANNOT coordinate with.
Everywhere you turn there are tradeoffs and half-solutions. Turns out "Just Do X" is not very helpful. Thus, I don't blame people at all for developing their own solutions to scaling CSS - like OP's framework.
> A selector is not not a variable or a function. CSS has functions (e.g translate) and it has variables, which are both distinct concepts in the language from selectors.
Congratulations, you have attacked the analogy rather than the argument.
So in your head, the analogy is not a big part of the argument? I'd accept your congrats, but I really have not earned it.
The whole idea of comparing CSS to general purpose, Turing complete programming languages is surprisingly stupid. CSS has a very specific, narrow goal: styling HTML elements.
> So in your head, the analogy is not a big part of the argument?
The analogy is decoupled from the thing it analogizes, and refuting the analogy refutes the thing itself about as much as burning a picture of the thing burns the thing itself.
> The whole idea of comparing CSS to general purpose, Turing complete programming languages is surprisingly stupid. CSS has a very specific, narrow goal: styling HTML elements.
Right, so, you still don't like the analogy but again don't address the argument.
> A selector is not not a variable or a function. CSS has functions (e.g translate) and it has variables, which are both distinct concepts in the language from selectors.
That misses the point. They're identifiers scoped to the entire document - the same way global variables and global functions are identifiers scoped to an entire program.
The point is, comparing CSS selectors to the functions or variables in other programming languages is silly, cause guess what... CSS actually has functions and variables!
> in which case you're limited to what that framework provides (and it won't be as robust as any non-wc framework).
Is there something inherently wrong with wc that stops robust frameworks being built on top of it? Have you tried actual framworks built on wc like Lit for example.
No, I'm saying that if you use a non-wc framework, it will be more robust than any wc framework. Not because it's non-wc, but because it's more mature. Lit is mature, but it's not more mature than React, and it definitely has less contribution to it than react.
It's definitely possible to make a comprehensive web component library. Something that could compete with React. But, as far as I know, it doesn't currently exist (and would be a huge task to achieve with... no discernible reason to do it?).
Sorry but you're mixing up terms. A "web component library" would be something not compete with React, because React is a web component framework. The frameworks is whats used to build the component libraries e.g I think material design has one built on top of React.
I'm sorry you're having a hard time understanding. "library" just means "package of code". A framework - of any kind - is a library. Not all libraries are frameworks, but a web component framework would absolutely be a library. And since it is a library of web components, it can be called a "web component library", correctly. A library of react web components is also a web component library, for the same reasons.
I'm not mixing anything up, and I'm not being unclear. I could have used the same terms, but that I didn't does not make me incorrect. You're just splitting hairs. I'm sorry that seemed like it was worth your time.
How about: maybe some things lie outside of the purview of empiricism and materialism, the belief in which does not radically impact one's behavior so long as they have a decent moral compass otherwise, can be taken on faith, and "proving" it does exist or doesn't exist is a pointless argument, since it exists outside of that ontological system.
I say this as someone who believes in a higher being, we have played this game before, the ethereal thing can just move to someplace science can’t get to, it is not really a valid argument for existence.
The burden of proof lies on whoever wants to convince someone else of something. in this case the guy that wants to convince people it likely is not real.
> "The human brain is mutable, the human "soul" is a concept thats not proven yet and likely isn't real."
The soul is "a concept that's not proven yet." It's unproven because there's no convincing evidence for the proposition. By definition, in the absence of convincing evidence, the null hypothesis of any proposition is presumed to be more likely. The presumed likelihood of the null hypothesis is not a positive assertion which creates a burden of proof. It's the presumed default state of all possible propositions - even those yet to be imagined.
With the actual layout models, I see it more of an evolution thing. For someone starting on CSS today, you do not have to learn all 8 now if you don't want to, just master the grid. It was designed to be the last one to rule them all.
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)?
It's a (computer) language, it is also a formal language. A programming language is a language in which you can write programs, which are descriptions of algorithms. You don't describe algorithms in HTML, hence it is not a programming language.
> 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.
HTML5 refers specifically to the latest, living version of HTML, the markup language. CSS and JavaScript have their own specifications, and version numbers. The term your looking for is the web platform [1].
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.
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.
nah. the technical semantics is absolutely the point when we're talking about code. HTML is thing distinct from javascript and CSS and it's very useful to be precise about it in our context.
> It's a source of stress to add a class to the system with a simple, short and readable name and have to worry it is used someplace else.
That is the whole point of CSS classes: re-use. A CSS class is not meant to be used in only one very specific place. For that, you can select an element's ID or an elements HTML path, to style just that one thing.
> Being an insane brand means literally nothing if people can trivially switch to competitors, which they can.
Logically speaking, yes it is easy to switch between OAI and Gemini, or Coke and Pepsi. But brand loyalty is more about emotions (comfort, familiarity,..) rather logical reasoning.
A selector is not not a variable or a function. CSS has functions (e.g translate) and it has variables, which are both distinct concepts in the language from selectors.
> No modules or namespaces. CSS is not supposed to be a turing complete general purpose programming language. Why would you need namespaces and modules to style up HTML tags?