Remove all id selectors from CSS

[turnerhayes]

Using id selectors (#foo) in CSS makes dealing with selector specificity a nightmare, since any selector with an id selector in it will always override a selector without one. We can always add a class to an element and use the class in the selector instead.

Note that this will become irrelevant if we end up using CSS Modules/styled-components/CSS-in-JS.

[knod]

Hmm, maybe I've been going about this the wrong way, but I've found classes to be really hard to work with at times to override semantic-ui-react styles. It's ended up in some pretty messy CSS.

[dylanesque]

Yeah, I've used some id's to override semantic classes, but I was rustier at using specificity to deal with those a few weeks ago. I can start working on these after I complete the last of the find and replace I've been doing with the inline styles. It also dawned on me the other day that certain dependencies like styled-components or emotion locally scope styles, resulting in far fewer necessary overrides and MUCH cleaner CSS.

[knod]

@dylanesque : Hold off on that till we've had some discussion about our next steps forward on this and some reasonable bounds. Also, don't remove id's in the js code itself. Some of those are being used by the js.

[turnerhayes]

I should amend my previous statement; I think having one top-level ID would be fine, so long as all selectors start with it, so that we can override third-party rules (as long as they don't use ID selectors, which they shouldn't).

So something like:

#App .myButton {
...
}

but not

#my-link {
  ...
}

or

#App #my-link {
...
}

I believe that should cover issues of overriding third-party styles.

[knod]

I'm not sure. 'semantic-ui-react' does include some id's, so I suspect their styles sometimes use them.

Also, for some page features, id's make sense. There are styles that are unique to a particular situation and shouldn't be abstracted. The fixed menu on the left is unique, for example. Do you mean we should remove id's that aren't being used appropriately? That is, ones that are able to be abstracted to a broader rule?

[turnerhayes]

I don't think there's really any reason to use IDs in CSS, apart from upping the specificity for cases like overriding third party rules. The fixed menu can be styled just as easily with classes, and helps make it more portable in case we have another page (or, potentially, another app that wants to use it as a component).

It may make sense to defer decisions about this change until we're sure of our styling approach; I understand there's been some talk about maybe moving to styled-components instead of CSS files, in which case this would be irrelevant, since everything would be classes anyway. But if we do stick with semantic-ui, then we should investigate its styles to see if they use IDs.