CSS-Tricks

syndicated content powered by FeedBurner

FeedBurner makes it easy to receive content updates in My Yahoo!, Newsgator, Bloglines, and other news readers.

Learn more about syndication and FeedBurner...

Current Feed Content

Web IQ Quiz

Posted: Wed, 20 Jul 2011 22:30:28 +0000

Pretty fun, well designed, interesting quiz. You gotta cough up an email and stuff to play any of the quizzes beyond the first one so you might get some random Windows Phone emails or something, but hey it's fun.
Direct Link to Article — Permalink

Advertise here with BSA
Web IQ Quiz is a post from CSS-Tricks
Classy Text Shadows

Posted: Wed, 20 Jul 2011 02:57:05 +0000

Tim Brown from Typekit shares some pretty classy CSS text shadows and drops some painter's terminology.
The Typekit blog exemplifies an idea I've been telling any company I've been involved with for years and years. Publish lots of interesting articles freely sharing information about your field. Especially if it's useful beyond the narrow scope of your business. It establishes you as an expert and is great for traffic. I guarantee this blog post alone will sell a bunch of Typekit subscriptions tangentially.
Direct Link to Article — Permalink

Advertise here with BSA
Classy Text Shadows is a post from CSS-Tricks
Everything About Radial Gradients

Posted: Tue, 19 Jul 2011 19:45:44 +0000

John Allsopp with a comprehensive article and updated tool for creating them. Funny how the vast majority of radial gradient examples are super in-your-face eye-seizure colors. I think it's because the "real world" uses for them are few. Subtle lighting effects are about all I can think of.
Direct Link to Article — Permalink

Advertise here with BSA
Everything About Radial Gradients is a post from CSS-Tricks
Little CSS Stuff Newcomers Get Confused About

Posted: Tue, 19 Jul 2011 02:24:39 +0000
If you're a pro, it's easy to forget the confusion you felt when you just started learning CSS. Just for fun, let's try and remember some of those little weird confusing moments. I'll start us out by listing some random ones I remember and have picked up on while helping others recently. Then you folks take it from there in the comments.
These aren't huge big things like broken layouts in IE or which vendor prefixes should you be using. It's the little fundamental stuff, like tiny differences in syntax that change meaning in a big way.
Tag qualifying
What's the difference between these two things?
```
.class    {   }
p.class   {   }
```
The first one will select any element with that class name. The second one will only select paragraph elements with that class name.
The first is more generically useful. The styling you apply with that class may be useful to multiple types of elements. Even if it's not today, it might be tomorrow. It's also faster for the browser to understand and apply.
It's a fairly rare case that you'd want to use the second example. It would only be if you wanted to re-use the same class name for multiple elements but have them to different things.
```
p.stand-out { background: yellow; }
span.stand-out { font-weight: bold; }
```
Selector order matters
Why are these so different?
```
.class div { color: red; }

div.class  { color: green; }
```
The first example there is very different because of the space character between .class and div. The stuff before the space and the stuff after the space select different elements. The first part is "select any element with this class name" and the second part is "select any div". Put them together with a space and you get "select any div that is a descendant of any element with this class name".
The second doesn't involve any of that descendant business. It's a tag-qualified selector like discussed above.
If the above CSS was the only CSS on the page, the results would be like this:
```
<div class="class">
   <h2>
      <div>Would be red</div>
   </h2>
   <div>Would be red</div>
   Would be green
<div>
<div>Would be black</div>
```
Why use ID's at all?
It seems like as far as CSS is concerned, using classes and using ID's is the exact same thing.
```
#id    { color: red; }
.class { color: green; }
```
It's just an attribute and it's a seemingly arbitrary difference in syntax depending on which one you use. The results are predictable:
```
<div id="id">Would be red</div>
<span id="id">Would be red</div>

<div class="class">Would be green</div>
<span class="class">Would be green</div>
```
You might have learned ID's are "supposed" to be unique, as in, only have one element per page that uses it. But you've slipped up before and it doesn't seem to matter, the CSS applies just fine.
Then you start getting conflicting information. Some tools and philosophy teach that ID's aren't good for styling. Some articles tell you they are the most efficient. Perhaps you work with a JavaScript developer who tells you they need ID's on everything because it makes their job way easier.
Confusion abound here. Turns out, everybody is kinda right. Here are the facts:
- CSS doesn't care much which you use, as far as actually applying styling. ID's are technically faster for a browser rendering engine, but other than the most extreme of circumstances you'll probably never notice a speed difference.
- JavaScript cares very much about ID's. It can be noticeably faster for JavaScript to find an element by an ID. And this is where the "uniqueness" is very important. JavaScript will only find the "first" element with that ID, so if you have multiple on the page, confusion may ensue.
- ID's have an infinitely higher specificity value than classes. If there is an element with an ID and a class and they both apply styles, the styles applied by the ID will take precedence over the styles applied by the class. This can be useful, this can be a hindrance.
My personal philosophy is to use ID's on stuff that I absolutely know there will only ever be one of and will not benefit from properties from a class name shared with other elements.
Buried hovers
What's going on here?
```
div           { color: red; }
div:hover div { color: green; }
```
:hover is a selector which only applies itself when the mouse is over a particular element. What is weird here is that you don't necessarily have to apply styles to that element being hovered over. In this case, we are applying styling only to descendant divs when the parent div is hovered. So:
```
<div>

   I will be red all the time

   <div>
      I will be red, unless that top
      div is hovered (but not necessarily me)
      and then I'll be green.
   </div>

   I will be red all the time

</div>
```
Whitespace doesn't matter
This:
```
div{color:red}
```
Is the exact same as:
```
div            {
      color       :       red

}
```
You do need spaces in selectors to make decendent selectors (e.g. ulli { } is absolutely not the same as ul li { }) but other than that you should use whitespace however makes looking and working with your CSS comfortable.
Notice the missing semicolon on that property in the example above. You can omit that if it's the last property in the group. Personally I never do as if you add more property/values later and forget to add the semicolon to the previous line, that's a problem. Because whitespace is so free, it will continue to read the next line as part of the value of the previous line.
Example of the problem:
```
div {
  -webkit-border-radius: 10px
  -moz-border-radius:    10px
  border-radius:         10px
}
```
The whitespace is fine. The no-semicolon on the last one is fine. But the first two property/value pairs don't have semicolons and will totally screw up and not work.
Property overrides
What font-size is the div going to have?
```
div {
   font-family: Sans-Serif;
   font-size: 18px;
   font-weight: bold;
   font-style: italic;
   color: red;
   margin: 0 0 20px 0;
   font-size: 21px;
   padding: 10px;
}
```
It's going to be 21px. You've accidentally listed it twice and the second one is going to win.
Order in CSS file matters
If you have two selectors that have the exact same specificity like this:
```
.red   { color: red; }
.green { color: green; }
```
And then they apply to the same element, the selector later in the CSS will always win. Class name order in HTML doesn't matter:
```
<div class="red green">Will be green</div>
<div class="green red">Will be green</div>
```
What makes for a semantic class name?
The previous example used "red" and "green" as class names. That's not very semantic. Why not? That's a whole ball of yarn, for next week! ish!

Advertise here with BSA
Little CSS Stuff Newcomers Get Confused About is a post from CSS-Tricks
Convert a Menu to a Dropdown for Small Screens

Posted: Fri, 15 Jul 2011 15:54:53 +0000
The Five Simple Steps website has a responsive design with a neat feature. When the browser window is narrow, the menu in the upper right converts from a regular row of links into a dropdown menu.
When you're on a small screen (iPhone shown here) and click the dropdown, you get an interface to select an option where each option is nice and big and easy to choose.
That sure makes it easier to pick a place to go than a tiny link. Yeah, it's two taps instead of one, but that's arguable since you'd probably have to zoom in to tap the right link otherwise.
The HTML
The HTML for these two menus is different. As far as I know, you can't style <select> and <option> elements to look and behave like <a>s or vice versa. So we need both. You could just put both in the markup. That's what Five Simple Steps does:
```
<nav> 

  <ul>
    <li><a href="/" class="active">Home</a></li>
    <li><a href="/collections/all">Books</a></li>
    <li><a href="/blogs/five-simple-steps-blog">Blog</a></li>
    <li><a href="/pages/about-us">About Us</a></li>
    <li><a href="/pages/support">Support</a></li>
  </ul> 

  <select>
    <option value="" selected="selected">Select</option> 

    <option value="/">Home</option>
    <option value="/collections/all">Books</option>
    <option value="/blogs/five-simple-steps-blog">Blog</option>
    <option value="/pages/about-us">About Us</option>
    <option value="/pages/support">Support</option>
  </select> 

</nav>
```
Let's go with that for now.
The CSS
By default we'll hide the select menu with display: none;. This is actually good for accessibility, as it will hide the redundant menu from screen readers.
```
nav select {
  display: none;
}
```
Then using media queries, we'll do the switcheroo at some specific width. You can determine that on your own (here's some standard breakpoints).
```
@media (max-width: 960px) {
  nav ul     { display: none; }
  nav select { display: inline-block; }
}
```
But now you gotta maintain two menus?
Well yeah, that's one concern. Maybe your menus are created dynamically and you can't control the output easily. Maybe you and hand crafting menus but want to make sure you don't accidentally get your menus out of sync. One way we can fight this is to dynamically create the dropdown menu from the original.
Using jQuery, we can do that with just a few lines of code:
```
// Create the dropdown base
$("<select />").appendTo("nav");

// Create default option "Go to..."
$("<option />", {
   "selected": "selected",
   "value"   : "",
   "text"    : "Go to..."
}).appendTo("nav select");

// Populate dropdown with menu items
$("nav a").each(function() {
 var el = $(this);
 $("<option />", {
     "value"   : el.attr("href"),
     "text"    : el.text()
 }).appendTo("nav select");
});
```
Then to make the dropdown menu actually work...
```
$("nav select").change(function() {
  window.location = $(this).find("option:selected").val();
});
```
But aren't dropdown menus kinda obtrusive?
Kinda. Most small screens these days are mobile and most mobile devices are JavaScript friendly, so not a huge concern. But, if you want to ensure this works with or without JavaScript I have an article about that.
Demo & Download
View Demo Download Files
Video
Quick video example in case you are reading this from somewhere you can't adjust the browser size and play with it to see what the heck we're talking about here.

Advertise here with BSA
Convert a Menu to a Dropdown for Small Screens is a post from CSS-Tricks
Identity at Mozilla

Posted: Fri, 15 Jul 2011 13:09:50 +0000

New project from Mozilla team to tackle the long-standing issue of single-signon (not needing a unique login/pass for every single app in the world). I love it when apps have "Sign in with Twitter", but I'm not sure Twitter should be the hub of all login activity, I'd rather it be some project solely dedicated to it. I hope it takes off. Seems easier than Open ID which always eluded me.
Direct Link to Article — Permalink

Advertise here with BSA
Identity at Mozilla is a post from CSS-Tricks
The Actual Browser Problems with Unquoted Attributes

Posted: Thu, 14 Jul 2011 17:22:10 +0000
In HTML (4, 5, whatever) quoting attribute values is optional, kinda. Both of these are totally fine:
```
<b class=boom>
<b class="boom">
```
But there are rules and limitations. Hopefully obviously, this is a problem:
```
<a title=Hi, mom! href=#>
```
That space in Hi, mom! is the problem. The browser will think the value of the title is Hi, and think mom! is an attribute onto itself. Any whitespace-like character will cause this problem. Mathias Bynens created a tool called the Mother-effin’ unquoted attribute value validator, a simple tool for evaluating a possible attribute value to see if it's valid or not.
The problem characters are: spaces, tabs, line feeds, form feeds, carriage returns, ", ', `, =, <, or >.
The Actual Problems
So those are the rules, but what happens if you actually break the rules? Using some of those characters in unquoted attributes can cause serious problems. Others do not. And some characters not referenced in those rules cause problems.
Let's just look at a bunch of them.
```
<div rel></div>
<div rel=></div>
```
Not valid, but not a big deal in any browser. Just sees the rel attribute as present but empty.
```
<div rel==></div>
```
Not valid, but works in every browser. Rel attribute seen as "=".
```
<div rel=&></div>
```
Rel value seen as "&" in all modern browsers including IE 9 and 10. IE 6, 7, and 8 see empty value, except when accessed through CSS (e.g. content: attr(rel);) in which the value is seen as "&"
```
<div rel=&a></div>
```
Rel value seen as "&a" in all modern browsers including IE 9 and 10. IE 6, 7, and 8 sees value as "a".
```
<div rel=a&b></div>
```
Rel value seen as "a&b" in all modern browsers including IE 9 and 10. IE 6, 7, and 8 see the value as "a".
```
<div rel=a&amp;b></div>
```
In this example the ampersand is encoded. Modern browsers including IE 9 and 10 see the value as "a&b" (same as leaving it unencoded). IE 6, 7, and 8 also behave the same as the last test, truncating the value to only "a".
Seems like IE 6, 7, and 8 don't freak out about ampersands in attribute values, but will truncate the value at the point they first see one (unless it starts with one, then everything after it and until the next one).
```
<div rel=`></div>
```
All versions of IE (even 10) have problems here. They treat the backtick character as a quote, so by only using one of them, it's like the entire rest of the document until the next quote is part of the value of the attribute. All other browsers have no problem as see the value as "`".
```
<div rel=```></div>
```
This is similarly problematic, because there is an odd number of backticks, it leaves a set of quotes open. All non-IE browsers see the value as "```".
```
<div rel=``></div>
```
This is slightly less problematic because what IE sees as quotes are closed. Non-IE browsers see the value as "``".
```
<div rel=<></div>
```
Modern browsers, including IE 9 and 10, see the rel attribute value as "<". IE 6 and 7 see the value as blank, but no big disasters ensue. IE 8 sees the value as blank through JavaScript but sees the value as "<" through CSS (e.g. content: attr(rel);).
```
<div rel=>></div>
```
Here we're attempting to set the value to ">", but what's actually happening is that we're creating a div with an actual ">" inside it. Another way to see that is:
```
<div rel=>
  >
</div>
```
The rel attribute, in every browser, will be blank.
```
<div rel={@#():,*!![[]]}></div>
```
This looks weird, but none of these characters are problematic and no browser has any problem with that.
```
<div rel='></div>
```
```
<div rel="></div>
```
This is problematic in any browser (single or odd numbers of quotes). Similar to the backtick situation only all browsers understand quotes and quotes. This is world-crashing-down problematic, as the entire rest of the document until the next quote is seen as a value of that attribute.
In this article "modern browsers" generally refers to Safari 5.0, Firefox 4, Chrome 12, and Opera 11. IE are generally listed by version. "All browsers" refers to what I listed for modern browsers plus IE 6-10. Some of what I used for testing is at this JS fiddle, which can be easily altered as needed for more tests. No JS libraries were used.
Also see Mathias' in-depth article on the subject, which covers using them in CSS as well.
The moral of the story: if any of this is confusing to you, just quote all your attributes.

Advertise here with BSA
The Actual Browser Problems with Unquoted Attributes is a post from CSS-Tricks
IE 8 Thinks All Table Cells Have a Colspan

Posted: Tue, 12 Jul 2011 17:51:41 +0000
Nathan Smith let me know about this little gem. IE 8 (only) thinks that all table cells have a colspan attribute, whether they do or not. So if you are looking to style table cells uniquely that have that attribute, it's a bit tough.
```
td[colspan],
th[colspan] {
   /* WARNING: this will apply in IE 8 to table cells
      even if they don't have a colspan */
   background: red;
}
```
What we would expect to happen is something like this:
Instead in IE 8, every single table cell is matched:
This is totally unique to IE 8. Neither 7 or 9 does this, and 6 doesn't support attribute selectors so that's out anyway. It also thinks the value of the colspan is 1, so all of these are out:
```
th[colspan],
th[colspan="1"],
th[colspan*="1"],
th[colspan^="1"],
th[colspan$="1"],
td[colspan],
td[colspan="1"],
td[colspan*="1"],
td[colspan^="1"],
td[colspan$="1"] {

	/* All problematic in IE 8 */ 

}
```
Solution
If you really need to make this selector work, you can instead select by colspan values that are anything except for the value of 1. A little verbose, but it works.
```
th[colspan*="0"],
th[colspan*="2"],
th[colspan*="3"],
th[colspan*="4"],
th[colspan*="5"],
th[colspan*="6"],
th[colspan*="7"],
th[colspan*="8"],
th[colspan*="9"],
th[colspan*="11"] {
  /* Styles */
}

td[colspan*="0"],
td[colspan*="2"],
td[colspan*="3"],
td[colspan*="4"],
td[colspan*="5"],
td[colspan*="6"],
td[colspan*="7"],
td[colspan*="8"],
td[colspan*="9"],
td[colspan*="11"] {
  /* Styles */
}
```
Advertise here with BSA
IE 8 Thinks All Table Cells Have a Colspan is a post from CSS-Tricks
New Poll: Large file on CDN or small file local?

Posted: Sun, 10 Jul 2011 13:59:07 +0000
The new poll is up (in the sidebar on the actual site, RSS folks) and it reads:
Would you rather host a 200k file on a major CDN or a 20k file self-hosted?
This requires a little explanation. Let's say the file in question is jQuery UI. On your site, you only need it for it's tabs functionality. You could load a copy of it from Google's CDN like this:
```
<script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.14/jquery-ui.min.js"></script>
```
That file is literally 205k, because it's the complete jQuery UI library. But, it's on what is probably the world's biggest/fastest/most-used CDN (Content Delivery Network). Lots of sites use jQuery UI and probably get it from there, so you have a decent chance of that file already being cached when a user gets to your site.
Or, you could download a customized copy of jQuery UI.
```
<script src="/js/jquery-ui-1.8.14.custom.min.js"></script>
```
This file could only be 20k, because it is trimmed down to only have the necessary stuff to make the tabs functionality work. That file is ten times smaller, but the chances of it being cached for a user coming to your site is nil if they are a first time visitor.
So all other things being equal, which do you choose?

Advertise here with BSA
New Poll: Large file on CDN or small file local? is a post from CSS-Tricks
Progress Element in Firefox

Posted: Thu, 07 Jul 2011 18:08:18 +0000

The <progress> element has landed in the Firefox nighties, one of the new HTML5 forms related elements. Of particular note is that they exposed the ability to style it via pseudo elements right away. Mounir Lamouri fills us in:
... the progress element is two div's. You can access to the outer div by styling progress and to the inner one with ::-moz-progress-bar
I wish all "widgets" were this easy and straightforward to style.
Direct Link to Article — Permalink

Advertise here with BSA
Progress Element in Firefox is a post from CSS-Tricks

syndicated content powered by FeedBurner

Subscribe Now!

...with web-based news readers. Click your choice below:

...with other readers:

Current Feed Content

Posted: Wed, 20 Jul 2011 22:30:28 +0000

Posted: Wed, 20 Jul 2011 02:57:05 +0000

Posted: Tue, 19 Jul 2011 19:45:44 +0000

Posted: Tue, 19 Jul 2011 02:24:39 +0000

Tag qualifying

Selector order matters

Why use ID's at all?

Buried hovers

Whitespace doesn't matter

Property overrides

Order in CSS file matters

What makes for a semantic class name?

Posted: Fri, 15 Jul 2011 15:54:53 +0000

The HTML

The CSS

But now you gotta maintain two menus?

But aren't dropdown menus kinda obtrusive?

Demo & Download

Video

Posted: Fri, 15 Jul 2011 13:09:50 +0000

Posted: Thu, 14 Jul 2011 17:22:10 +0000

The Actual Problems

Posted: Tue, 12 Jul 2011 17:51:41 +0000

Solution

Posted: Sun, 10 Jul 2011 13:59:07 +0000

Posted: Thu, 07 Jul 2011 18:08:18 +0000