And I can’t help but hum a little Europe:

We’re leaving together /> But still it’s farewell /> And maybe we’ll come back /> To earth, who can tell? /> I guess there is no one to blame /> We’re leaving ground /> Will things ever be the same again?

Direct Link to Article — Permalink

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The problem is using adjacent (+) or general (~) sibling selectors combined with pseudo classes. Like this:

h1 ~ p { color: black; }
h1:hover ~ p { color: red; }

Nothing wrong with that, right? Seems pretty straightforward. That just doesn’t work in WebKit, nothing happens. There are lots of weird quirks that can affect it and seemingly fix parts of it. Like this:

/* This affects both paragraphs */
h1 ~ p { font: 18px Helvetica, Arial, Sans-Serif; }

/* This works */
h1:hover + p { color: red; }

/* This only affects first
... and does nothing without previous rule */
h1:hover ~ p { color: blue; }

I didn’t test every single one, but there are apparently issues with all the pseudo selectors (:focus, :hover, :checked, :enabled, etc)

A CSS Only Fix!

Alexander also sent a clever CSS only fix to the issue. Use a do-nothing animation on the body:

body { -webkit-animation: bugfix infinite 1s; }
@-webkit-keyframes bugfix { from { padding: 0; } to { padding: 0; } }

WebKit-only fix to a WebKit-only problem.

Well Documented

This is certainly not the first report of this. Here are some bug reports:

• bugs.webkit.org/show_bug.cgi?id=12520
• bugs.webkit.org/show_bug.cgi?id=17680
• bugs.webkit.org/show_bug.cgi?id=18026
• bugs.webkit.org/show_bug.cgi?id=18027
• bugs.webkit.org/show_bug.cgi?id=26539
• bugs.webkit.org/show_bug.cgi?id=29029
• bugs.webkit.org/show_bug.cgi?id=32695
• bugs.webkit.org/show_bug.cgi?id=45168

And other publications which mention the issue:

• Showing and hiding content with pure CSS3, in the Taking care of the elderly section
• CSS3 :target based interfaces in the Issues with spiders and reptiles section
• dev.opera.com/forums/topic/600712 – a brief discussion of the bug
• Pure CSS collapsible tree menu in the “Another demo, another bug” section
• Breadcrumbs (& CSS3 general sibling selector) in the “Caveats” section
• CSS3 – Almost a good idea but for Safari and Chrome of all browsers, where the webkit browsers are heavily criticized for the bug
• Webkit Bug: Hover and Sibling Selector, an article about the bug featuring a couple of potential fixes.
• Safari CSS :hover and Adjacent Sibling Selector Bug – yet another blog post about the issue
• Safari bug report: Hover with adjacent selector doesn’t work, the Quirksmode take on the problem.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

this site is by Paul Irish /> i made it cuz hsla is wayyyy cooler than rgba and more sensible too!

HSL is better than RGB. The reason it isn’t used as much (according to me) is because you can’t get HSL color values out of Photoshop. Hence, tools like this and my own.

Direct Link to Article — Permalink

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

If you need to put a border on only three sides of an element, there are a bunch of ways you can do it.

You can specifically declare the border on just three sides:

div {
  border-top:    1px solid red;
  border-right:  1px solid red;
  border-bottom: 1px solid red;
}

Verbose, but easy to understand.

Or, you could declare just a border which will cover all four sides and remove the one you don’t want.

div {
  border: 1px solid red;
  border-left: 0;
}

Much shorter, but relies on understanding and maintaining that the border removing override is kept after the border declaration.

Or, you could declare the color and styling and use shorthand only the border-width to specifically declare the three sides.

div {
  border-color: red;
  border-style: solid;
  border-width: 1px 1px 1px 0;
}

Shorter than the first example, but less repeative. Just need to be aware if left border did acquire width it would already be red and solid.

And then there is the fact that borders affect the size of the element under the regular box model. If you wanted to add borders without adding to the size of the element, you’ll need to lean on CSS3. Here is a way to do it with inset shadows:

div {
  -webkit-box-shadow:
     inset -1px 0   0 red,
     inset  0  -1px 0 red,
     inset  0   1px 0 red;
  -moz-box-shadow:
     inset -1px 0   0 red,
     inset  0  -1px 0 red,
     inset  0   1px 0 red;
  box-shadow:
     inset -1px 0   0 red,
     inset  0  -1px 0 red,
     inset  0   1px 0 red;
}

But then inset box shadows has far less browser support than borders do. For example, the code above will only work in Internet Explorer version 9+. If you’d rather use borders, and still not affect the elements size, you could play with box-sizing, which is supported down to IE 8.

Oh the choices! This is such a small thing, but I think it is a good example of how there is so often many different ways to accomplish the same thing in CSS. If you are just starting out in CSS, is this kind of thing confusing or pretty straightforward?

See all examples.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The Drawing Table is in essence a mini one-page jQuery application. It has one primary function, creating a colored design by changing the colors of cells in an HTML table. However it has many features to make this as easy and useful as possible. In this screencast we walk through the existing code looking at the finished example, the markup, and the JavaScript powering that it feature by feature.

src="http://cdn.css-tricks.com/wp-content/uploads/2010/10/screencast-92-thumb.png" alt="" title="" /> /> View Screencast

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

id="more-7361">

.not-a-square {
   -webkit-border-radius: 10px;
   -moz-border-radius: 10px;
   border-radius: 10px;
}

Why is this method of ordering properties so commonly taught? Here is what it would look like “the wrong way”:

.not-a-square {
   border-radius: 10px;
   -moz-border-radius: 10px;
   -webkit-border-radius: 10px;
}

Even doing it “the wrong way”, won’t the border radius be the same no matter what, forever? A quick investigation might lead you to conclude that it will, and this ordering of properties is rather nonsense.

1. The Long Long Ago: None of the properties are supported, order doesn’t matter.
2. The Past: Only vendor prefixes are supported, order doesn’t matter.
3. The Now: Both vendor prefixes and actual property are supported. If prefix is last, it will override actual property, but both are the same anyway.
4. The Future: Only actual property is supported, order doesn’t matter.

Here’s a simple chart with this concept at work.

Woah there, Cowboy

The fact is, the ordering of CSS3 properties is important, and the above is fundamentally flawed. “The Now” is exactly the problem. We are at a crucial juncture in browser history where some browsers are supporting both the vendor prefixed version and the actual CSS3 property. Right now it’s specifically WebKit that is doing this, and the way they have implemented it is that if you list the vendor prefix after the actual property, the vendor prefix will override and be the property that renders.

Why does that matter? In the simple border-radius example we saw above, either way, the corners on that element will have a border-radius of 10px. There is no difference in how the vendor prefix and “real” property handle rounded corners when you set only one value. The problem is that there is a difference between the implementations of the properties when passing more than one value.

.not-a-square {
   /* These do totally different things */
   border-radius: 30px 10px;
   -webkit-border-radius: 30px 10px;
}

The spec or “real” version will render the top left and bottom right corners at 30px and the top right and bottom left corners at 10px. The vendor prefix will render all four corners with elliptical corners 30px wide and 10px tall.

So if you’ve been blinding including the real border-radius at the end of your property lists using identical values, and then switch from Safari 4 to Safari 5, you’d see a dramatic change in how the above code was styling your boxes.

<!--[if IE]>
  <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

Credit for that to Remy Sharp, Jon Neal, John Resig and anybody else who contributed to that idea. Also for the benefit of those non-hip browsers, it’s best to reset many of the HTML5 elements to block-level as they should be:

article, aside, figure, footer, header, hgroup,
menu, nav, section { display: block; }

Now we’re all set to use and style HTML5 elements. But wait! What happens if we dynamically add HTML5 to the page via JavaScript.

var s = document.createElement('div');
s.innerHTML = "<section>Hi!</section>";
document.body.appendChild(s);

Or in jQuery:

$("body").append("<section>Hi!</section>");

Hip browsers do fine, but Internet Explorer will once again not recognize the new element and not apply CSS to it.

Joe Bartlett has written a great work-around to the problem called HTML5 innerShiv and I thought more people should be aware of it.

Using it

Please note that this script does not require jQuery. It’s just vanilla JavaScript and will work with any library or library at all.

1. Download

Download the script and insert it onto your page. Or copy and paste the script into other JavaScript you are already loading if you want to avoid an extra HTTP Request.

2. Wrap all HTML content in innerShiv function before inserting

Here is the same jQuery example as above, made to work using innerShiv:

$("body").append(innerShiv("<section>Hi!</section>"));

Quick demo.

Remember to check out Joe’s page, which does a better job of explaining things.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

$("a").click(function() {
   $("body").append($(this).attr("href"));
   return false;
}

That code would append the href attribute as text to the body every time a link was clicked but not actually go to that link. The return false; part of that code prevents the browser from performing the default action for that link. That exact thing could be written like this:

$("a").click(function(e) {
   $("body").append($(this).attr("href"));
   e.preventDefault();
}

So what’s the difference?

The difference is that return false; takes things a bit further in that it also prevents that event from propagating (or “bubbling up”) the DOM. The you-may-not-know-this bit is that whenever an event happens on an element, that event is triggered on every single parent element as well. So let’s say you have a box inside a box. Both boxes have click events on them. Click on the inner box, a click will trigger on the outer box too, unless you prevent propagation. Like this:

This demo.

So in other words:

function() {
  return false;
}

// IS EQUAL TO

function(e) {
  e.preventDefault();
  e.stopPropagation();
}

It’s all probably a lot more complicated than this and articles like this probably explain it all a lot better.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

If you are like me, you are both guilty of seriously unorganized Photoshop documents and appreciate well organized ones. The disorganization isn’t intentional, it’s just born of (if you’ll pardon the likely-inaccurate clich) being in right-brained creative mode and caring about what you are looking at not the left-brained organizational stuff. Then it compounds itself as you go in and out of the file for days on end. If you are handing this file off to someone else, or are beginning the HTML/CSS conversion process, it’s a great idea to revisit the file with the specific intent of organizing it. We’ll cover good naming conventions, using folders, layer comps, and various other little tricks.

View Screencast

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.