Orthogonality and CSS in JS | Hacker News Reader

Orthogonality and CSS in JS

benmccormick.org

38 pointsben33618 comments

I think the specific problem of CSS & JS (rather than the more interesting 'separation of concerns' conversation) is partly due to CSS itself not being fully separatable.

It's used for style & design, but also for functionality. In some ways, ideally, function related CSS would be stored with the module, but site-level design CSS would be separate.

Additionally, CSS by design has greedy selectors. If I put in a:

   a { text-decoration: none; border-bottom: 1px solid pink;}

in my site.css, it will muck up any components which use an <a> tag, but don't specifically re-write the border.

Are there good solutions to this?

I kind of feel in some ways, with SPAs and web apps being a thing rather than simple pages, we need a new way of defining styling, which then compiles to CSS, figuring out the correct over-rides along the way.

Some solutions to the greedy css selectors are how web components can limit scope to certain elements. Angular 2 has some level of emulation for this. CSS modules also tries to achieve something similar through scoped classnames.

> It's used for style & design, but also for functionality

So true.

I once searched days for a broken event handler in JavaScript, just to find out that somewhere deep inside a CSS file, someone disabled events for the element.

Didn't even know CSS had that power.

I really didn't know CSS could do that. http://caniuse.com/#search=css%20pointer-events for any one whose mind was blown by this.

The idea seems to be, that designers have more flexibility.

You can layer elements how you like and then, in the end, disable all the elements "in the front" of the element that you want to have "clickable".

Until one uses it, it might be hard to realize how incredibly useful it is. From both CSS and JS perspectives. I rarely use it simply because of older IE lacking support.

> inside a CSS file, someone disabled events for the element.

I never heard of that. I just looked up CSS pointer-events [0], is that what you're referring to or are there others?

[0] http://caniuse.com/#feat=pointer-events

Yes, this disabled the clicks on an element.

http://www.slideshare.net/stubbornella/object-oriented-css/2...

The first simple thing is to avoid element level selectors, stick to class names as much as possible. Another is to namespace your CSS.

Element level selectors are so often demonized and having written quite a bit of CSS in my life, I have come to appreciate how easy it is to write and maintain CSS when you actually use those element level selectors mixed with relationship selectors ( >, +, ~,) and attribute selectors.

I don't demonize them, I use them too. But if you rely on them too much then eventually it causes problems. Especially on a large project that grows over time in CSS and HTML.

Attribute selectors are indeed handy and are on par with class names in my suggestion.

> How do we define module boundaries?

The question should be "How do we define module interfaces?"

Take Bootstrap as practical example.

How does it "interface" with your code?

CSS classes of course!

But wait!

If you use its "components" it also interfaces via HTML elements.

If you use even more of it, it also interfaces via JavaScript.

But even if you just use their CSS, how to switch to BlazeCSS, for example?

Well, you kick out Bootstrap, include BlazeCSS and ... you replace the CSS classes in your HTML elements, done...almost, sometimes you even have to fix up the HTML.

Hopefully this gets better with Web Components.

The problem we have right now is that CSS stuff is top down, while it still requires heavy customization from the bottom up (some styling only work for specific element types, etc.)

With Web Components, we can have custom elements "at the bottom" which are transparent in their child element usage, and can let CSS frameworks target them from the top. V1 uses ul/li for tabs, V2 uses divs all the way, but the users just includes the css/js and the used tag <fw-tabs> stays the same.

features are concerns too, now you have files related to your feature separated by not only file but folders and drives.

maybe there should be a file editor that's feature aware but also separates those file for you.

I'm not sure, does the article author recognize that the quoted tweet [0] is satire? The subsequent thread should make it clear.

[0] https://twitter.com/BenLesh/status/812092408519413761

I have followed Ben McCormick for a while, I assure you he knows that is satire.

Ha, yes I knew it was satire. That is always hard on the internet though :)

Gather together the things that change for the same reasons. Separate things that change for different reasons. Sometimes that means that splits cleanly by language boundaries, but what should we do if it doesn't.

Reply on news.ycombinator.com