Another demo, another bug

Everything I seem to investigate lately seems to present itself with an annoying bug/feature in various browsers. Last time it was the inconsistency between browsers and generated content on form elements. This time it is WebKit not being able to apply styles using the checked pseudo-class in conjunction with a general sibling combinator (E ~ F) or chained adjacent sibling combinator (E + F + F). Making it very hard, and probably the reason I haven’t seen a CSS solution that works in WebKit browsers. I did come across this demo but due to the bug mentioned above doesn’t work in WebKit browsers.

So I soldiered on and came up with a pretty decent attempt, and remember folks I’m not a designer so be kinder this time with design critiques all I’m doing is showing you how to do the technique . With that out of the way let’s dig into the inner workings and road blocks I faced.

General sibling combinators are flaky

The CSS3 selector module has a very useful addition to compliment the CSS2.1 adjacent sibling combinator. Unlike the adjacent selector the general selector gives us some flexibility in that it will match a sibling that isn’t immediately preceded by our first element.

Great, I have 3 elements an <input>, <label> & <ol> the general sibling combinator is the perfect tool to do things like input:checked ~ ol. Check Firefox, awesome works, Opera too! Woo! Surely WebKit will have this…nope nothing. Let me try input ~ ol, yep works across the board, *face palm*.

So I dug into WebKits bug tracker and came out with this bug which has been around since 2007. Stating that general sibling combinators in combination with dynamic CSS, ala :checked, won’t reflect changes. Nor will it do chained adjacent combinator which was going to be my next solution.

However doing :checked with a single adjacent sibling combinator works fine in post 2008 WebKit browsers. So using this information I went about and built a working demo that has good browser support.

The demo is built using an ordered list (ol) nested with further ordered lists to naturally represent a basic folder structure.

<ol>
    <li class="file"><a href="document.pdf">File 1</a></li>
    <li>
        <label for="subfolder1">Subfolder 1</label>
        <input type="checkbox" id="subfolder1" />
        <ol>
            <li class="file"><a href="">File 2</a></li>
            <li class="file"><a href="">File 2</a></li>
            <li class="file"><a href="">File 2</a></li>
        </ol>
    </li>
</ol>

As you can see, in order to get around the general combinator issue in WebKit based browsers I have switched the label to come first then the input so the “folders” could be expanded/collapsed by checking/unchecking the checkbox.

li input
{
    position: absolute;
    left: 0;
    margin-left: 0;
    opacity: 0;
    z-index: 2;
    cursor: pointer;
    height: 1em;
    width: 1em;
    top: 0;
}
li label
{
    background: url(img) 15px 1px no-repeat;
    cursor: pointer;
    display: block;
    padding-left: 37px;
}

To sit the input and label in the right visual order I absolutely positioned the input and applied a left padding to the label to push it out. That way changing the styles of the child ol, when the input is checked, can be done using the adjacent sibling combinator. I’ve also set the cursor to pointer when hovered over the input or label to visual show they’re clickable.

li input + ol
{
    background: url(toggle-small-expand.png) 40px 0 no-repeat;
    margin: -0.938em 0 0 -44px; /* 15px */
    display: block;
    height: 1em;
}

Unlike my custom radio and checkbox article where I added the background image on the label, this time I had to do some trickery and apply it to the direct sibling ol of an input. Applying a sprite image to the ol wouldn’t be possible in this situation due to it being applied to the ol which would make it difficult to effectively hide other images within the sprite image.

To position the ol correctly I use a negative margin to pull it into the right location so it will sit next to the label and underneath the invisible checkbox.

li input + ol > li
{
    height: 0;
    overflow: hidden;
    margin-left: -14px !important;
    padding-left: 1px;
}

To hide the sub folders so they don’t appear when the parent folder is collapsed I target the child list items and set them to a zero height and hide any overflow.

li label
{
    background: url(folder.png) 15px 1px no-repeat;
}
li.file a
{
    background: url(document.png) 0 -1px no-repeat;
    color: #fff;
    padding-left: 21px;
    text-decoration: none;
    display: block;
}

To differentiate between folders and files I applied a background image to either the label or to an anchor within a list item for files.

li
{
    position: relative;
    margin-left: -15px;
    list-style: none;
}
li.file
{
    margin-left: -1px !important;
}

To pull out the folder list items I apply a larger negative margin so the folder will line up with any of the file icons, and for file based list items I reset the left margin so they sit flush.

Change icon based on file extension

With some CSS3 attribute selectors we can determine an anchor links file format and change the icon accordingly.

li.file a[href $= '.pdf']     { background-position: -16px -1px; }
li.file a[href $= '.html']   { background-position: -32px -1px; }
li.file a[href $= '.css']    { background-position: -48px -1px; }
li.file a[href $= '.js']      { background-position: -64px -1px; }

Using the $= CSS attribute selector allows us to check the end of an attribute exactly ends in .pdf, .html etc.

If for some reason you attribute doesn’t end with your file extension, your anchor may have a query string on the end. We can still match file types.

li.file a[href *= '.pdf']   { background-position: -16px -1px; }
li.file a[href *= '.html']  { background-position: -32px -1px; }

The *= will match a substring that contains .pdf or .html anywhere within the attribute and if a href has a query string we can still match our file extension without issue. This does have the slight disadvantage that it will match it anywhere e.g. if you have a file called file.html.pdf it will match both file types and the one with the higher CSS specificity will be applied or incase of the example above their CSS specificity is the same so the html background will be applied.

Checkbox attributes

In the demo by default the first folder is open, this is done by adding the checked attribute to the checkbox which will trigger our styles thanks to the checked pseudo-class and reveal its sub files and folders.

We can also add the disabled attribute to the checkbox to stop a user from opening a folder as the input can neither be checked or unchecked.

Lastly using a combination of both disabled and checked will allow us to reveal the sub files and folders but not allow the user to close the top level folder.

Browser support

Based on testing this will work in any CSS3 selector supporting browser. The following have been tested and known to work

• Firefox 1+
• Opera 9.6+
• Safari 4+
• iPhone/iPod Safari
• Chrome 1+
• Android
• IE9+

This could very well work in IE8 but would require some JavaScript to get IE8 to interpret the checked pseudo-class, which I won’t be going into.

Right now I use conditional comments to hide the stylesheet from all versions of IE and another conditional comment to load the stylesheet for IE9 and greater.

<!--[if gte IE 9 ]>
    <link rel="stylesheet" type="text/css" href="_styles.css" media="screen">
<![endif]-->
<!--[if !IE]>-->
    <link rel="stylesheet" type="text/css" href="_styles.css" media="screen">
<!--<![endif]-->

Highly scalable

This technique will cater for a large amount of sub folders and files. It’s governed by your screen real estate and even then it’ll apply scroll bars to the document when the tree structure gets too long or wide.

Any questions/comments/suggestions leave a comment.

Short URL: http://cssn.in/ja/026

But you’re thinking I’m mad, there can’t possibly be any other way to trigger a pure CSS overlay.

Radio buttons?!

Yep this technique uses radio inputs along with the checked CSS3 pseudo-class, which I described in my custom checkbox/radio inputs article, to show/hide the futurebox modals.

<ul>
    <li>
        <label for="futurebox01">
            <img src="image.gif" width="100" height="102" alt="The CSS Ninja" />
        </label>
        <input type="radio" id="futurebox01" name="gallery" />
        <div class="overlay">
            <label for="close" title="Close futurebox">
                <img src="image.png" alt="The Css Ninja" width="469" height="500" />
            </label>
        </div>
    </li>
</ul>

The mark-up differs from the original futurebox. The overlay now needs to appear directly below the image, the images are wrapped in a label as well as the overlay, we set the “for” attribute on the label so we can check the radio without having to actually click the radio. We also use that to our advantage so we can actually close the modal once it’s been opened by having the large image wrapped in a label with a “for” attribute to a hidden radio button.

Having the same name value on all the inputs makes sure only one of the radio buttons can be checked at any one time.

ul li input { display: none; }
ul li input:checked + .overlay { display: table; }

Since we don’t actually want or need to see the radio button we hide it. As mentioned before the “for” attribute controls the checking and unchecking of the input.

Unfortunately due to a bug in IE (you’ll need to login to view it, or just change your UA string to googlebot ) only labels with text trigger the input. Since IE9 is the first IE to support the checked pseudo-class if this bug is fixed this technique will work, until then it won’t. Let’s hope a fix makes it into IE9 final release.

The second line uses the checked pseudo-class to apply display: table to the inputs direct sibling with a class of overlay.

.overlay
{
    width: 100%;
    height: 100%;
    position: absolute;
    top: 0;
    left: 0;
    display: none;
    z-index: 999;
    background: rgb(0,0,0);
    background: rgba(0,0,0,0.7);
}
    .overlay label
    {
        display: table-cell;
        vertical-align: middle;
        text-align: center;
    }

The overlay styles don’t differ at all to the original demo, except that instead of an anchor tag wrapping the image it’s now a label. When the input is checked the overlay sibling of that input becomes visible, by setting it to display: table, as shown in the previous CSS block. The label has display: table-cell applied to it so it’ll act like a table cell and naturally fill all height and width available to it. Applying vertical-align: middle will make the image vertically center and to horizontally center the image we take advantage of the fact that images are inline elements and just set the label to have text-align: center.

Not just for images

Since futurebox was only ever originally meant for loading images I thought I would extend this new version to also load static and dynamic content (iframes). In the demo the second listing shows 2 examples of static content and 2 examples of loading an iframe.

Static content

In order to show static content within a futurebox overlay the mark-up differs slightly.

<ul>
    <li>
        <label for="futurebox01">
            <img src="image.gif" width="100" height="102" alt="The CSS Ninja" />
        </label>
        <input type="radio" id="futurebox01" name="gallery" />
        <div class="overlay">
            <label for="close" title="Close futurebox">
                <span class="content01">
                    <span class="inner_content">
                        // content goes here
                    </span>
                </span>
            </label>
        </div>
    </li>
</ul>

Rather than have the image we have 2 spans, although 1 is fine I used 2 to make the scrolling look nicer.

.content01
{
        display: block;
        width: 460px;
        padding: 20px;
        background: #fff;
        color: #000;
        margin: 0 auto;
        text-align: left;
        cursor: auto;
        -webkit-border-radius: 10px;
        -moz-border-radius: 10px;
        border-radius: 10px;
}
    .content01 .inner_content
    {
        display: block;
        height: 500px;
        overflow-y: auto;
    }

The content span I apply a base width and some padding along with applying some CSS3 to give the modal some nice rounded corners.

The inner content span I set a fixed height and apply overflow-y to auto so any content that extends further will show a vertical scrollbar otherwise if the content fits it will hide the scrollbar.

The reason I use spans and not divs is because a label is a inline element and putting divs inside it is not only invalid but will also cause render issues in some browsers. So using a span and setting it to display: block handles that dilemma.

Change the height of individual modals

Since the base height of the static content container is quite high putting in a small amount of content will create alot of empty white space. You can get around it by targeting specific futurebox modals and set the height to something else.

#futurebox07 + .overlay .inner_content { height: 265px; }

Each input has their own id so the “for” attribute will work on the labels, we can then use that id to target specific modals and change their height.

It’s an iframe

Loading static content has a lot of great uses but sometimes only an iframe can handle some situations such as submitting a form within a modal or loading an external resource.

The first iframe example loads up my contact page, feel free contact me, so you can submit a form without affecting the modal or causing a post back on the parent page.

The second iframe loads a Google search for futurebox.

Since iframes are naturally inline placing it inside a label isn’t invalid and won’t cause any browser issues.

.overlay iframe
{
    background: #ffffff;
    border: none;
    padding: 10px;
    -webkit-border-radius: 10px;
    -moz-border-radius: 10px;
    border-radius: 10px;
}

To give the iframe the same padding and rounded corners as the images and static content modals, we add a few styles to reset the iframes border, add some padding, set the background and apply some border-radius values to give it rounded corners.

Close buttons

I’ve also added close buttons on the static and iframe modals, these are purely for show and don’t technically close the modal since clicking anywhere on the overlay will close the modal. It’s purely there to give the user the feeling they are actually closing something by clicking a button, rather than the background.

<label for="close" title="Close futurebox">
    <span class="content01 content02">
        <strong class="closebutton" title="Close futurebox">X</strong>
        // content
    </span>
</label>

To add the close button I’ve added a strong tag within the content container. I’ve just added an X inside to represent the close action and added a title attribute so it makes sense.

.closebutton
{
    background: #606061;
    color: #FFFFFF;
    cursor: pointer;
    height: 24px;
    line-height: 24px;
    overflow: hidden;
    position: absolute;
    right: -12px;
    text-align: center;
    top: -12px;
    width: 24px;
    -webkit-border-radius: 12px;
    -moz-border-radius: 12px;
    border-radius: 12px;
    -moz-box-shadow: 1px 1px 3px #000;
    -webkit-box-shadow: 1px 1px 3px #000;
    box-shadow: 1px 1px 3px #000;
}

Since we have fixed width content it makes it possible to position it correctly while still keeping the futurebox horizontally centred, that’s the reason there is no close on the image based modals as the width can vary from image to image. To sit the button to the right of the futurebox I absolutely position it and set top and right to -12px so it will sit slightly offset from the container.

To create the circle effect I set the width and height to 24px and apply a border-radius of 12px for either side which will create our circle.

.closebutton:hover
{
        background: #318DF2;
        text-shadow: 1px 1px 1px #ccc;
}

When the user hovers over the close button I change the background-color and give the X a light drop shadow.

Mix it up

We can mix up the styles of the futurebox by adding a class to the parent ul, in the last list example I’ve added a class to do just that.

.theme01 .overlay
{
    background: none;
}
    .theme01 .overlay label > img,
    .theme01 .overlay iframe,
    theme01 .content01
    {
        border: 1px solid #ccc;
        -moz-box-shadow: 5px 5px 10px #000, -5px -5px 10px #000;
        -webkit-box-shadow: 5px 5px 10px #000, -5px -5px 10px #000;
        box-shadow: 5px 5px 10px #000, -5px -5px 10px #000;
    }

Instead of a semi transparent rgba background, I’ve reset the background to none and applied a dual box shadow to the overlay items.

Love it, hate it?

Think it’s awesome, think it’s an abomination? Let me know what you think or if you have any suggestions on how you think it could work better make sure to leave a comment.

Short URL: http://cssn.in/ja/025

I’ve been sitting on this little idea for a while and as a bit of fun I finally got around to putting it together and properly testing it. Basically on an iPhone with geolocation support (3.0+), I have set up a little web app that will get the speed from the GPS and move the speedometer needle according to your current speed in kilometres.

But speed returns null?

When I originally played around with the geolocation API on the iPhone checking the speed attribute always returned null, what I failed to actually do was test this value while actually moving. The speed attribute is capable of getting speeds as low as 2km/h so walking with the phone will start to register speeds.

So we can get the speed let’s use it

if(navigator.geolocation) {
    navigator.geolocation.getCurrentPosition(getSpeed, handleError);
}
function getSpeed(pos) {
    updateStats(pos);
 
    var coordsListener = navigator.geolocation.watchPosition(updateStats, handleError);
}

Here we get the current position and upon success tell it to execute the getSpeed function. Inside that function I call another function which does all the hard work which I’ll explain below, next I call the watchPosition method and pass it the same updateStats function so we can get constant updates from the GPS about our speed and adjust our speedometer needle.

function updateStats(pos) {
    var speed = pos.coords.speed,
         speedVariation = 3.6,
         currentSpeed = Math.round(speed*speedVariation),
         angleVariation = 0.8,
         initSpeedAngle = -105,
         speedAngle = initSpeedAngle + (currentSpeed * angleVariation);
 
    needle.style.webkitTransitionDuration = '500ms';
    needle.style.webkitTransform = "rotate(" + speedAngle + "deg)";
    speedVal.textContent = currentSpeed + "km/h";
}

var speed = pos.coords.speed,
     speedVariation = 3.6,
     currentSpeed = Math.round(speed*speedVariation);

When I get my initial position and my subsequent position updates through the watchPosition method, I access the current speed, in metres, through the coords attribute. To work out the rough speed I times the speed by the speedVariation var which is 3.6 which will give me the speed in km/h, for miles/hour the variation is 2.237. I do this calculation inside the Math.round function so I get a whole rounded number with no decimal places.

var angleVariation = 0.8,
     initSpeedAngle = -105,
     speedAngle = initSpeedAngle + (currentSpeed * angleVariation);

To calculate the corresponding angle to the equivalent speed we are currently getting from the GPS I had to work out the angle variation per kilometre. I knew there was 16° between each 20km/h block. The angle variation then could be worked out to be 0.8° per kilometre, I also needed to have the starting angle of 0km/h and that is exactly -105° from our middle point. With those 2 values plus the currentSpeed I could then work out the angle so the speedometer needle could be correctly rotated to the right spot.

needle.style.webkitTransitionDuration = '500ms';
needle.style.webkitTransform = "rotate(" + speedAngle + "deg)";
speedVal.textContent = currentSpeed + "km/h";

To move the needle when the speed changes and to make that change animate between the two points I use CSS3 transforms and transitions. By setting our -webkit-transition-duration any changes done using the -webkit-transform property will be transitioned smoothly between the current angle and the new angle. The last bit is just to print out the speed so we can compare the needle position to the actual speed being read.

Some CSS3

I’ve added some extra CSS3 to the speedo including animations and box-shadow

#dial #needle
{
    -moz-box-shadow: 1px 1px 3px #ffd712, -1px -1px 3px #feb018;
    -webkit-box-shadow: 1px 1px 3px #ffd712, -1px -1px 3px #feb018;
 
    -webkit-animation-name: speedorgo;
    -webkit-animation-duration: 2s;
}

To add the slight glow around speedo needle by using a dual box-shadow so it appears on both edges. The -webkit-animation- properties allows me to specify a predefined animation that can be applied to different elements.

@-webkit-keyframes speedorgo {
    0%   { -webkit-transform: rotate(-105deg); }
    20%  { -webkit-transform: rotate(41deg); }
    100% { -webkit-transform: rotate(-105deg); }
}

By using webkits @-webkit-keyframes rule and giving it a unique name which we applied to our speedo needle in the previous CSS using the -webkit-animation-name property we can do some pretty cool animations. Inside this animation rule I set up the animation to rotate any element it’s applied to to go from -105° to 41° then back to -105° when you rotate the phone into landscape mode it’ll trigger the animation and do the animation over a 2 second period.

Pfft! Who needs the internet…

Well technically we initially need the internet but after we load the web app for the first time no connection is required for this to work. By taking advantage of the application cache we can store all our assets on the phone, and since the GPS can still work without a network connection the speedo will still function fine.

A clear sky

In order to pick up a consistent speed reading from the GPS you will need to have the phone with a good clear view of the sky. I’ve found when using it while walking the speed reading will fluctuate quite a lot, going from 0 to the actual speed your doing and back to 0 and back up etc. It becomes more reliable the faster you are moving. I’m sure with some adjustments to the code getting a more consistent speed reading will be possible.

Go forth and hack

We have a fun little tech demo that shows what can with some simple JavaScript and CSS3. I don’t see why this couldn’t work on an Android, Palm Pre or a Blackberry with the new webkit browser, all of these should or should very soon support the features required for the web app to work. If you get this working in any other smart phone please leave a comment.

Short URL: http://cssn.in/ja/024

It’s a bug, no it’s intended…well actually it’s still a draft

So upon my initial investigation of how doing something like this would be possible, I came across what I initially thought was a bug with Firefox and IE8. Applying CSS generated content to form elements doesn’t work, turns out Firefox and IE8 are following the CSS3 draft specification as specified in the CSS3 Generated and Replaced Content Module.

The box model defines different rules for the layout of replaced elements than normal elements. Replaced elements do not have ‘::before‘ and ‘::after‘ pseudo-elements;…

Form elements fall under the “replaced elements” category and therefore don’t allow :before and :after pseudo-elements on them. However Safari, Chrome and Opera all allow generated content on form elements. Further to the odd behaviour Chrome and Safari will only apply generated content on checkboxes, radios and file inputs whereas Opera will allow it for all form elements, see test case.

You can see my initial attempt at creating custom radios and checkboxes. This applied the generated content directly to the inputs themselves. Open up the demo in Safari or Chrome to see it working. This presented yet another problem this time with Opera, clicking the radio or checkbox directly would never actually check the box whereas with Chrome and Safari the box would be checked and the custom replacement would change state accordingly. But if you clicked the label, which uses the for attribute to create the relationship to the corresponding input, it would check the input in Opera and change the custom check state correctly.

I then thought I would see if I could fix it by using some JavaScript to check the input onclick, this worked for Opera but stopped it working in Chrome and Safari as it was putting it in an indefinite indeterminate state, as it was checked then quickly unchecked by the JavaScript.

document.body.onclick = function (evt) {
    var node = evt.target;
 
    if(node.nodeName === "INPUT") {
        var isChecked = node.checked;
        (isChecked) ?
            isChecked = false :
	    isChecked = true;
    }
}

As there was no safe obvious way that didn’t involve browser sniffing or using bad object detection to determine if the browser behaved in this way. And the fact it was taking away from the whole point of this demo, to create a CSS only solution for custom forms, I scrapped my idea and went back to the drawing board.

Selectors, pseudo-classes & pseudo-elements

As you can see from the demo each radio and checkbox is replaced with a custom one. The difference here from my initial attempt, and to get around the fact you can’t apply generated content to form elements consistently, is to apply the generated content to the label rather than the input itself, and using some clever selectors I can determine the state of the radio/checkbox is in and adjust the custom replaced one accordingly. I also set the original input opacity to 0 so it won’t show through our custom one.

<p>
    <input type="radio" value="male" id="male" name="gender" />
    <label for="male">Male</label>
</p>

The HTML isn’t bloated and needs no extra mark-up

p:not(#foo) > input + label
{
    background: url(gr_custom-inputs.png) 0 -1px no-repeat;
    height: 16px;
    padding: 0 0 0 18px;
}

Basically this selector is looking for a label that is immediately preceded by a sibling input, that is a child of a paragraph that doesn’t have an id of foo and lastly it has the :before pseudo-element so we can add our custom radio input. The reason for the not selector is to not apply these styles in IE8, I’ll explain why further down.

Update: Thanks to Lea and Mr.MoOx for their suggestions this now uses a sprite image. Rather than insert the image in the content property, I apply a background and insert 3 non-breaking space characters, since the content property doesn’t accept named entities I used the unicode equivalent of \00a0. The reason I insert 3 is because Firefox 1.5 won’t show the full background unless I put 3 in there and using a fullstop and applying color: transparent doesn’t work in FF 1.5.

To get this working in older browsers such as Firefox 3 and down I use a negative margin to get it to sit in the right place. Support for absolutely positioned generated content was only recently added in Firefox 3.5+. I then adjust the newer browsers by offsetting the left value to be equivalent of the left margin.

Update 2: Thanks to Marius for demonstrating that the :before pseudo-element is superfluous and adding the background directly to the label itself with a few adjustments works just fine and removes the hacky need for using the content property with 3 non-breaking space.

I moved the previous demo and it’s source files to a legacy folder so you can still get them if you want.

Now all the radios have been replaced by our custom versions we need to be able to tell if the radio is checked so we can adjust our custom state.

p:not(#foo) > input[type=radio]:checked + label {
    background-position: 0 -241px;
}

Again this is the same as the previous selector with one difference, we add the :checked pseudo-class available in the CSS3 selectors module to determine the radios state in CSS and change it upon the user checking the radio.

Of course the control doesn’t end there we also utilise the :hover, :focus, :active & :disabled pseudo-classes to change the radio on hover, when it has focus (for keyboard support), when the input is active (click and hold your mouse cursor to see this state change) and when it’s disabled. Mixing this with the :checked pseudo-class lets us control all possible states of the radio input and gives us great control and flexibility that doesn’t require a mouse nor JavaScript to control the states.

p:not(#foo) > input[type=radio]:hover + label,
p:not(#foo) > input[type=radio]:focus + label,
p:not(#foo) > input[type=radio] + label:hover { 
    background-position: 0 -181px; 
}
p:not(#foo) > input[type=radio]:hover:checked + label,
p:not(#foo) > input[type=radio]:focus:checked + label,
p:not(#foo) > input[type=radio]:checked + label:hover  { 
    background-position: 0 -261px;
 }
p:not(#foo) > input[type=radio]:disabled + label,
p:not(#foo) > input[type=radio]:hover:disabled + label,
p:not(#foo) > input[type=radio]:focus:disabled + label,
p:not(#foo) > input[type=radio]:disabled + label:hover,
p:not(#foo) > input[type=radio]:disabled + label:hover:active { 
    background-position: 0 -221px; 
}
p:not(#foo) > input[type=radio]:disabled:checked + label,
p:not(#foo) > input[type=radio]:hover:disabled:checked + label,
p:not(#foo) > input[type=radio]:focus:disabled:checked + label,
p:not(#foo) > input[type=radio]:disabled:checked + label:hover,
p:not(#foo) > input[type=radio]:disabled:checked + label:hover:active {
     background-position: 0 -301px; 
}
p:not(#foo) > input[type=radio]:active + label,
p:not(#foo) > input[type=radio] + label:hover:active { 
    background-position: 0 -201px; 
}
p:not(#foo) > input[type=radio]:active:checked + label,
p:not(#foo) > input[type=radio]:checked + label:hover:active {
     background-position: 0 -281px; 
}

Another addition I have made to the CSS is also changing the input states when the user hovers, clicks or focuses on the label it will now change the input to reflect those actions.

IE8 is almost there

IE8 can do everything, except it doesn’t support the :checked pseudo-class and therefore makes this technique useless. So I use the not() pseudo-class, which IE8 doesn’t support, to work around this unfortunate lack of ability. Let’s hope IE9 adds the CSS3 selector module¹. This of course degrades nicely in non-supporting browsers and fallback to the browser default form elements.

¹ IE9 does support the CSS3 selector module so this technique has across the board support for all major browsers.

Accessible and friendly

CSS generated content doesn’t get in the way of a screen reader and they have a clear view of the form elements CSS generated content is no longer used it’s now a background image on the label rather than doing it on the generated content see update (I would appreciate any accessibility experts or screen reader users to please comment to correct or agree with me). Users, who have trouble operating a mouse or, like me, prefer navigating forms with the keyboard as it’s faster, aren’t left out. Tabbing through the inputs changes the states, pressing spacebar to check a radio or checkbox also changes the state. I also change the label colour and give it a text-shadow to give a nicer indication that the current input has focus.

The disabled and checked attributes work as intended with this solution and don’t require any trickery to achieve that.

<p>
    <input type="radio" disabled value="male" id="male" name="gender" />
    <label for="male">Male</label>
</p>
<p>
    <input type="radio" checked value="Female" id="female" name="gender" />
    <label for="female">Female</label>
</p>

As you can see from the above mark-up adding the disabled or checked attributes (disabled=”disabled” & checked=”checked” also work) will allow us to target those states using the :checked and :disabled pseudo-classes. As well as change the style if we use JavaScript to disable any inputs based on users actions.

Browser support and notes

As of writing the following browsers have been tested and known to work with the demo:

• Firefox 1.5+
• Opera 9.6+
• Safari 3.2+*
• iPhone/iPod Safari**
• Chrome 4+
• IE9+

Will run this demo through browsershots and update it accordingly if the browser support works in any lower versions mentioned

* This would work in Safari 3.2 except due to a bug. The checked pseudo-class will work just fine if it has the checked attribute on the input but won’t change the input state if the user checks the input with their mouse or keyboard (the actual input will check but the CSS state won’t update the custom input image).

* This now works in Safari 3.2 but, and a big but, the behaviour is quite bizarre. Clicking a radio or checkbox will change the custom state but clicking it again to uncheck won’t show until you have hovered away from or taken focus away from the input. If you have Safari 3.2 installed try the new demo to get a better understanding of what’s happening.

** To get the iPhone to work with this demo I had to apply the pointer-events CSS property. Since the input is actually sitting on top of the background image we no longer need to apply pointer events to the label.

p:not(#foo) > input + label
{
    pointer-events: none;
}

Here for legacy reasons no longer needed for iPhone support

Since having the generated content sit over the top of the actual checkbox, iPhone Safari needed a kick up the bum with the pointer-events property so we could click through the custom checkbox to the actual checkbox. Desktop Safari works fine without it.

Drawbacks

Resolved see update above. This technique has only 1 drawback I can think of, IE support is not a drawback for me, you can’t use a big sprite image to save all the radio and checkbox states, they need to be individual images. Using CSS generated content to insert an image doesn’t give you control of the image position like a background image does. The images are small in size and the initial load of each state shouldn’t be noticed. If however you wish to preload all the images take a look at my CSS based image preload technique. That technique will create quite a few http request depending on how many images you preload but since they’re small in size it shouldn’t be a major concern.

Short URL: http://cssn.in/ja/023

There’s a better way

The article instantly got me thinking on a potential alternate method to accomplish the same task, but using a widely available CSS2.1 property. Which if possible will up the browser support significantly. Thankfully the idea actually worked.

CSS generated content

In CSS2 a content property was introduced, which in conjunction with the :before and :after pseudo-elements allows us to generate content in a document. The most interesting value that can be used with the content property is url() which allows us to pass an image.

content: url(img01.jpg);

That’s all great than we can add a single preloaded image using the content property but what about multiple images? That’s where the content property shows its true power, we can pass multiple url’s.

content: url(img01.jpg) url(img02.jpg) url(img02.jpg)

Brilliant, we can now preload multiple images using one line of CSS. We have all the benefits of the CSS3 method without the CSS3 and the Browser support grows exponentially.

• IE8+
• FF2+
• Safari 3+
• Chrome 1+
• Opera 9.62+

Putting it all together

Now we know how to preload multiple images using CSS2, lets put it all together:

body:after
{
content: url(img01.jpg) url(img02.jpg) url(img03.jpg);
display: none;
}

Instead of creating an empty div with a class on it, we can utilise the requirement of the :after (or :before) pseudo-element. This needs to be there for the content property to work. We apply it to generate the content after the body tag and then set it to display: none, that way the preloaded images aren’t shown but are still loaded. We know have a pure CSS solution that requires no mark-up.

Almost perfect

IE6 and 7 do not support CSS generated content and therefore will not preload any images, but that’s a minor trade off. Users of IE6/7 will just have to load the images when they are called rather than getting them from the cache.

A possible work around for their lack of support is to use conditional comments to load the images. This solution will require extra mark-up.

• Images are lazy loaded so they are only called when the futurebox overlay is activated.
• You can scroll through using next/previous buttons
• Use the keyboard to activate or close futurebox. Overlays can be opened in any order using the keyboard.
• Generated content for image description and counters
• CSS transitions for webkit browsers

It’s back with a vengeance

The overall markup hasn’t been altered all that much compared to the original it just adds useful functionality.

<ul class="overlay_container">
	<li class="overlay" id="futurebox_img2">
		<a href="#close" title="Close future box"></a>
		<p title="Image description goes here">
			<a href="#futurebox_img1" rel="prev" title="Previous">&lt;</a>
			<a href="#futurebox_img3" accesskey="3" rel="next" title="Next">&gt;</a>
		</p>
	</li>
</ul>

The anchor tag is now empty as we load the image as a background. A paragraph tag containing our next and previous links along with a title attribute so we can give the image a small description. The rest of the markup and foundation CSS stays pretty much the same.

Due to the complex nature of this updated version browser support is not a great as the original version. I will run this through a browser screenshot service and confirm browser support. If you come across any weird behaviour please make a comment about it.

Lazy loading images

In the original demo the images were loaded in the page essentially slowing down the load time. I’ve fixed that by using a lazy load technique, rather than having an <img> tag I set a background on the overlay anchor tag. The image is only downloaded when the user clicks on a thumbnail.

.overlay:target > a { background: url(gr_cssninja_lrg.png) 50% 50% no-repeat; }

We use the #futurebox_img2.overlay selector for all other overlays to target each item so we can change the background image correspondingly.

Scroll through images

I have added ability to scroll forwards and backwards through the images using buttons. These form part of the markup in each overlay item essentially just applying the previous images id in the href and the same for the next button.

<a href="#futurebox_img1" rel="prev" title="Previous">&lt;</a>
<a href="#futurebox_img3" accesskey="3" rel="next" title="Next">&gt;</a>

On each next/previous link we use the rel attribute so we can target it in CSS using attribute selectors

.overlay > p a,
.overlay > p a[rel=next]
{
	/* styles here */
}
.overlay > p a[rel=prev]
{
	/* styles here */
}

Keyboard navigation

Along with navigation buttons to scroll through the images you can use the keyboard to scroll through in any order. Closing futurebox is also possible using the keyboard. This is done using accesskeys and controls vary in different browsers and platforms.

<a href="#futurebox_img3" accesskey="3" rel="next" title="Next">&gt;</a>

Using the numbers you can scroll through up to 10 images using the 0-9 numbers and the corresponding keyboard combination in your browser:

• Firefox Windows: Alt + Shift + 0-9
• Safari/Chrome Windows: Alt + 0-9
• Opera Windows: Shift + Esc (This brings up a menu where you press the accesskey you wish to activate)

To close futurebox the access key is x. If you know of any other keyboard combinations, especially the Mac equivalents, I’ll update the article.

CSS generated content

It is now also possible to add a small description below each image using the CSS content property.

.overlay > a + p:after
{
	content: "No. " counter(futurebox) " " attr(title);
}

That snippet will get the paragraph tag that is a direct sibling of the anchor tag that is a direct child of the overlay class. Using the :after pseudo-element is how we can append the content after the paragraph.

We also use generated content to do automatic numbering of each image using the counter-reset and counter-increment properties in conjunction with the counter() function used in the content property.

.overlay_container 	{ counter-reset: futurebox; }
.overlay_container > li 	{ counter-increment: futurebox; }

We first reset the counter so we know it will start from 1, we also give it a unique name e.g. futurebox but this can be anything. Then in the following line we increment the counter for each list item inside the overlay_container, we use the child selector to make sure it only counts top level list items. The counter increment idea came from this blog post about doing a css based gallery (it’s in Russian so you’ll need to run it through a translator).

Animation without the JavaScript

One of the most requested features for futurebox was using webkits CSS transitions property to animate scrolling between images. So in this version I have added fading between image overlays. In Chrome and Safari we animate the opacity of the image so it will fade in upon activation.

.overlay a
{
	opacity: 0;
	-webkit-transition: opacity 1s ease;
}
.overlay:hover a { opacity: 1; }

To setup the transition we set the opacity to 0 and tell the transition to ease the opacity over 1 second. The reason I activate the transition on :hover and not :target is that target will not transition upon activation, whether this is a bug will take some further investigation.

To stop issues in browsers that don’t support transitions. I wrapped the transition styles in a media query.

@media (-webkit-transition) {
	/* Styles here */
}

This will only target webkit browsers that support the -webkit-transition property. When Firefox & Opera add support for transitions hopefully they will add support for this media query.

Another issue with transitions is hover will fail to activate if you launch futurebox using the keyboard, moving your mouse will then trigger the transition to execute. Only the initial launch is affected using the keyboard to scroll through other images will trigger the transition correctly.

Some things to note

While this does have good browser support it won’t work in IE and I don’t see it working without considerable use of hacks. There is however a fantastic article over at Carsonified on creating a lighbox effect that works in IE.

To continue my effort to accomplish tasks in CSS that are usually reserved for JavaScript, such as my Futurebox and CSS based iPhone orientation detection. I have developed a CSS based version of the popular “accordion effect” that utilises the webkit CSS transitions. Like the Futurebox demo I’m utilising the CSS3 :target pseudo class to know which item to show based the URI fragment identifier (the # in the url).

It should be noted that this works best in a webkit based browser such as Safari 3+, Chrome or iPhone. Other browsers that support the :target pseudo class will still function on the core level but won’t animate the showing and hiding. The following browsers have been tested and work with this demo.

• Firefox 1.5+
• Opera 9.6+
• Safari 3+
• Chrome 1+
• IE6+ – IE solution

The xhtml

<dl>
	<dt><a href="#Section1">Section 1</a></dt>
	<dd id="Section1">
		<p>
			Lorem ipsum dolor sit amet...
		</p>
	</dd>
	<dt><a href="#Section2">Section 2</a></dt>
	<dd id="Section2">
		<p>
			Lorem ipsum dolor sit amet...
	</dd>
	...
</dl>

We setup the accordion using a definition list to create the foundation so we can show and hide the definition data (dd) tag when the user clicks the anchor link inside the definition title (dt) tag.

The CSS

dl
{
	padding: 10px;
	min-width: 960px;
}
	dl dt
	{
		-webkit-border-radius: 5px;
		-moz-border-radius: 5px;
		border: 1px solid #cccccc;
		margin: 0;
	}
		dl dt a
		{
			color: #ffffff;
			font-weight: bold;
			text-decoration: none;
			padding: 10px;
			display: block;
		}
	dl dd
	{
		margin: 0;
		height: 0;
		overflow: hidden;
		-webkit-transition: height 1s ease;
	}
		dl dd p
		{
			padding: 10px;
			margin: 0;
		}
	dl dd:target
	{
		height: auto;
	}
 
@media (-webkit-transition) {
	dl dd:target
	{
		height: 6.667em;
	}
}

Pretty simple CSS involved, the dd tag is hidden by setting the height to 0 and the overflow to hidden.

-webkit-transition: height 1s ease;

This property on the dd tag lets webkit browsers know we wish to transition the height value over 1 second period using the ease timing function this transition will only happen when the height of the dd tag is changed. We can also express this in a long hand version.

-webkit-transition-property: height;
-webkit-transition-duration: 1s;
-webkit-transition-timing-function: ease;

To change the height we use the :target pseudo class to set the height of the dd tag to auto so the right content will show based the URI fragment identifier. For webkit browsers it’s a little different.

Webkit media queries

In webkit browsers there are additional media queries available so we can target browsers that support the extended features such as transitions and not affect other browsers. In this demo I use the @media (transition) media query.

Webkit implements this feature by using their -webkit vendor extension so the media query looks like the following

@media (-webkit-transition) {
	dl dd:target
	{
		height: 6.667em;
	}
}

Unfortunately setting the height of the dd tag to auto will not make it animate although this would be ideal and much more capable of catering for different sized content it’s not possible at the moment. For now we have to set the height to an actual value, to keep the height in line with any text resizing I set the height using em based value so if the user has larger text the height will adjust and won’t cut of any content. The height is 80px we divide by the base font size, which is 12, and we get 6.667em.

What about IE

Unfortunately IE doesn’t support the :target pseudo class and won’t work as describe above, but that didn’t stop me! Take a look at working example that functions in IE6 and up.

This is quite hacky and involves a bit of IE conditional comments.

IE xhtml

<dl>
	<!--[if IE]>
		<a href="#Section1" class="ie"><div>
	<![endif]-->
	<dt>
		<!--[if !IE]>-->
			<a href="#Section1">
				<!--<![endif]-->Section 1<!--[if !IE]>-->
			</a>
		<!--<![endif]-->
	</dt>
	<dd id="Section1">
		<p>
			Lorem ipsum dolor sit amet...
		</p>
	</dd>
	<!--[if IE]>
		</div></a>
	<![endif]-->
	...
</dl>

As you can see there is conditional comments so I can wrap the dt and dd tag in an anchor so we can get it functioning in IE using the following CSS. I also use the conditional comments to hide the anchor that appears in the dt tag only for IE browsers. IE6 was not functioning with just the anchor around the dd & dt so I added a div inside the anchor. In IE6 the first anchor would surround all the items, the div fixes that. Demo, demo files and example code has been updated to reflect that.

IE CSS

dl a.ie { text-decoration: none; }
	dl a.ie dd { display: none; }
 
/* Fix IE6 hover bug */
dl a.ie:hover { background-color: #606061 !important; }
 
dl a.ie dt
{
	color: #ffffff;
	font-weight: bold;
	text-decoration: none;
	padding: 10px;
	display: block;
}
 
dl a.ie:hover dd,
dl a.ie:active dd,
dl a.ie:focus dd
{
	height: auto;
	color: #cccccc !important;
	display: block;
}

Pretty simple stuff, set the text-decoration so the content isn’t underlined. We need to hide the dd tag as it causes issues in IE7 and below when trying to hover over any items below the first section. Next a background-color is applied to the :hover pseudo class of the surrounding anchor to fix an issue in IE6 that won’t trigger a hover unless something like a background-color is applied it. To make it work in IE we utilise the :hover, :focus and :active pseudo classes. That way when the user hovers in IE the content gets revealed, we also simulate a “click” by using the :active pseudo class. The :focus pseudo class allows us to make it work by using keyboard navigation, tabbing to the anchor will reveal the content. All the mark-up is XHTML 1.0 Strict complaint.

I think this is a pretty good attempt and best of all it works in all major browser so it can be potentially be used in a production environment.

writing-mode which is currently in the CSS3 draft specification allows us to accomplish text rotation without using propriety properties, effectively future proofing the concept as more browsers adopt the CSS3 draft spec.

The CSS

p { writing-mode: tb-rl; }

That’s it incredibly simple CSS technique that will eventually work with all browsers as their CSS3 support gets better. This is one of the handful of CSS3 supported properties in IE. The tb-rl value tells the browser to display paragraphs with the text flowing from top to bottom, right to left. Essentially rotating the text 90 degrees clockwise and aligning to the right.

This properties true intention is for displaying other languages in their correct “writing mode” such as Japanese right to left or Arabic & Hebrew which display right to left & top to bottom (rl-tb).

Support

At the moment IE is the only browser to support it starting from IE5.5 and up, IE8 adds further values through using the -ms extension. There are 4 values available from IE5.5+ and an additional 4 values for IE8+ through the -ms extension.

• lr-tb – This is the default value, left to right, top to bottom
• rl-tb – This flows the text from right to left, top to bottom
• tb-rl – Flows the text vertically from top to bottom, right to left
• bt-rl – bottom to top, right to left
• tb-lr – This and the followings value are only available in IE8+ using -ms-writing-mode. Text flows top to bottom, left to right
• bt-lr – Bottom to top, left to right
• lr-bt – Left to right, bottom to top
• rl-bt – Right to left, bottom to top

Rotate text in other browsers?

As stated in Snooks’ article we can do this in Webkit based browsers and Firefox 3.5+ using the transform property.

-webkit-transform: rotate(90deg); 
-moz-transform: rotate(90deg);

For both we need to use the vendor extensions -moz & -webkit. As for Opera it neither yet supports transforms or writing-mode properties but I’m sure that will change with the upcoming release of version 10.

In the article example we need to position the element differently for browsers that support the transform property compared to ones that support writing-mode as the elements rotated still exist as horizontal elements where as with writing-mode the element is truly rotated, see screenshot below.

Element that is rotated is outlined and highlighted, writing-mode on left transform on right

.datebox span:nth-child(3)
{
	right: 0px;
	top: 0px;
}

To target the browsers that potentially support the transform property we use the CSS3 nth-child() psuedo class.

A pretty cool alternative to an already great idea by snook.

Still using the CSS3 media queries we can accomplish orientation detection with only CSS but instead of looking at the unsupported orientation property we can use the min-width and max-width propertities to our advantage to detect what orientation the user is currently in. Load the below demo in your iPhone/iPod Touch to see it in action, rotating the phone will either change the text from “Portrait” to “Landscape” depending on your orientation respectively.

Looking in the Apple Developer documentation on Human Interface Guidelines (HIG) we can determine the min and max width we need to target to find out the user orientation. Let’s look at the CSS from the demo to better understand how it works.

h1
{
	display: table-cell;
	vertical-align: middle;
	text-align: center;
}
	h1 span { display: none; }
 
/* Portrait */
@media screen and (max-width: 320px)
{
	h1 span:nth-child(1) { display: inline; }
}
 
/* Landscape */
@media screen and (min-width: 321px)
{
	h1 span:nth-child(2) { display: inline; }
}

In the demo we have a <h1> set with to display: table-cell, this isn’t important to the demo but allows me to easily vertically centre the text. Inside the <h1> there are 2 spans which will show or hide depending on what orientation you’re in, initially we hide both spans.

The next few lines are where we can figure out using only CSS what span to show. To determine if the user is in portrait mode we use the media query @media screen and (max-width: 320px) we know from the HIG that 320px is the max-width in portrait mode. We do the same for landscape but this time we use min-width and increase the value by 1 so viewport needs to be at least 321px wide before any styles in the media query will be applied. Inside each media query I use the CSS3 nth-child pseudo class to target an individual span.

Not without issues

In order for this to work we need to add the viewport meta tag to force the iPhone Safari viewport width to be that of the device, it is usually defaulted to 980.

<meta name="viewport" content="width=device-width, minimum-scale=1.0, 
 maximum-scale=1.0">

My original idea was to use the max-device-width and min-device-width properties which would bypass the need for viewport meta tag but unfortunately this doesn’t work. It may be due to the fact that it will always return a min-width of 320 and a max-width of 480 and therefore wouldn’t be possible to do it the current way I have devised.

Until the iPhone adds in support for the orientation media query, this technique is quite a capable work around. Of course there are still some things it can’t do so the orientation event handler will still be needed for more advanced changes to happen.

Futurebox?

I’ve aptly called it Futurebox because this is only a proof of concept, it only works in the better browsers but never the less is a cool look at a useful CSS3 technique. The following browsers have been tested and will work with this example, it may also work in earlier versions of the browsers listed but I have not yet tested in them.

• Firefox 1.5+
• Safari 3.2+
• Chrome 2+
• Opera 9.5+

How does it work?

As mentioned above the whole thing is only possible due to the CSS3 :target pseudo class. It all works by getting the anchor link in a URI which can be referenced in your CSS using :target. If an element has an id that matches the URI the styles applied to it will come into effect. I’ll break down the above example so we can get a better look.

The xhtml

<a href="#futurebox_img1">
	<img 
		src="gr_ninja-attack_med.gif" 
		width="100" 
		height="102" 
		alt="The CSS Ninja" 
		id="futurebox01" 
	/>
</a>
 
<div class="overlay" id="futurebox_img1">
	<a href="#close" title="Close future box">
		<img 
			src="gr_cssninja_lrg.png" 
			alt="The Css Ninja" 
			width="600" 
			height="639" 
		/>
	</a>
</div>

Pretty simple mark-up we have our thumbnail image which links to an anchor link. The overlay image has the id that we are linking to on the thumbnail. The overlay mark-up has 2 divs around the image to horizontally and vertically centre the image. We have another anchor tag around the large image this is so we can “close” the overlay.

The CSS

html, body { height: 100%; }
 
.overlay
{
	width: 100%;
	height: 100%;
	position: absolute; 
	top: 0; 
	left: 0; 
	display: none; 
	z-index: 999;
	background: rgba(0,0,0,0.7);
}
	.overlay a
	{
		display: table-cell; 
		vertical-align: middle; 
		text-align: center;
	}
		.overlay_container img
		{
			background: #ffffff;
			padding: 10px;
			-webkit-border-radius: 10px;
			-moz-border-radius: 10px;
		}
 
.overlay:target { display: table; }

The overlay class is position: absolute so it can sit over the content, it is expanded to 100% width and height and has a background: rgba() applied so we get that nice transparent overlay look. Not all browsers support rgba that work with this example, for those no background colour will appear. Initially it is set to display: none.

overlay_container class The anchor tag has display: table-cell so it will act like a table cell, vertical-align: middle is applied give us the ability to vertically centre anything within this container and finally text-align: center so we can horizontally centre any inline elements. The entire screen is now clickable by styling the anchor this way making it more inline with how lightbox works.

The image has padding, background and for the supporting browsers we set rounded corners using border-radius. Since images are naturally inline elements, we can avoid setting margin: 0 auto and a width on the image to centre it (text-align: center on the previous container handles that for us) making this technique more flexible.

Finally the magic that allows this technique to work is very simple we target the overlay we want to display by using :target, the user clicks a thumbnail which has a link to #futurebox_img1 the :target pseudo class will look for any elements with the id of futurebox_img1 and set it to display: table, for a more in depth look at the css table property check out my previous article. We use table rather than block so the styles setup on the overlay_container class will allow us to horizontally & vertically centre the image.

Further reading

Think Vitamin has a good write up on the :target pseudo class – Stay on :target.

Arve Bersvendsen, an Opera developer, has a good proof of concept on his personal site to change the stacking order of draggable windows using :target.

CSS3.info has a good compatibility table showing browser support for CSS3 selectors.