Archive for December, 2010

Angled content mask with CSS

December 28th, 2010 No comments

In this article I will show you how to do create angled CSS content “mask”. The idea is pretty simple and it uses CSS transform property (rotation to be more precise). Of course this effect will be fully functional only in browsers currently supporting CSS rotation.

In last article I talked about my position on vendor prefixes. In this article I am using properties that currently contain vendor prefixes. Funny, isn’t it? Although I would still prefer to have prefix-free properties, that is not stopping me (and it shouldn’t stop you) from using the new properties goodness.

Let’s get to the business. Look at the image bellow to see what I am trying to achieve.

Take a look at the demo or
Download files

The idea, as mentioned, is quite simple. We have 3 nested elements. Top level acts as a container of a certain size that fits into design, i.e site header. Second element will be rotated X degrees (clockwise) and third element is rotated -X degrees (anti-clockwise) so it evens up horizontally. Take a look at the image bellow to get a better idea.


The markup looks like this:

<div class="box">
	<div class="inner">
		<div class="content"><img src="img.jpg" alt="my bike" /></div>

The CSS goodness

Important thing here is to set overflow property to hidden on all 3 elements (ok you can skip that for the 3rd element). First element is not rotated and it has fixed width and height. Second element is rotated clockwise and third element is rotated anti-clockwise by the same degree amount. The placement of the elements should then be further adjusted by element’s margins and of course you are free to style it as pleased (background images, borders etc.) On the demo page I am providing a bare-bone example you can then restyle as pleased.

/* angled box styles */

	margin:1em 0;
.box .inner{
	border:3px solid #fff;
.box .inner .content{

This trick is works best if applied to images (background images), but any content can be masked like this.
Also please note that it will take some tweaking the margins to get the best result. What you need to have in mind that the content should be nicely presented in browsers that don’t support CSS rotation, just as in my example.

Categories: Designing, Others Tags:

Vendor prefixes and web standards

December 21st, 2010 No comments

When I started with the web development I was somewhat obsessed with web standards. The idea of having one set of rules or recommendations on how to develop a web page seemed like the only way to go in my professional life. The one thing that really annoyed me back then (besides various IE fixes and hacks) was browser inconsistent JavaScript support. I was in a place where I had to tweak and adjust every script I made and test it over and over again. Then this great thing came along so I am not worried about that anymore. The inconsistencies are still there, I just have a marvelous piece of code that does the worrying for me.

Most of the CSS properties however were cross browser supported all along. Sure, there are some misinterpretations and missing support for pseudo element here and there (especially with old mastodons browsers) but the situations wasn’t nearly as complicated as with JavaScript.

Then the web began to change. New technologies were introduced, new buzzes… Browser developers started to experiment in supporting cool CSS properties that not only could change the appearance of an element, they could also control the behavior.
As a web developer I couldn’t be more excited about these new properties. If nothing, it brought us choices. We don’t have to use them, but if we want to, we can.

Vendor prefixes

But there is one thing that is far from ideal…
In it’s original idea, standards should be a unique set of rules and coding recommendations applicable to all platforms, devices, browsers… Vendor prefixes couldn’t be further away from that. Applying a vendor prefix you target specific browser, so if you want to target another one, you either can’t or have to use another line of code with another “vendor prefixed” CSS property.

Take a look at this example

	-moz-box-shadow: 10px 10px 5px #000;
	-webkit-box-shadow: 10px 10px 5px #000;
	box-shadow: 10px 10px 5px #880008;

We all talk about IE hacks, how we hate it, how these are not complying to web standards, how they’re not valid… I am asking you, how is the example above different from these hacks?

I am aware that prefixes were used by browsers to try on new experimental properties. I salute that, without these great efforts we wouldn’t have progress. But do we have to keep the vendor prefixes for CSS properties that are not so experimental any more? Why don’t we have support for non prefixed properties now that some of the things are out of the experimental phase and more or less accepted?

Why are developers forced to write multiple lines of CSS for the same thing and when will it all be standardized?

In my opinion, vendor prefixes are unnecessary. If browsers want’s to experiment with new properties, what keeps them from doing so and use the “regular” naming conventions? It could even speed up the process of cross-browsers acceptance.

Let us know what do you think, I would really like to hear more thoughts on this one.

Categories: Designing, Others Tags: