Hacker News Reader

>Those that tend to hate the cascade tend to fight the browser a lot, whether they realize it or not. Generally speaking, they want things to work a certain way (IE everything in isolation) and prefer to think of styles isolated bits.

So, wouldn't that be the browser fighting them, then?

They want something specific, and the broswer forces a paradigm upon them that they don't want.

They are the humans and the browser (well, the styling language of the browser) is the tool that should accomondate them, not the other way around.

This is a sane argument. I have no objection to it. Both things are true, in a sense.

It really depends on how you view the browser, IE should browsers be more adaptive to certain paradigms or should it set a reasonable paradigm and enforce it? I don’t know that there is a 100% right answer in this case, though they have moved to create better hooks for some forms of isolation (e.g. layers, scoping) but they fundamentally haven’t walked away from the cascade aspect.

It’s converging the two paradigms, for sure, but as I said, I don’t think either is wholly incorrect or correct.

Now if you wanted my opinion on the whole thing, I think the cascade is a fundamental element to be leveraged not avoided, but that’s me.

If someone picks up a hammer and struggles to pound screws in with them, it’s not the hammer that’s defective.

I don’t think CSS is the perfect tool for all browser-based styling but it’s the tool that’s there and it’ll probably work a lot better if you use it the way it’s intended to be used. If you want a screwdriver instead of a hammer… you have options (don’t target a browser, propose an alternative to CSS, use something that compiles down to CSS).

>If someone picks up a hammer and struggles to pound screws in with them, it’s not the hammer that’s defective.

If someone wants to hammer nails and they're given a blender, then the blender might not be defective, but it surely is not the right tool for the job, and it's imposed upon them.

Few people ever loved CSS. The majority always either hated it or learned to tolerate it. Most who do CSS today use a few different paradigms on top to make them tolerable like BEM, or use different transpilers to get a better language, or directly control styling from code, with CSS-in-JS libraries or like React does it.

>I don’t think CSS is the perfect tool for all browser-based styling but it’s the tool that’s there

Sure, I never denied its existance. Just its design.

I'd ask what you mean by "fighting the browser"- as generally, the number one way to ruin the performance of your CSS is to introduce depth to it. In general, keeping everything isolated regularly leads to better rendering performance.

Avoiding the cascade at all costs, for example. It can introduce a lot of unintended consequences.

Another anti pattern I have seen is the over use of media queries to force the browser to do certain things rather than embracing relative sizing constraints via intrinsic design and letting the flexbox and grid algorithms do most of the heavy lifting.

Here though I want to point out isolation is relative, as is the cascade. I think it’s important to leverage the cascade wherever you can but that doesn’t mean you are leveraging it from top to bottom per say, but it does mean thinking more wholistic about the context of styling

To be fair, there was a time that flexion did not exist and extensive use of media queries was the only way to create a responsive website.

Those efforts don't just dissappear quickly, since that was the only way available that worked across all browsers for nearly a decade.

Isn’t the browser responsive by default? The only issue I see is taking a layout built for refloyable documents and wanting to create applications and magazine-like design with it. Now it’s possible but it’s always more convulated than something like the tools available on platforms like iOS and Android.

Two camps I see are (1) those who want to hold the program in their head and be able to answer ever more obscure questions about the program using their understanding. And (2) those who try things until it works and then address problems as needed.

Do these two camps align with your two camps? Those who want control fight the cascade, others just fiddle with it until it looks good?

I don't mean to disparage either camp, because we need both approaches in the real world.

I don’t think these are two separate camps. Rather everyone has a value - let’s call it S - which is the maximum size and complexity of a program they can hold in their head. When the program’s size is smaller than S then they use strategy 1, when it’s larger they use strategy 2.

When you are a beginner your S is close to zero, as you gain experience you develop increasingly better compression to be able to grow your effective S, but it’s never infinite. There’s always some size program where you will devolve to strategy 2, and all programs tend to grow in complexity until they reach the point where nobody understands them, like some kind of complexity Peter principle.

> the second group often has a better grasp on keeping project maintainability over time in my experience.

That's probably in the eye of the beholder and a necessity. If you are all in on the cascades then you have to limit the depth of your page structure, otherwise it becomes impossible to predict how things will ultimately render or what the impact of a change at layer 3 will have on the rest of the page.

Technically speaking, isolation is perfectly possible with webcomponents.

Yes, there are more tools for isolation now, but you can’t wholly opt out of the cascade, even if it’s only local relevant, and I think that’s a good thing IMO