This is rather like famous "Go To Statement Considered Harmful" dictum of lore, and its variants in other contexts: the key takeaway shouldn't be that we should never use these constructs -- rather than we should be circumspect about using them, as they tend to have hidden side effects.
Totally agree, but in this case I can say for sure that the benefits of using IDs are so impractical, that with no doubt I will add a class name to the target element style the class not the ID.
In my development practice I've found that messing CSS with IDs don't help scale your app ( you can hardly override them ), they are also subject of all the reasons stated here and in the article ( bad performance, global scope introduction, ... ).
The only reason to style IDs would be if I happen to have an old theme that people styling it were using IDs.
I totally don't support styling IDs ( or using !important - which basically is on the same page ).
Comments
This is rather like famous "Go To Statement Considered Harmful" dictum of lore, and its variants in other contexts: the key takeaway shouldn't be that we should never use these constructs -- rather than we should be circumspect about using them, as they tend to have hidden side effects.
Totally agree, but in this case I can say for sure that the benefits of using IDs are so impractical, that with no doubt I will add a class name to the target element style the class not the ID.
In my development practice I've found that messing CSS with IDs don't help scale your app ( you can hardly override them ), they are also subject of all the reasons stated here and in the article ( bad performance, global scope introduction, ... ).
The only reason to style IDs would be if I happen to have an old theme that people styling it were using IDs.
I totally don't support styling IDs ( or using !important - which basically is on the same page ).