undefined | Better HN

0 pointsspion11y ago0 comments

Its definitely not a problem with the person. That person may be working on a, say, date picker component (or something equivalent that is not yet covered with HTLM5) that provides minimal styling (with the ability to override it). They don't even know all their end-users.

They decided to use the name `.calendar`. Was that safe? Nope, their user #3 had an "upcoming events" calendar using the same class name that totally breaks when the datepicker CSS is included on the page. Should they make sure to prefix all their class names with their name? What if someone else with the same name also decides to do this? What if they make a new alternate datepicker, must they add the version number/descriptor too?

This is probably one of the reasons why we don't yet have separate reusable components with minimal overridable styles for the web (instead we have only entire pre-styled frameworks)

If styles had scope and HTML had a way to import them, we could say `import calendar from "path/to/file"`, then use the calendar style on our component and be sure that there is no way its going to leak outside of outside its lexical scope. Web components will fix this (html imports, scoped stylesheets). But web components aren't ready yet.

Let me ask you a different question though: is there a reason for the "oh god, not JS" sentiment? The solution is potentially even simpler than CSS: styles are defined as variables containing JSON objects, they're exported as a module, and can be imported and used by any component and mixed freely. No cascading/selector rules, no priorities, no overrides. When HTML CSS and JS share scope, things become much simpler.

0 comments

3 comments · 2 top-level

talmand11y ago· 1 in thread

Your example only shows to me problems in the person and/or the team doing the CSS coding. It is certainly possible to namespace CSS if guidelines are established at project start, just like with coding any other language. What happens if two developers namespace their class in the same way?

The reason I would say no to a JS solution is simply because you are adding yet another step to the render of the page, more code for the browser to parse, and in the end results in the same issues you started with as they are only masked. This is just an attempt to make something work in a fashion it was designed to do. I'd rather fix the problem at the source instead of adding another layer to the problems.

But in the end, no matter what fancy JS code that comes up it still has to render out the CSS exactly as the browser expects it to be. That means that whatever this thing generates, people who know CSS can hand-code the exact same thing. Any problems that exists for CSS exists in this as well, it just masked so it's not readily apparent.

spionOP11y ago

But what if there isn't a single cohesive team developing the website? There are no globally established practices for CSS name-spacing and there are multiple ways to do it (based on what tradeoffs you're willing to make).

See font-awesome for an example of what I mean by library (yes, they prefix everything with `fa-` which is fine until the bootstrap team comes up with a FizzActivity widget in bootstrap, which you wont be able to use together with fontawesome)

What happens if two developers namespace their class in the same way in JS? Well, with CommonJS this is pretty much impossible (import by path), and even without CommonJS there is no incentive to do it as you can easily pick a huge namespace without it affecting anyone. Just adding `var shortName = long.namespace.containing.shortName;` fixes the long name without that short name having effects anywhere else in the code or any of the inner functions (components) you may call, because... lexical scope.

And sure, we can hand-code everything in assembly too - after all thats what compilers do anyway. But that doesn't mean that the higher level language has all the problems that assembly has. A tool like this can do a lot of the job for you, by generating unique names and letting you refer to them via any (variable) name you like.

Sakes11y ago

I do have a reason for saying "oh god not JS". In my experience, the biggest reason people try and solve CSS issues with javascript is because they don't fully understand CSS and how to structure it in a maintainable way.

I used to hate CSS. I still think it is very flawed, just google how to center something and watch all the blogs pop up.

But rather than cursing it the rest of my dev days, I took the time to learn it and structure it properly. I now never spend longer than a few minutes trying to resolve a css bug.

Ideas like the OPs only procrastinate someone's true problem, which is they don't know how to properly work with the technology that they are forced to work with.

j / k navigate · click thread line to collapse