A while ago I made a design with lot’s of semi transparent areas (I know, stupid me, it’s only 2010 after all) and solved that in modern browsers with rgba(). All fine and well, I threw in some border-radius and box-shadow, and from Opera through Firefox to Webkit, it looked increasingly better. Great, I’m all for progressive enhancement. Except it of course looked really bad in IE. I set out to find an acceptable solution.

Gradients, where?

For general opacity, we have the alpha filter. but that sets the opacity of foreground elements as well, making it useless in this case. Looking a bit further, I found the gradient filter. Seeing as how I needed transparency and not gradients, this didn’t seem very useful.

But the gradient filter supports some fun stuff. While it’s not mentioned anywhere in the msdn article, the gradient filter has an #ARGB syntax. That’s right, the A is for Alpha. No, I don’t know why it’s at the front.

Anyway, Gradients don’t have to be between two different colours, right? You can just as easily go from white…to white. So that’s what I did:

filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#26ffffff,endColorstr=#26ffffff);

And there you go, alpha-transparent backgrounds!

Gotcha’s

Of course, it’s not that easy. rgba() notation is in values from 0 to 255, with the a being a floating point between 0 and 1, and #ARGB is in hexadecimal format. You need to convert rgba() to #ARGB to make it useful.

I’ve saved you the math, here’s an easy (to and from) converter:

Convert to and from rgba() and #ARGB

More gotcha’s (or: Oh, IE!)

Of course, just finding the correct value for #ARGB isn’t the only problem you will have. There are more downsides. For one, the code above isn’t actually the one you have to write. The code below is:

background:none;
-ms-filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#26ffffff,endColorstr=#26ffffff);
filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#26ffffff,endColorstr=#26ffffff);
zoom: 1;

Firstly, you have to set the actual background to none, then you have to use -ms-filter for IE8, filter for everything below, and set zoom:1; to make sure the element has hasLayout (or else the filter doesn’t work.)

Apart from the code, there are two other downsides: When you use filters, ClearType gets disabled. That’s a pretty big downside, since non-cleartyped text looks hideous. According to some you can fix it, but YMMV.

Secondly, as soon as you place the website in an iframe, say goodbye to the A in your gradient. the backgrounds will lose there transparancy and look hideous. I learned that the hard way. if you use the gradient filter, don’t display your site in an iframe.

Should you use it?

Using stuff like this, it’s a bit like we’re dragging IE along, kicking and screaming. And that’s what we do. We want to move forward, so we find ways to get around the limitations of lesser browsers. Whether losing ClearType is worth it depends wholly on the design. In my case it did, in your case, it might not.

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

How to use RGBA() in IE

Why they exist

You see, vendor prefixes exist for one important reason. Vendor prefixes are used for unfinished specifications. Unfinished specifications change. They evolve. Sometimes they don’t describe the implementation at all, or the syntax has yet to be agreed upon. They are not done yet. They are unfinished.

This means browsers could, and will implement things differently. To give a concrete example: Gecko and Webkit implemented the border-radius syntax differently. Had there been only one “-beta-” prefix, you could not have used border-radius in a cross browser way. That doesn’t seem like a real solution, does it?

“But I have to type so much!”

Sure, typing -moz-, -webkit, -o- again and again gets annoying, but come on, you’re a developer. It’s trivial to make a snippet (or whatever your editor calls them) for this, or to use a Sass or LESS mixin. Tools will save us.

Vendor prefixes are awesome

Vendor prefixes allow us to test out new technologies, they allow different browsers to implement them in the way they seem most conforming to the specification (at that moment). This in turn allows developers to deal with browser differences by setting different values for each vendor prefix.

Browsers get to test out different implementations, and developers get early access to new possibilities. That seems like an excellent deal to me.

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

CSS Vendor prefixes considered important

CSS transforms

CSS transform (in Firefox 3.5+ and Webkit-based browsers) has a whole bunch of interesting functions, such as rotation, translation, scaling and skewing. To learn more about the different functions, check out the Mozilla developer center overview of CSS transform. After playing around with chaining different transforms and seeing the effect, I found out something interesting:

transform:rotate(45deg) translate(0, -35px);

If you rotate first, and then translate (move), it will move along the rotated axis. The above code translates a block to the top-right corner (45 degrees). (the gray div is not transformed while the black one is.)

Using this, I could rotate and translate a bunch of divs to create loading spinners (though this one doesn’t spin yet!):

In this example, each div is rotated an additional 45 degrees. The first one is not rotated, the second one is rotated 45 degrees, the one after that 90 degrees, and so forth. Additionally, each div has increased opacity to make it look like most loading spinners.

Animation

Webkit supports CSS animations, but these are continuous while most loading spinners are not. On the left side is a spinner animated with CSS animation (only works in Safari and Chrome), on the right there’s one animated with a small bit of JavaScript to look like regular loading spinners:

The code for the CSS animation is fairly straightforward:

#div2 {
  -webkit-animation-name: rotateThis;
  -webkit-animation-duration:2s;
  -webkit-animation-iteration-count:infinite;
  -webkit-animation-timing-function:linear;
}
@-webkit-keyframes rotateThis {
  from {-webkit-transform:scale(0.5) rotate(0deg);}
  to {-webkit-transform:scale(0.5) rotate(360deg);}
} 

While the (quick and dirty) code for the JavaScript animation is pretty easy as well:

  var count = 0;
  function rotate() {
    var elem2 = document.getElementById('div3');
    elem2.style.MozTransform = 'scale(0.5) rotate('+count+'deg)';
    elem2.style.WebkitTransform = 'scale(0.5) rotate('+count+'deg)';
    if (count==360) { count = 0 }
    count+=45;
    window.setTimeout(rotate, 100);
  }
  window.setTimeout(rotate, 100);

Someone else might be able to duplicate the loading spinner-style rotation with CSS animations (please let me know!), but the JavaScript solution looks better and works in Firefox too.

Going crazy with it (More examples!)

Once I had the basic ‘functionality’ working, I just decided to go crazy with it and create a whole bunch of different style loading spinners. You can find them on this page: CSS3 loading spinner examples.

Check out the source for the way to style the different spinners and let me know when you make interesting variations!

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

CSS3 loading spinners without images

The presentation

Or watch it here, if full screen is more of your thing: CSS frameworks by Kilian Valkhof. It’s in Dutch.

The presentation is a general overview of the current CSS frameworks, both client side and server side. It gives a rundown of the way they work, what their (dis)advantages are and which one you should use. Just kidding ;)

I managed to keep SenCSs out of the presentation, for its larger part. The most fun discovery was that very little people knew about the server-side options like sass and cssscaffold. They provide a powerful way to manage your CSS and allow you to write smarter css, faster. It’s where the cool stuff will be happening :)

Prezi was interesting to work with, even though their sloppy coding prohibited me from making my presentation on my normal pc, a 64bit Ubuntu installation. It worked nicely in a 32bit VM though. Prezi, if you want a horde of smart, creative early adopters to use your product, pay me and I’ll fix your code ;)

The Meeting

Thanks to Martin for hosting the May meeting, Mirabeau in Eindhoven has an awesome looking office. It was our most southern meeting yet, and there were more people than I expected, so that was all good.

Besides my presentation, Arjan Eising gave a talk about WAI-ARIA. It was very interesting and he had some nice code examples, though I had hoped to hear a little bit more about the juxaposition between it and HTML5.

I also got rid of about 60 more stickers, which have been going like hot buns ever since they got the Zeldman seal of approval.

If you want to host a Fronteers meeting in the future, don’t hesitate to contact us!

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

Slides of my Fronteers talk

If you’re not familiar with Cufón, check out my previous article: Cufon vs. Typeface.js, which one is better? or this article: Exploring Cufón, a sIFR alternative for font embedding by Cameron Moll.

Not just @font-face…

Now, @font-face isn’t the only way to display custom fonts. What if the visitor already has the font installed? It’ll display automatically then, again leaving us with no reason to use load Cufón. These are the three options you have when you want to display custom fonts, in order of speed:

• The font is already installed on the users computer
• The font get’s downloaded and displayed with the use of @font-face
• The font gets replaced by Cufón

I will not go into @font-face in this post, for more on web fonts, read these articles: CSS at ten and @font-face in IE: making web fonts work (Which not only explains how to use @font-face in browsers that support it, but also in IE using their proprietary DRM-ed .eot ‘standard’.)

The trick

The effect of an installed font and using @font-face are the same: The font is rendered and displayed natively by the browser. This means that you only have to check if the font is available, and can forgo checking if @font-face is at all an option. A very smart solution to do this is the jQuery fontAvailable plugin. The implementation looks like this:

$(document).ready(function() {
    if($.fontAvailable('Optimer')) {
        // code here
    }
});

The plugin works in a most ingenious way: On document load, it created an element with the alphabet in it, and sets the font-family to a non-existent font to apply the default font. It then replaces the font-family with the font you've specified, and checks if the width has changed. If the width has changed, that means the font was applied and is available.

Update: Eneko Alonso ported the plugin to mootools: moo-fontavailable. Cool no?

So, all you have to do to make this work, is make sure that the font-name you define in your @font-face declaration is the same as the real font name, and it will automatically work for both already installed fonts, and fonts loaded in with @font-face!

And then Cufón

So, with an @font-face declaration in your CSS, and a bit of JavaScript telling you if the font is available, all you have to do is add in @cufón when $.fontAvailable returns false! (Note the added ! in the example code, so Cufón gets executed if the font is not available)

$(document).ready(function() {
    if(!$.fontAvailable('Optimer')) {
      Cufon.replace('h1');
    }
});

Unfortunately it's not quite that easy. Because IE can show a FOUC with Cufón, you have to add Cufon.now(); at the end of the page. If we use Cufón from within $(document).ready();, that would make Cufon.now(); ineffective because it would actually be parsed before the document is ready, and thus before the initial Cufon.replace(); function.

It will still work, but IE users might see the font getting changed while the page is loaded. Over at the Google group, they are already working on a solution to this, so it shouldn't be long before you won't need Cufon.now(); at all anymore.

That's all there is to it

All in all, it's quite simple. Check if the font is available, either through already being installed or through @font-face, and if it isn't, we'll let Cufón display it. This offers you the best of both worlds, because browsers that support @font-face will have their native text, and browsers without @font-face support will still get custom fonts.

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

Combining Cufón and @font-face

Why?

HTML5 is arriving sooner rather than later. The 2022 date means that it’s fully supported, finished, done. It doesn’t mean we can’t use it. For example, CSS2.1, from 1998, still isn’t fully supported, finished, done, either. We all use that as well, right?

A lot of the HTML5 supported today are actually browser quirks, formalised. It’s usable right now, will get you acquainted with HTML5 and will basically make your front-end life easier :) (And it all works in Internet Explorer too!)

There is much, much more to HTML5 than visible in this article. This article only focusses on what you can use now. If you want more info on HTML5, check the specifications, or the whatwg blog.

<!doctype html>

The simplified doctype is ierhaps the most iconic idea in HTML5. It turns out, the above code is all that’s needed to trigger standards mode. The validator understands it as well. Quite a change from the humongous HTML4 or XHTML doctype declarations, no?

<meta charset="utf-8">

This works the same as the doctype. You don’t need anything more than this to make your browser set a charset. It turned out that people so often mistype this attribute, (content="text/html; charset=utf-8"), that browser parsers actually encountered charset=utf-8 more than the whole content attribute. Since it’s legal to omit the quotes, charset is being parsed as an attribute in all browsers. And it’s legal in HTML5.

<script>
 //your javascript
</script>

<style>
 // your css
</style>

You no longer have to declare the type attribute with text/javascript or text/css. All browsers already act as if anything inside those tags is javascript or CSS.

Getting used to new structural elements

HTML5 introduces a bunch of new elements that allow you to better describe your document:

• <header>
• <footer>
• <nav>
• <section>
• <article>
• <aside>

These are not all the new elements, but they are the ones that are going to replace the numerous divs used today. While you can use them already, I consider it a bit tricky in-production (it’s dependent on javascript). Instead of using the elements however, it’s a smart thing to start using these names as classes for the divs you currently use. When the time comes, it’s easy to just switch over to these elements.

Soon we’ll be living in the future!

When you start using HTML5 like in the examples above, you have the benefit of acquainting yourself with HTML5, still make websites that work today and more importantly, make sure your websites will still work for a long time to come!

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

Add a little HTML5 to your websites

What makes a good print stylesheet?

A good print stylesheet, first and foremost, hides all the unnecessary elements, such as navigation, search, sidebars and other elements that aren’t directly important for the page being printed. It removes as much of the colours as possible, so that you’re not wasting anyone’s colour ink, and make sure your text is the width of the page (width:auto) so that you’re not wasting anyone’s paper.

There’s one smart trick when making a print-stylesheet. In print, people can’t click on your links, but they might want to visit them anyway. By using this bit of CSS, you place the actual link in parenthesis behind the linked word:

a::after {
  content: " (" attr(href) ") ";
  font-size: 90%;
}

Where the font-size makes it just slightly smaller than the normal text to distinguish it a bit more.

Two very handy CSS properties are page-break-before and page-break-after. With these elements you can control where your site should “break” over into the second page. On this site, I use this CSS:

div.comments {page-break-before:always;}
h2, h3 {page-break-after:avoid;}

Comments are always placed on the second page, so that the article is always on it’s own as well. One thing I find pretty ugly is when a page ends with a header, and the following paragraph is on the next page. The second bit of code prevents that.

There are two ways you can add a print stylesheet. One is with a seperate stylesheet, and linking to it with <link rel="stylesheet" type="text/css" href="print.css" media="print" />. The other one, which I use on my own site, is an @media print code block at the bottom of my CSS file:

@media print {
  //my print-only css
}

Which I think is better, because it saves a http request while still being fairly clear.

Of course, most of this information isn’t new. There is a great A list apart article from 2002(!) that details much of what I’ve written above.

Updated: Additional cool techniques by Jan Paul Posma

The trick we used before to display links can be used in a number of different ways. Suppose, perhaps, that you are using relative links on your domain. about ( /about ) wouldn’t be very useful. Luckily you can add arbitrary text to your ::after content, such as this:

a[href^="/"]:after {
	content: " (http://kilianvalkhof.com" attr(href) ")";
	font-size: 90%;
}

And the same idea can be applied to acronyms and abbreviations!

abbr[title]:after,
acronym[title]:after {
	content: " (" attr(title) ")";
	font-size: 90%;
}

The [title] part of the selector is there to make sure only abbreviations with a title element get explained. This prevents empty parentheses from popping up.

In the eye of the public

So, we’ve known about this since 2002 at least, why do clients still ask for a special print page and a little printer icon for people to click on?

The reason for that is of course pretty clear: the browsers doesn’t tell people that a page is especially adopted for print as well as screen. And so in turn people have no idea of the possibilities.

Print stylesheets arent very useful if people don’t use them.

And I really don’t know how to change that. Do you?

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

A useful print stylesheet

They’re both right.

Of course, it’s all about when you use which method. In some cases, absolute positioning breaks faster and it’s better to use floats, while in other situations it’s better to use absolute positioning because floats would break the layout. luckily for us, there is one very simple rule:

If elements should not interact, use absolute positioning, if they should, use floats.

It’s that simple. Lets take this site for example. The searchform in the top right uses fixed positioning (which mostly behaves like absolute positioning) because it will, and it must, never interact with the other elements on the website. However if you scroll down to the footer, you can see 4 lists next to each other. It’s entirely possible that there are only two or three lists available. In that case, you do not want a gap on the left or in the middle, you want the elements to interact and line up nicely starting from the left. That’s what floats do for you.

If you want a more in-depts explaination of css positioning, check out my articles on them:

• Understanding CSS positioning, part 1
• Understanding CSS positioning, part 2
• Understanding CSS positioning, part 3

So, now you know that it’s not black and white (It’s grey!). There are times when you use floats, and there are times when you use absolute positioning. In my opinion, correctly styled floats are much more robust than absolute positioning, so I personally tend to use them more. How about you?

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

Absolute positioning Vs. floats

The Specification

The negation pseudo-class, :not(X), is a functional notation taking a simple selector […] as an argument. It represents an element that is not represented by the argument.

What it says here, is that a selector with a :not() in it will match all elements that do not match what’s between the parenthesis.

A simple selector is a term used in the specifications. A simple selector is: a single element, attribute selector, class, id or pseude-class.

Examples of simple selectors:

body
*
[value="foo"]
.foo
#foo
:hover

Basically, any of the above type, but with only one selector.

The browsers

The :not() selector is only supported by modern browsers (Firefox, Safari and Opera), :not(IE).

Let’s take a look at what browsers allow you to do:

div:not(.home) {…}

This selects all div elements that do not have the class .home

div *:not(p) em {…}

This selects all em elements that are in an element (that is not a p element) and that are in a div element. so <div><strong><em>…</em></strong></div> is a match, but <div><p><em>…</em></p></div> is not.

input:not([type="file"]) {…}

This uses the attribute selector to select all input element, save for the file upload ones.

I was surprised to find out that

h2:not(.foo, .bar) {…}

also works. You can give the :not() selector a comma separated list as well! (Tested in Firefox 3) This is surprising, because it’s not documented as such in the specifications.

You can use the :not() selector as a part of a large selector. I’ve done this a few times in my current design:

li:not(.pingback) .comment-content p:first-child:first-line {…}
body:not(.home) h2 + p:first-letter {…}
.post:not(.first-post) a:hover {…}

The :not() selector is a nice addition to the CSS Tookit, and it can already be used in a way that allows for graceful degradation, such as I do on this website. If you have any nice experiences with :not(), please share them in the comments!

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

The CSS3 :not() selector

li:not([class=pingback]) .comment-content p:first-child:first-letter

Which is one of the selectors I use to style the comment section of my new design. Not bad, is it?

Sorry for the delay on the second part of Building your own lightbox. The article is proving itself to be, how do I say it, humongous.

So, for this week, Tell me your best CSS selector!

Feel free to Flattr this post at flattr.com, if you like it.

This article is written by Kilian Valkhof, Front-end developer & User experience designer. Please visit KilianValkhof.com for more articles!

Your best CSS selector?