What's the name for the CSS style / best-practice that WordPress uses?
I ask because, with PHP, we have Pear style, GNU style, K&R, etc... Is there any keyword or name for the css style used by WP?
Is there a nomenclature for css formatting conventions at all?
ie:
.this,
.and-this {
display: none;
}
rather than:
.this,.and-this{display: none;}
Drupal has CSS formatting guidelines as well. But, I'm unable to find any resource except maybe this one which gives titles to different css formatting conventions in any way.
There is no special CSS that WordPress uses: it just employs regular old CSS like any other site. That page you linked to is showing preferred syntax conventions. I just skimmed through the page and the examples of CSS syntax that they don't like were marked incorrect ... even though most would actually function just fine from what I can tell. A little misleading.
Regarding your two snippets above: those will have the same results (though in the second one you need a space after the comma: .this, .and-this{display: none;}). The first snippet referred to as human-friendly or human-readable, with extra whitespace and line breaks to make it easier for people to read and write. The second is simply minified for faster processing by computers, which removes whitespacing and line breaks.
It should be noted that this principle of minification from your example really only applies when scaled up to hundreds/thousands of lines of code and doesn't make much of a difference with less than that.
I'm working on some refactoring of legacy code to move styles to a stylesheet file from the html. Our build process runs the stylesheet css files through the YUI compresser minifier. Which in its efficiency strips out empty .selector { } styles see - YuiDoc's No empty declarations section.
The issue arises when in some places the code finds and modifies stylesheet rules, but it can't find the rules that have been minified/stripped. Is there a noop rule they would not effect any rendering but would keep the effectively empty rule in the stylesheet?
According to W3C CSS2 Specification
In CSS, identifiers may begin with '-' (dash) or '_' (underscore).
Keywords and property names beginning with -' or '_' are reserved for
vendor-specific extensions
So you could create your own property say for example -custom-noop: noop; without the validator complaining too much. You might however have some problems with older browsers ignoring other rules in a block if you use this.
Edit:
You might also have some luck with this syntax:
.someclass{
/*! Keep Me */
}
Comments like this are kept in after compressing so it might work for keeping the block the comment is inside. Note that after compression the ! is stripped so you will need to add it back each time you compress it.
What does the following CSS do and is it valid?
h4 {
width: 83%;
#width: 75%;
}
It is not valid. #width: 75%; is a syntax error, since # isn't used in CSS property names (although it is used in CSS selectors, to select elements with specific ids). Most browsers will ignore it (hopefully) and only the first rule will be applied.
It might have been someone's attempt to write a CSS comment. This is the valid way: /*This is a comment*/
Edit
I would suggest using a CSS reset file to account for browser differences.
Apparently there's a hash hack which looks exactly like the one you have, but I have no idea what specific browsers the author is trying to target or filter since there aren't any reliable results as to what browsers apply the rule and what don't (that looooooong list of user agent strings isn't what I'd call reliable; I'd call it inconsistent).
In any case, a hash is not a valid character for property names. I'm sure anyone that isn't IE will squarely discard it on sight.
using # before a property is applying different css style for ie 7. Is a css hack like *. To make it valid you can use conditional comments for ie.
From what I've read on http://developer.expressionz.in/blogs/2007/09/08/for-your-ies-only/ the hash-hack is intended to make a rule only visible to IE browsers. Since it is - as already mentioned by others - not a valid property, other browsers will ignore it.
BTW if the second width was not preceded by #, it would take width = 75% and not 83%. The last value always overrides all the preceding ones. As others pointed out, it could be a hack, which I don't know but most likely a syntax error.
To basically answer both your questions.
The # before the property targets IE7 & IE6 (and lower)
No, it's not valid.
I asked the same question, there's more info there that may be helpful to others:
Post: " CSS - "#" sign before property "
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why do /**/ comments work in stylesheets but // comments don't?
In CSS there is only one way to create comments: /* I'm a comment */
The problem is that it isn't nestable.
Why don't we have an alternative comment syntax like //?
I think the real answer is that CSS treats newlines like any other whitespace, so it wouldn't make sense to have comments that are terminated by a newline. This is from the CSS1 spec: http://www.w3.org/TR/REC-CSS1
A CSS style sheet, for any version of CSS, consists of a list of statements. There are two kinds of statements: at-rules and rulesets. There may be whitespace (spaces, tabs, newlines) around the statements.
Of course, this also makes a lot of sense in the context of minification, as mentioned here: Why do /**/ comments work in stylesheets but // comments don't?.
It's not in the specification, and because CSS is widely used and supported, adding it in is virtually impossible. You can't just publish a new specification and expect all browsers to magically support it.
Internet Explorer 6, a browser more than 10 years old, is still widely used, so you can safely assume that even if this addition to the specification were made, it'd take another 10 years to be supported enough to bother. The problem with //-style comments is that they don't scale - unlike new HTML tags, which can be safely ignored as long as the rest of the document makes sense, adding a //-comment will break unaware user agents.
So the short answer is, we don't have it because we don't.
If it really means that much to you, write a script or macro that converts //-comments into /* */-comments, and apply it before running your web application.
There is a way to have // comments in CSS. If you use Sass/Compass.
I really like using Compass, because it gives me everything I miss about CSS, like functions, variables and so on...
Here is the Compass home page and the underlying Sass-language.
Compass is very nice, because you just have a program running in the background that compiles your Sass-code into real CSS, so your workflow is exactly as normal, but in other files (SCSS or Sass) and with very extended functionality!
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.