Hacker News Reader

Comment by gizmo | Hacker News Reader

Every CSS rule is effectively in global scope. And as the complexity of web apps increases regression testing becomes a bigger and bigger challenge. Being able to insert components multiple times and not having to worry whether an innocuous CSS change can result in "spooky action at a distance" really helps.

I think this is a reversal of the best practice of complex CSS class hierarchies. Having flatter and fewer CSS classes and more inline CSS will result in redundant style information, but having fewer CSS rules apply to nodes is a win overall.

View on HN

Every CSS rule is effectively in global scope.

They are, and that's why sibling and child selectors exist. If you only ever define simple classes with no thought about how they'll work in the overall app then you're in for a bad experience with styles cascading to things they're not meant to affect. If you actually use CSS the way it was designed then you have complete control over exactly what styles are applied to which elements.

A good rule in component based development is to define a class name for the component and use ".unique-component-class-name > .class-for-things-in-this-component" to limit the application of styles to that component. This takes a bit of discipline but it's pretty obvious when you get it wrong.

Yes indeed. Say you're creating a new component, and this new component will contain (among other things) some existing component, but the existing component needs to be styled slightly differently in this particular context. How do you deal with this with inline styling? Threading around this information between the components in JS to make the old component aware of the new one seems clearly wrong. A good old-fashioned style sheet handles it easily and relatively cleanly.

I've seen that inline CSS seems to be the latest trend, but I haven't really read up on why myself. Is this post really the current thinking? I find it completely uncompelling.

the existing component needs to be styled slightly differently in this particular context.

See my other comment in this thread (https://news.ycombinator.com/item?id=24221241) for how I'm tackling that sort of problem at the moment. tl;dr Work out what the dev should be able to override in the style at runtime and make it a CSS var that's set inline in the component. As I said there, it might not be the best approach especially in very large apps, but it does seem to be working well for me.

The rule we've come up with is essentially "don't do that". But if you need to, instead of having styles cross boundaries, the inner component should be configurable (either by making two versions of it, or having something like "mode=large" as an abstraction over the CSS it needs to apply to itself).

    Every CSS rule is effectively in global scope.

We had this problem in programming forever. These days, you can put your function in a class in a namespace ... still the namespace sits in global scope. But we never came to the conclusion that we should make all code inline to solve it. Fortunately.

So if you make a CSS rule to make links in your userlist red:

    .gizmosUserlist .name a { color: red }

Then yes, it will apply to other .gizmosUserlist instances.

Shadow DOM is a way to prevent it if you want.

Personally, I think it is a good thing, that you can make all links in all gizmosUserlists red if you like and can target a specific one with a more specific selector if you like.

the inline CSS is not redundant, because redundancy only applies to the source, not the output. And in a component world, the source is the js/compiler/component source code, and the output is what's on the page. I wouldn't care if the css is repeated for every component that's rendered, as long as it's clear from the source code of the component (or js source).

Nobody bats an eye when a compiler unrolls a loop, and you get N copies of the same code in assembly. In the same sense, nobody should care how clean the "assembly" of the web is (CSS+HTML).

I'll believe that CSS+HTML is the "assembly of the web" once I have to touch them as little as I have to touch the output of my C++ compiler or Java bytecode. Right now, any web developer has to be very comfortable with debugging HTML and CSS issues, whereas it's entirely possible for a competent Java developer to know literally zero about bytecode.

a proper C++ or java dev will examine the byte code if stuff is broken (if required), just the same as they would when writing react apps. You wouldn't normally need to examine the output the html or css when you use a framework as high level as react (or really, most web component frameworks).

That argument falls because it was never designed that way. If you want broad browser support and careful testing of edge cases you can't threat it that way, even with WASM you likely won't escape it.

At some point people should care because most applications delivered over the web perform by the rules of entertainment meaning that if it takes too long to load or render people leave and look for their entertainment elsewhere.

You have to really try for that to happen.

Reply on news.ycombinator.com