Hacker Newsnew | comments | show | ask | jobs | submit login

I recommend not using IDs due to selector specificity and the scenario where you most likely will run into annoying #ID issues and think about using `!important`.

I don't think it's absolute blasphemy to use #ids, but try to never use them. Think of it that way. I tend to use them only for #js-functionality hooks, which is also a good-practice to tell someone "don't freaking change this ID or you break the JS."

Tips from http://www.betterfrontend.com




I'm obviously lacking in imagination here. How would using an ID for styling a "clearly one-per-page" element lead to problems? I'm thinking of things like the main page title, or some sort of primary navigation block. The whole point there is that I want the specific rules for those elements to override the defaults, right?

-----


It may be "clearly one-per-page" now, but it may not be. You don't really gain anything by using an ID. Keep the selector specificity simple so it doesn't bite you in the ass and cause a refactor.

.page-wrapper .page-main %article.main

There's no difference using that to

#page-wrapper #page-main %article#main

Psuedo example, those can be mix and matched with classes and IDS but doing so just complicates the selectors and the cascade.

There is of course exceptions and things that may just make total sense, but overall, it leads to complications. You don't gain any real benefits unless it's a JS hook for #id selector performance.

-----


For example, styling the same unique block based on context. If it's a mainpage, I want it red, otherwise it's green.

-----


I follow the same line of thought to an extent. I like to put an id on the body tag for global navigation purposes, but aside from that I keep the id for js work.

-----


Yep, exactly this!

-----


Does anyone else get kicked to github from the Betterfrontend website? Probably supposed to be a button but ended being a frame-breaking Github 404.

That's not very nice.

-----


I'm experiencing that as well - it looks like any (unofficial) github buttons need to have their domain changed from github.com to ghbtns.com. The commit message seems to confirm this.

[0]: https://github.com/markdotto/github-buttons/blob/master/READ...

-----


Thank you, it's been fixed! Clear cache if you still have issues.

-----


Thanks. That wasn't nice how they did it. Now it's leading to a caching problem for users who already viewed it. I'm not sure what to do. Fuuuu.

Thanks for the heads up. It should be fixed now. Clear cache the "hard" way if you have to.

-----




Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: