Here's One Solution

Setting RGBa backgrounds using inline CSS

I’m working on some code that is injected into a page using JavaScript and has to exist in an unknown environment. To make sure that the styling is not over-ruled by other CSS applied to the page I am adding some CSS as inline styles. This works fine until you try to apply an RGBa background with a hexadecimal fallback.

Usually you would declare something like this in your CSS.

div {
    background-color: #666;
    background-color: rgba(0,0,0,0.6);
}

All browsers apply the first background colour value, and this is then overridden by the second value in browsers that understand RGBa. Browsers that don’t understand RGBa just ignore it and continue to use the first value.

If you apply this inline however, it doesn’t work in IE7 or IE8.

<div style="background-color: #666;background-color: rgba(0,0,0,0.6);">content</div>

Inspecting the elements shows that the background colour value is empty.

As I am adding all of this code to the page using JavaScript I decided to try setting the styles using JavaScript at the same time.

div = document.createElement('div');
div.style.backgroundColor = "rgba(0,0,0,0.6)";
if (div.style.backgroundColor.indexOf("rgba") == -1) {
    div.style.backgroundColor = "#666";
}

The trouble with this version is that IE7 and IE8 throw a JavaScript error when you try to set a RGBa value for the backgroundColor property. This gave me an idea I could use though. If setting an RGBa colour throws an error, then we can catch it, ignore it and set the value as the hexadecimal fallback.

div = document.createElement('div');
try {
    div.style.backgroundColor = "rgba(0,0,0,0.6)";
}
catch(e) {
    div.style.backgroundColor = "#666";
}

This is the method I am currently using. If you know of a better way, let me know in the comments.

Animations on iPad using Zepto.js

Since leaving TMG, I’ve been working on a couple of iPad projects. I’m finding the Zepto.js library to be a huge help. It is essentially a stripped down version of jQuery. It gives you chaining, selectors and a nice API, but because it is only aimed at Webkit loses all the cross-browser stuff you get in jQuery Mobile.

One of the main jobs in building things for the iPad is adding nice smooth transitions and animations. I thought that the best way to do this would be to toggle a CSS class using JavaScript,

$('div.animate').toggleClass('newposition');

and then use CSS transitions to animate the change.

div.animate {
    position: relative;
    left: 0;
    -webkit-transition: left 1s linear;
}
 
div.newposition {
    left: 500px;
}

This was horrid though. The animation worked, but it was jerky at best, with lots of the intermediate steps not being rendered. I found that I got a much better result by using the anim() function provided by Zepto.

$('div.animate').anim({translate3d: '500px,0,0'}, 1, 'linear');

This works by adding the animation as inline CSS, but that means any further changes and CSS rules get increasingly complicated. The method I’m using to solve this problem is to setup a clean up function and call that once the animation has completed.

var cleanup = function() {
    $('div.animate').toggleClass('newposition').attr('style','');
}
$('div.animate').anim({translate3d: '500px,0,0'}, 1, 'linear',cleanup);

This seems to work pretty well, but am I overcomplicating things? Have you found a better way to handle animations?

HTML5 elements inside block level links cause styling issues in FF 3.6

I was fixing a couple of bugs in the new design or fineartdavid.com, the site I use for my artwork, and was reminded about something I found a while back, made a test suite for and then forgot about.

If you have one of the new HTML5 elements inside a block level link bad things happen in Firefox 3.6. I’ve tried explicitly setting the element to display: block in the CSS, but this hasn’t worked.

HTML5 elements in links test suite

It seems to me a fairly common use case. The exact code I wanted was a figure with a figcaption, all wrapped in an a, but right now this bug means we can’t have nice things.

Do you know a way to fix this? Am I missing something stupid?

Update

Remy Sharp is calling it a vomit bug which seems an appropriate name. zcorpan suggests in the comments that nesting a div could help so I’ve added that to the test suite.

Webkit (Safari and Chrome) removes links containing only floated elements from the tab order

I’ve just found a strange bug in Google Chrome.

I’ve been working on a set of templates for fineartdavid.com, and was testing them for keyboard accessibility. I hadn’t expected anything unusual because there is nothing very complicated in the the HTML. When I tabbed through the page however, the large images were being skipped.

At first I thought the problem was caused by block-level links. These are allowed in HTML5 and are a good solution to the design pattern where you have an image and a header both pointing to the same link.

<a href="#">
    <img src="/path/to/image.png" alt="descriptive alt text" title="" />
    <h2>Blog entry title</h2>
</a>

A few experiments showed that this was fine though, and that the problem only happened when the image was floated. Further investigations showed that any links that contain only floated elements are removed from the tab order.

Check out the test suite. Obviously has implications for accessibility, so lets hot it is fixed soon.

Update: I’ve updated the title because this happens in Safari too, meaning it is a Webkit, and not Chrome bug.

Update 2: I’ve filed a Webkit bug report.

Using a CSS gradient and a background image on the same element

I’ve spent the last 2 weeks working on the next version of the tmg website and I’ve been having a lot of fun using lots of CSS3.

One of the problems I ran into was having a background image and a css gradient on the same element. CSS gradient’s aren’t a part of the official W3C backgrounds and borders spec, but they have been implemented by Webkit (Safari and Chrome, amongst others) and Mozilla (Firefox) using vendor prefixes. The trouble with things that aren’t in the spec is that it is a bit harder to find the relevant documentation.

These won’t work

The problem stems from the fact that gradients are specified as a background-image, which means they override any previously declared background-image. If you do it in the opposite order, the background-image will override the gradient.
I’ve simplified the CSS here, but if you want to see the full code for each example just fire up Firebug or your browser’s built in developer tools.

.example1 {
	background-image: url(../images/plus.png);
	background-image: -moz-linear-gradient(top,  #cbe3ba,  #a6cc8b); /* for firefox 3.6+ */
	background-image: -webkit-gradient(linear, left top, left bottom, from(#cbe3ba), to(#a6cc8b)); /* for webkit browsers */
}
 
.example2 {
	background-image: -moz-linear-gradient(top,  #cbe3ba,  #a6cc8b);
	background-image: -webkit-gradient(linear, left top, left bottom, from(#cbe3ba), to(#a6cc8b));
	background-image: url(../images/plus.png);
}

This does work

Well it turns out that it is actually very easy to apply both a gradient and a background image to the same element. You can read about the Mozilla implementation and Safari (Webkit) implementation on their websites, or you can carry on reading here.
The trick is to set the gradient and the background-image using the multiple background syntax which is part of the W3C spec.

.example3 {
	background-image: url(../images/plus.png), -moz-linear-gradient(top,  #cbe3ba,  #a6cc8b);
	background-image: url(../images/plus.png), -webkit-gradient(linear, left top, left bottom, from(#cbe3ba), to(#a6cc8b));
}

How about combining the -moz- and -webkit- backgrounds?

Using this new found information, the obvious question is “can we use the multiple background syntax to declare the gradient for webkit and mozilla at the same time?”. Let’s find out.

.example4 {
	background-image: url(../images/plus.png), -moz-linear-gradient(top,  #cbe3ba,  #a6cc8b), -webkit-gradient(linear, left top, left bottom, from(#cbe3ba), to(#a6cc8b));
}

Rather annoyingly that doesn’t work. I would have thought that each browser would ignore the vendor prefixes it doesn’t know, but it looks like that only works for CSS property names, not values. Although thinking about it, that’s not what’s going on with the other examples because the vendor prefix is on the value there and not the property name.

Whatever the reason, it looks like we’ll have to stick to multiple, vendor-specific lines for the time being. Hopefully CSS gradients will be incorporated into the spec soon so we will only have to declare them once.