I got a maintenance job and there is a huge CSS file, in which I found a lot of things like the following:
.xxxx {}
That is, a selector with absolutely nothing in it. I think they are useless, but there are so many of them I start to doubt myself. Am I right that they can be removed safely? Or they actually are doing something and I should keep them?
I'd say it's probably the worst design in history (or a stronger contender to the title...) but it could be used.
See below:
document.styleSheets[0].cssRules[0].style.setProperty('color', 'red');
.randomClass {}
<div class="randomClass">No styling?</div>
You can acces, process, and even modify stylesheets. Even if a selector is empty of styles, that can be modified using code.
So, it's probably very safe to remove, but if you want to be 100% certain, either leave it there, or go through all possible code branches.
I have this weird scenario where I am moving code between two servers. In the original server everything looked ok, however in the second server the CSS breaks. When I looked into the code, it seems the css styles/classes and the html counterparts both have different casing and those too vary for the same class, so for example, html has class="main_menu" and css has .Main_Menu.
So obviously it should break, however in the original server it seems somehow the casing was ignored and for that reason everything worked properly. So any idea how that was achieved?
CSS selectors are already case-insensitive.
What you have to watch out for are HTML class names, as they are case sensitive.
See this question for a more detailed explanation.
There are two ways I will tell you to fix this, but both are, in essence, just slapping a band-aid on it and calling it good.
Change each HTML class to include the new CSS selectors
Run the entire stylesheet and HTML rules through a toLowercase() method of some sort.
Both of these will fix your problem, but neither are a very good solution.
The moral of the story is to use one case and stick with it. There is no point in going back and forth.
Sometimes !important is useful, for example if I have defined common style for all links on the site (selector, say, a), but when I want to override some rules I have the following choices:
Use more specific (longer) selector
Use !important
Which way is better and may be there are some guidelines?
Use !important very, VERY sparingly -- it overrides just about everything, even inline styles, and messes in a less-than-obvious way with the "cascade" of style rules that gives CSS its name. It's easy to use badly, and tends to multiply, particularly when misused. You can easily end up with a element with !important rules that you want to override, at which point you often have to either refactor your styles, or use another !important rule and contribute to the problem.
And once it's spread and you're using it everywhere, you're back up in the same situation you'd be in without it (difficulty in specifying elements specifically enough to override other styles), but you also don't have !important anymore cause everything else is using it too.
When faced with a situation where !important looks appealing -- or worse, one where it's already in use and spreading -- prefer to refactor your CSS if you can. (Frankly, if you need !important outside of a user style sheet, it's usually because your selectors are already way too specific, and/or you're not taking advantage of the C in CSS.) You'd do better to define your basic styles as close as possible to the html or body elements, and when you want to override, use as little specificity as you can get away with. That way, you have plenty of room to make changes. Usually there's a reason you want to override a style, and those cases can quite often be boiled down to a class name, a particular section of the page (read: a particular parent element), etc.
(The only real exception that springs to mind is if the styles you're overriding are effectively out of your control. (If you use a framework that has very strong opinions on how your page should look, for example, you might find it annoyingly difficult to override anything. I've worked with applications that actually inserted their own inline styles, where nothing but an !important rule could override them.) If you don't have full access to the code, overriding and refactoring can easily be more trouble than they're worth. You can use !important to claw back some control, as long as you're aware of the consequences.)
What i can say is that you should try to avoid it as much as you can because it means that there are redundant code, and give an indication that the CSS and styles are not well structured.
But in some cases its a must to use it and no way to avoid.
So just do your best.
Avoid it when you can as this is what most advocate but at the same time it is important.
Have a look at:
The importance of !important in CSS
I didn't see anything on here about it with a quick search, if there is let me know.
Here is an example of a CSS selector I'd write.
div#container div#h h1 { /* styles */ }
div#container div#h ul#navi { /* styles */ }
div#container div#h ul#navi li.selected { /* styles */ }
I write all my CSS like. This allows me to stop from having styles floating around and I can technically re-use the same class name easily. For instance, I might use .selected on multiple elements across the site.
I also specify the element type (div, ul, etc) before the class/id unless the style is used for multiple elements. I also specify the element before id's even though there will only ever be one id because it allows me to know the element easily when reading my CSS. For instance I'll know right off the bat that em#example will most likely have a font-style of italic.
This isn't a question about CSS formating, it's about writing selectors.
I'd love to hear opinions on this approach, as I've used it for years and I'm reevaluating my stying.
Although it's somewhat off topic I also write my selectors like this for selector libraries (like jQuery for instance). Although I haven't looked into jQuery's internals to see if there is performance issue with specifying the element with an ID.
I think it really depends on what the selector is for.
Almost every site has one or a few style sheets that "skin" the site - fonts, text colour, link colour/hover, line spacing, and so on, and you don't want these selectors to be very specific. Similarly, if you have a component or element that's reused in many pages and always needs to look the same - like let's say the tags right here on SO - then it's going to be a pain to maintain if you use selectors based on the ID.
I would always use the ID in the selector if it refers to a specific element on a specific page. Nothing's more frustrating than trying to figure out why your rules don't seem to be working because of a conflict with some other rule, which can happen a lot if everything is classes. On the other hand, I think that nesting the IDs as you are (#container #h) is redundant, because the purpose of an ID is to be unique. If you have more than one element with the same ID on the same page then you can end up with all sorts of problems.
It does make the CSS slightly easier to understand when your selectors provide some idea of the "structure" that's being represented, but, to be honest, I think that goes against the idea of separation of concerns. The #navi might be moved outside the #h for perfectly legitimate reasons, and now somebody has to update the style sheet for #navi, even though nothing about it has changed.
A bit subjective as Darrell pointed out but that's my two cents.
While the question is a little subjective I have to say I agree with your thinking. I think defining the element before the selector is clearer when reading the code and it is less error prone.
Simple question, and probably reflects my inexperience with CSS, but...
When creating a style sheet I like to explicitly specify the '*' wild card, so:
*.TitleText {
instead of just
.TitleText {
I find it reminds me that TitleText is applied to "any" tag, and can be overridden by a subsequent h1.TitleText. Maybe I just like this because for the longest time I didn't get that whole CSS selector concept properly and when I realized that the second (above) was just shorthand for the first, a lot of things "clicked".
Is what I do bad practice, good practice, or neither here nor there?
I don't know whether it's good or bad, but I've been doing CSS work as part of web app development for several years and I've never seen anyone use the * character.
While both are equivalent in terms of the style outcome, there are a couple other factors to keep in mind.
Using * increases the file size
If you do not use a CSS minifier (gets rid of unneeded data such as extra whitespace) that removes unneeded asterisks, using * every time a tag is not specified leads to quite a bit of extra characters in the file which will cause longer loading times (and more bandwidth usage). While I wouldn't go through a large file and remove asterisks already in place (unless you really have time to do so and love tedious tasks that could cause a bug you won't discover for years), I would suggest not including unneeded asterisks when writing new styles and removing unneeded asterisks when editing old styles.
Using * can lead to confusion
Using * when it's unneeded can lead to confusion, especially when someone new is working on the project and has not dealt with * being present when it's not needed (which is quite common).
Example
/**
* This matches an element with the class `alert` within
* any element within an `article` element
*/
article * .alert { /* ... */ }
vs
/**
* This matches an element with the class `alert` within
* an `article` element
*/
article *.alert { /* ... */ }
If there is 100% consistency in a project (and the style is known by all individuals working on the project), then the first example would never happen (it would be article * *.alert instead). However, this is an ideal situation and will more than likely fall apart after a few generations of developers (people love to use their own style instead). So, even if you have a consistent style, a new hire may come in and write in their own style for a short time, or read the current style incorrectly and produce code that doesn't match the selectors (or vice-versa). Therefore, I'd suggest sticking to the standard that I have seen the most (read: exclusively) in projects and websites:
Do not use the asterisk if it's not required.
A quick look at the source of some well known websites (e.g., Facebook, Google, Yahoo, etc) will show that they don't use asterisks unless they have to (even in their non-minified styles). You can also take a look at some open source projects on GitHub.
Conclusion
The asterisk should only be used if it is absolutely required (e.g., body * p to match paragraphs that have a parent other than body). Not only is this the unwritten standard (and less likely to cause confusion), but it also decreases the file size of style sheets, which increases the loading speed of the website.
Personally, I tend to only use the * when applying a rule to all tags. It is redundant in the case of *.class{}, but useful in the case of .class *{}.
I have read in a few places, but not verified, that the * selector can impact performance. It's not something I use unless I need to, as I generally prefer to be a bit more explicit, but that's just a personal preference.
It's neither good or bad, but it is (entirely) redundant.
EDIT: Actually, methinks it bad, 'cos it's potentially confusing (as in to humans, not parsers).
According to the CSS specification:
5.3 Universal selector
The universal selector, written "*",
matches the name of any element type.
It matches any single element in the
document tree.
If the universal selector is not the
only component of a simple selector,
the "*" may be omitted. For example:
*[lang=fr] and [lang=fr] are equivalent.
*.warning and .warning are equivalent.
*#myid and #myid are equivalent.
Therefore, .TitleText and *.TitleText are equivalent. It is highly unlikely that any implementation would have a performance consideration for *.xxx which is not there for .xxx.
This then boils down to a question of style. And since the considerations of style raised by the other answers seem to be to be largely moot, I believe I will go ahead and continue explicitly specifying the *.
I don't think it matters, but none of the examples I ever saw when I was learning used that wild card format, so I learned to do without the asterisk.
Also, none of the tools that generate CSS do it that way, so by using the asterisk, you risk an automated tool wiping out your format if you ever choose to put your CSS into such a tool.
Just for consistency with most other web developers, I'd probably recommend doing away with the asterisk so you don't have to deal with another developer asking why you've put an asterisk there.
I think the * is implicit, so they do the same thing.
I am not sure, but it might cause some problems if you do it like this:
span.style { color: red; }
*.style { color: blue; }
The * style will probably override the span style. I could be wrong though since span.style is a more specific selector.
I think it is pretty funny you do that, even though I totally get why! You're using DOS prompt/shell syntax with your CSS. In the end you might have been confusing yourself further thinking about it that way, since in a Shell you're looking at the file extension but in CSS it is actually mapping to a class.
So what I mean is, it works for class selectors, but kind of falls over for ID selectors. For example:
span#id { ... }
*#id { ... }
...and it no longer looks like Shell syntax. :) Personally I wouldn't do it the way you're doing it, because it might be confusing, but I don't think you're breaking anything.
That would be redundant, assuming * means 'every possible thing in the world' not having a * would also mean the same. I normally use *{margin:0; padding:0} in undo.css to reset the margins and paddings , but never as a pseudo selector.
I have never seen anyone use the wildcard like that, and I suspect it will be picked up in preference to just specifying the class. Other people modifying the styles maybe forced to keep using that syntax. That is if they figure why their classes are not working.
*.class will overwrite span.class even if span.class is more important.
I see no practical use for *.class, overwrites should be done with !important statement and only sparsely.
The only reason i use * is to remove all padding and margins, i actually always do this its the first css statement i write down always :).
There are also quite a few css hacks based on "* html" not working in IE6 and lower.
I'd flag it as bad practice.
In terms of the CSS specs, your two examples have identical meaning. However, there are potential issues with it in practice. The biggest, that I can see, is that some browsers may mistreat * in terms of rule weighting and so potentially throw off precedence (though I do not know of any, off the top of my head, that do this — it just wouldn't surprise me). It is also widely held, though I can't quote chapter-and-verse at you, that class selectors should always include a specific tag name for performance reasons. It is apparently faster to apply a class selector with a tag name (span.foo) than without and faster to apply an ID selector without a tag name (#bar) than with.
EDIT: This is pointing out that there could well be a performance issue. Some people seemed to think I was some sort on way out there rant...
While I don't know for certain, I'd like to give a word of warning! Consider the following identifier:
div#foo a.bar {}
I hear that jQuery for example, which utilizes css, would in the above example traverse the DOM looking for divs first, then check to see if they have an id of #foo, then for an A tag before finally seeing if it's classed .bar.
My concern with the * is that the browser may traverse the DOM looking for ALL tags and then look for .bar, rather than inherently just looking for the attribute of 'bar' - that's two sweeps of the DOM rather than just the one. Might be an extremely minimal difference, but if your syntax hits the airwaves, that's a few more solar panels we need to install.