tags:

views:

582

answers:

12
+1  Q: 

CSS Selector Style

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?

+5  A: 

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.

ahockley
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
A: 

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.

Grant Wagner
A: 

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.

WillCodeForCoffee
`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`.
cic
PS: I like your moniker - WillCodeForCoffe :)
Software Monkey
+1  A: 

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.

seanb
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
*.class {} and .class * {} are two entirely different things...
Andrew G. Johnson
"*.class {} and .class * {} are two entirely different things" - yep - that's the point....
seanb
A: 

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.

questzen
A: 

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.

BeWarned
+1  A: 

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

da5id
A: 

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

Martijn Laarman
Actually, the * selector is always less specific than an element selector: http://www.w3.org/TR/CSS21/cascade.html#specificity
Gareth
A: 

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.

Ben Blank
+1  A: 

Such things are for your personal choice, see what feels the most comfortable to you.

Please note that

span..style { color : blue; }

might not work (try that out) where

span.*.style { color : blue; }

just works.

TomWij
A: 

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.

Steve Perks
@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.
Software Monkey
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.
Steve Perks
+1  A: 

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

Software Monkey