2

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?

12 Answers 12

7

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.

1
  • I used to use it for global reset (so did everyone else I know), but then that thing about impacting on performance came about (which I've never seen verified, but does make sense).
    – da5id
    Commented Dec 17, 2008 at 23:04
2

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.

1

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.

2
  • I find myself using the * selector in combination with the adjacent sibling selector + regularly. It helps in issues like clearing floats where you may have a variety of elements below the floated one. i.e. div + * { clear:both; }
    – different
    Commented Dec 17, 2008 at 23:11
  • "*.class {} and .class * {} are two entirely different things" - yep - that's the point....
    – seanb
    Commented Dec 26, 2008 at 22:35
1

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).

1

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 *.

0

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.

0

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.

2
  • span.style have higher specificity then *.style; * does not affect the specificity of the selector. So: on span elements with the class style the rules from span.style will override rules from *.style.
    – andreas
    Commented Dec 17, 2008 at 22:59
  • PS: I like your moniker - WillCodeForCoffe :) Commented Dec 29, 2008 at 22:53
0

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.

0

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.

0

*.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.

1
0

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.

-1

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.

2
  • @Steve: In your example, where would the * go? My question is simply about using a lead asterisk, which is semantically identical to it's shorthand equivalent without a lead asterisk. Commented Dec 18, 2008 at 0:57
  • It would be most helpful if you would add a comment if you think the answer is wrong! I think you're doing the original poster a disservice by marking this answer as bad. Commented Jul 1, 2009 at 0:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.