Tag: webkit

3 Golden Nuggets: CSS

It has come to my attention over the past month or so, I do infact have a lot to talk about on a blog. However, a lot of it usually derives from realisations and discoveries when I’m programming; while these are usually rich with information, they are also generally small in nature. Therefore I have decided to start a new series of blog posts: 3 Golden Nuggets. These will entail 3 profound points, about a predetermined topic, which I think you will find both enlightening and interesting.

My first topic of the series? CSS. I have spent a good few years (seven to be exact) learning and absorbing the various rules outlining this definitive language. Nonetheless, it still manages to surprise me with the various secrets in the ground-breaking CSS3 release. Here are just a few which I think will prove to be useful in future:

iOS touchStart: Grey overlay

When building the campaign page for the Dyson DC59, I came across a problem with the iOS UI. It was showing a translucent grey box overlay when the touchStart event is triggered on any element, which significantly impedes the premium feel of the page. After a significant amount of time ‘googling’, I came across a simple yet effective solution:

You might also notice on iOS, when you touch and hold a touch target such as a link, Safari displays a callout containing information about the link. This -webkit-touch-callout property allows you to disable that callout, as shown here:

IE CSS limitations

Only until recently, in work, had we been using a single CSS file for the styling of all our 85+ sites. We use Compass as our CSS framework, utilising the wonders of SCSS/SASS and concatenating all of our category/page specific files into a single entity. From a page load optimisation viewpoint, this seems completely sane, however it turns out if you’re unlucky enough to use Internet Explorer (couldn’t help myself) then you’ll find some limitations in how you are supplied the CSS styling rules. These limitations will either result in any styles which exceed the limitations not being rendered, or the CSS file itself failing to load at all. So for future reference, here are some important rules to note on CSS limitations:

  1. A sheet may contain up to 4095 rules
  2. A sheet may @import up to 31 sheets
  3. @import nesting supports up to 4 levels deep

Our solution in the end was to separate the @import’s into two separate files to be served to the browser.

Box-sizing property

Traditionally, I decided to save the best for last. I stumbled upon this CSS3 rule when I was taking a gander at the Google+ code in the Chrome inspector. I was both instantly shocked and excited when I saw it’s capabilities; shocked because I couldn’t believe I hadn’t found this rule until now and excited because this will solve a lot of past, present and future problems for me.

Usually when you add padding and/or borders to an element, it expands it’s size to cater for these three new values. So, for example, an element with a 250px width and 15px padding on the left and right would add an additional 30px to the final width of the element, resulting in a 280px width. This would prove especially troublesome when attempting to use a percentage value. Now enters the box-sizing rule; it enables the element’s padding and border values to be calculated inwards. Therefore an element with a height of 100px, with a top padding of 10px and a bottom border of 3px, will still remain 100px in the browser. Here is the webkit magic which enables this awesome feature:

For anybody using Compass, the shorthand is @include box-sizing(border-box);

I hope you’ve found my 3 Golden Nuggets informative; be sure to share the knowledge!

10th October 2013