CSS3

Keith Clark, an independent web developer from the UK, has developed a JavaScript solution to IE’s CSS3 shortcomings in relation to CSS3 selectors. CSS3 selectors became the first W3C module to reach proposed recommendation status back in December 2009.

His ie-css3.js project (currently in beta) allows Internet Explorer, versions 5 through 8, to identify CSS3 pseudo-class selectors and render any style rules defined with them. All this is achieved by simply including the script, along with Robert Nyman’s DomAssistant, within the head element of your web pages.

The annual W3C Technical Plenary / Advisory Committee (TPAC) meetings week took place last month bringing together the CSS Working Group, amongst others, for a series of face to face meetings in Santa Clara, California. Minutes from the meeting have now been made available online and promise progress for a number of CSS3 modules including CSS3 Selectors, Multicolumn Layout, Transitions, Transforms and Animations.

I’ve just put a pre-Alpha build of Firefox 3.1 through its paces, and can confirm (following David Baron’s announcement) that it gets a score of 578/578 in our CSS3 Selectors Test, which means not only support for the new selectors, but some bugs fixed in existing ones. To put that score in perspective, Firefox 3 scores only 357/578.

There is an almost perfect score on Daniel Glazman’s Selectors Test too, with only one discrepancy showing up.

So Safari, Opera and now Firefox all pass the test; of the major browsers, that only leaves one Inevitable Exception…

Those brave enough to try pre-Alpha can download builds from Mozilla’s FTP server. The usual warnings and disclaimers apply!

Apple surprised a lot of people by releasing Safari 3.1 today (myself included!), and amongst its list of new & improved features (audio and video tags! SVG in img and background-image!) are two which will be of interest to readers of this blog: full CSS3 selectors support, and web fonts.

The first means that Safari now supports the missing nth-child / nth-of-type selectors, which are useful for styling tables and lists (amongst others), and also now passes our Selectors Test (which, while by no means exhaustive, is very useful). Opera 9.5 will also support these selectors; Firefox 3 probably won’t, IE8 is unknown.

The second is the more exciting to me, and I’ve already written a quick introduction (with example) on my own blog. In a nutshell, you can now embed fonts in your pages to display even to users who don’t have that font installed. There’s a longer article with more examples on A List Apart.

We’d known most of this was being implemented by Webkit/Safari, but had no idea it would be coming so soon. Congratulations to the whole team, and here’s hoping it serves as an example to the other browser makers.

Daniel Glazman has created a new test to show CSS3 Selectors support in your browser. He has also posted results for current browsers.

With this and the Acid 3 test, there’s a lot for browser makers to aim for.

As this is my first post, I’d like to introduce myself. My names James and I’m currently working as a senior User Interface Developer for Teachers TV. Like many of you guys, I’m fanatical about web standards and about creating the leanest, most semantic markup possible. I too am excited about the new possibilities with the arrival of CSS3, and am keen to contribute as much as I can to this great site. My first post is regarding a new method of creating Tooltips that I devised while coming up with a solution for a recent project.

Up until now, there were a few options in existence; ugly Javascript-based methods, or solutions that use blank anchor tags (for IE6 compatibility). Another possibility is to ignore IE6 altogether and make use of the hover pseudo class in conjunction with the parent element that contains the tooltip text. I had to think out the box a bit on this one, but have come up with a completely new CSS3-based solution.

My solution degrades gracefully in browsers that don’t support the CSS3 elements I’ve used and is a lot more elegant than former methods since it utilises an element’s title attribute, rather than creating additional markup within a parent element.

Let’s start with the HTML (Note: the following example is based on use of icon background images for the divs, hence the fixed dimensions):-

<div title="Tooltip text for first div"></div>

<div title="Tooltip text for second div"></div>

In short, my method is achieved by making use of the :before (or :after) pseudo element and content property, combined with the :hover pseudo class.

First off I grab the value of the divs title attribute by using the content property’s attribute function. Notice how I set the generated content to display:none -I’ll make it visible on :hover.

div:before{
	content:attr(title);
	display:none;
}

I now combine both the :hover class and :before pseudo element together, to specify values for the generated content when the div is hovered over.

div:hover::before{
	width:200px;
	display:block;
	background:yellow;
	border:1px solid black;
	padding:8px;
	margin:25px 0 0 10px;
}

One of the problems I came across at this stage, was that when having two elements floated left to each other and you hover over one of the elements, although the tooltip displays, it renders underneath the adjacent element. It is a simple case of layering the generated content over the div; my immediate thought was to specify a layering value in the above statement. However, after referring to the relevant W3C spec, it was apparent that in line with their recommendations, user agents ignore the position property in an instance such as the above statement, therefore rendering a z-index value useless.

The solution was to specify the z-index and position properties in a separate statement dealing exclusively with the :hover pseudo class.

div:hover{
	z-index:10;
	position:relative;
}

This meant that it now works! It of course works in every browser above IE7 including Safari 3, Firefox 2.0.0.12 & Opera 9.5b

Obviously there’s nothing you can do to stop the default behaviour of standards compliant browsers regarding rendering of title attributes, so when leaving your cursor on my method for too long, the default browser behaviour will overlay the generated content CSS effect

Live example of the final product

Mozilla’s John Resig has removed support for certain CSS3 selectors from the jQuery Javascript library, and says the fact that no-one has asked for them to be reintroduced is evidence that they aren’t very useful:

Now, I’m sure I’ll probably get lots of feedback saying “but ‘E + F’ can be useful, look at this example” or “of course ~= is useful, you can use it on rel attributes” – that’s not the point. The fact is that they are woefully un-used. To the point that they are a burden upon the implementors of the specification. What’s the point of implementing the above features – or more importantly: optimizing the above features for speed – if no one is using them.

Daniel Glazman, who authored the original spec, says that John is looking at them from a purely HTML-centric viewpoint, that lack of support means that people haven’t really thought of using them yet, and that just because the majority don’t have a use for them, doesn’t mean that they are useless;

So we have here selectors that are not implemented yet or not interoperably and Web designers don’t use them. How surprising!!! In CSS, we have some features here to serve some typographic local constraints, because we saw a menu in a restaurant nicely designed and we needed a new feature to be able to make it in CSS. Serves a very little community of users. That community will NEVER show up in any stat. Is that a reason to drop the feature? You don’t see a wide community of users for a given selector? Is that a reason to drop it? CERTAINLY NOT.

I’m with Daniel on this one; the key point for me is that the support for them at the moment is so limited that we haven’t yet seen what the talented development community can do with them. I’m sure I, as a front-end HTML developer, won’t use them as frequently as the existing selectors, but I already use some of them infrequently and look forward to using them more.

One of the selectors new to CSS3 is the :target pseudo-class, which can be used to apply rules to an element with a fragment identifier; that is, an anchor name or an id. For example, let’s assume you have a section heading with an id of ‘chapter_2’:

<h3 id="chapter_2">The Title of the Chapter</h3>

You could create a direct link to that element by using the fragment identifier at the end of the URL:

http://www.example.com/index.html#chapter_2

And, with the :target selector, apply a background to that element to indicate clearly where you have arrived:

h3:target { background-color: #ff0; }

Pretty useful, right? Not a killer feature, but useful nonetheless. It can be made even more useful, however, with a little bit of ingenuity; how about, for example, a pure CSS image gallery?

Take a look at this example (in a browser which supports :target; Mozilla, Webkit or Opera browsers will do the trick). Clicking the links allows you to browse through the different images, and it’s done with minimal markup and no scripting.

The first step is to create a list, with the image, name, and link in each list item; for example:

<li id="one">
	<p><a href="#one">One</a></p>
	<img src="https://www.css3.info/wp-content/uploads/2009/09/one.jpg">
</li>

Each list item needs an id, which will provide the anchor, and the link href is to its own id; this allows :target to work its magic! All the images are absolutely positioned on top of each other, and using the selector simply changes the z-index value so the targeted image is on top:

img { position: absolute; }

li:target img { z-index: 100; }

Easy! Of course, this is only a very simple example; with even more ingenuity, this could be expanded to become a very useful tool.

Update: I’ve just seen that Daniel Glazman came up with a very similar proposition before I did: CSS-only tabs.