CSS3

We’re busy here at css3.info! Our interview with H&kon was cool of course, but then Opera 9.5 was released and we had to update and add quite a few pages… Because all these pages were still static html, that was quite a bit of work. Tonight I took the time to move all of them into WordPress, and after I’d done that, I’ve refined the search function and results a bit, so it now shows the pages in the searches as well!

We’ll probably be adding new preview pages in the coming days, I’ve already updated the existing ones which Opera 9.5 supports now (cool, cool stuff, you should really have a look at it).

Ow and because of the many complaints about it, I removed the text-shadow from the text in the menu tabs.

Here’s the concluding part of our interview with Håkon (you can read the first part here).

6. Name the top five CSS3 features you’d like all major browsers to support in their next major release.

   Here’s some of my favorites:

   • Backgrounds and borders
   • Media queries
   • Multi-column layout
   • Selectors
   • Paged media

   Also, we must not forget Generated content, and tables from CSS2.1. These are great features that still can’t be used due to lack of support from one browser.

7. Do you think there should be a Acid3 that focuses on CSS3 features that designs want supported as soon as possible?

   Yes, I think it’s time for another Acid test — all major browsers but one (guess which one!) support Acid2 by now. I believe Acid3 should test CSS3 features that a critical mass of browsers can agree to implement. Also, it should probably test features from the upcoming HTML5 and the DOM.

8. Do you have a favourite designer who you admire their work, either from a design or technical respect?

   I can’t give you one name. I often show designs from the CSS Zen garden when I give talks; I like many of them.

   I can name two favorite fonts designers, though: Ray Larabie and Dieter Steffmann.

9. How do you think designers can get more involved with the CSS3 progress, to make sure features designed by designers themselves are added to the spec, instead of the features the spec writers might think are important? Is there a way this can be done without designers (many who don’t have much free time to spare) having to read through long mailing list histories and understanding a lot of very technical implementation details (I’m thinking such as having a appointed advisory board of designers for example that advise what features they want, and gather feedback from others, then the implementers can discuss this and come back with issues or start to draft specs for those features)?

   We’ve always encouraged designers to be part of the CSS Working Group, and there has always been strong designer presence in www-style. Many of the choices we’ve made along the way are based on input from designers. For example, you wouldn’t find Backgrounds and borders on top of my list if it hadn’t been for designers. The idea of an advisory board may be a good one.

10. How do you feel about being nicknamed “the father of css”?

    I often refer to CSS as my baby, and I’m fine with being called the father :-) It must be emphasized, though, that the child was shaped by a community. Bert Bos was the first to join the efforts, he came with a proposal of his own that we worked into CSS. Thomas Reardon and Chris Wilson of Microsoft were also influential in the time before the CSS WG and and the www-style mailing list was started.

11. What do you think of the Brazilian band CSS?

    Wow. Right. Change of mindset. Music, right? When it comes to music, I prefer Opera!

We’ve had some great interviews with luminaries of CSS-based design here on CSS3.info already, but this one is my personal favourite! Håkon Wium Lie, ‘the father of CSS’*, spared us some time to answer a few questions about the evolution of web design and the future of CSS. I’m so excited by this, I’ve almost forgiven our friends at Opera for not letting us have an early preview of Opera 9.5!

1. Is the use of web fonts the next big step in web design?

   Yes! Web fonts will be the next big thing if browsers start supporting them. Fonts are one of the core ingredients of design, along with space and colors. CSS is pretty good with space, colors, and fonts, but in the case of fonts the raw materials — the font files — are in short supply. Interestingly, there are lots of freely available TrueType font that authors allow us to use for free. So, I’m trying to connect the dots between web pages and the available fonts. I’ve written more about this in an article in Alistapart and you can play with web fonts in Prince.

2. With the current battles over copyright infringement with music and video on the web, can you imagine something similar occurring over the misuse of rights-protected fonts?

   Almost all the content on the web is copyrighted. It’s still available because copyright holders want it to be available. Sure, there are cases when the copyright holder has not given permission. But I don’t think anyone would argue that we should remove all images, video or music from the web for this reason? There are plenty of freely available fonts out there and no need to use fonts with resistant owners. Also, plenty of new font will be created open-source style if browsers start supporting web fonts.

3. Has web design turned out more or less the way you imagined when you wrote the CSS spec so many years ago?

   CSS was partly about design, and partly about markup. We — Bert Bos and I in the beginning, soon others — wanted to improve web design, but also to keep markup clean. I think the first part has succeeded quite well; I continue to be amazed by the things people are able to do with CSS. I’m less certain about the markup. But you didn’t ask me about markup, so I don’t have to answer for it :-)

4. Outside of web fonts, which part of css needs most work in your opinion? And why?

   Lots of work has gone into the CSS specifications. That will continue, but it’s not where work is most needed. What we need now are implementations — interoperable implementations. In order to get them, we need tests and testers. Lots of them. People who are interested in this subject should join the CSS testsuite mailing list.

5. If you could start all over again, what would you do differently in CSS?

   I’ve written a long PhD thesis, in part on that subject. That’s the long answer. The short answer is that we should have published a test suite earlier. We worked hard to get the CSS1 specification right, but implementors don’t really like to read specifications. They will work long hours, however, for so that their code passes a well-designed test. Eric Meyer came to our rescue and made sure CSS1 got a the test suite.

Part two of this interview, where Håkon discusses CSS3 and web design, will be available shortly.

* Maybe we should have asked him what he thinks of that nickname!

Since the move away from tables to CSS-based layouts, lists have become more important in producing semantic markup; in Andy Clarke’s Transcending CSS, he seems at times to be on the verge of saying all content can be marked up with lists!

Yet the basic list itself is let down by the range of markers available; for unordered lists you have disc, circle or square, or images which are implemented so differently across browsers that it’s better not to use them. Perhaps most annoying of all, you can’t have the glyph be a different colour from the content without extra markup:

<li><span>Lorem ipsum</span></li>

That could be set to change with the proposed new lists module which allows a much wider range of glyphs, markers and counters and, more notably, the ability to style them with the ::marker pseudo-element. In a nutshell, this allows you to treat the list-style-type as a separate entity and style it accordingly.

The working draft doesn’t specify exactly what declarations you’ll be able to apply, although it does mention borders, margin, and padding so it’s not a great stretch to imagine that you could add colour and font styles to that also – meaning lists could be set to become a lot more decorative:

li::marker {
background-color: #fff;
border: 2px dotted #f00;
color: #f00;
font-size: 2em;
height: 4em;
text-align: center;
width: 4em;
}

Do I have to include the usual disclaimer? This is still only a working draft of a proposal (and a low priority one at that), and browser support currently stands at nil.

I was reading Veerle’s blog today; the excellent article A CSS styled table version 2, to be precise. All good, practical stuff, and well-presented as usual. But what stood out for me was the technique to stripe the table rows: either through classes, or Javascript.

Of course, both of those are valid techniques; but really, neither should be. It’s pretty easy to forget, when we see how far CSS-based design has come in the last few years, just how reliant on workarounds and tricks we are in order to perform what should be basic functions.

Presented below are some of those workarounds that I’d love to see consigned to the dustbin of history; not because they are bad – on the contrary, they are extremely inventive – but because CSS 3 should allow the effects to be replicated without the extra mark-up, script or code.

Tiger-striping on table rows

Whether done with background images, DOM scripting or just adding classes to the markup, none of the techniques are as easy as using the nth-child pseudo-class:

tr:nth-child(odd) { color: blue; }

‘Sliding Doors’

Requires no extra mark-up but a lot of CSS jiggery-pokery, most of which could be avoided with multiple background images:

li {
background: url('image0.png') no-repeat left top,
 url('image1.png') no-repeat right top;
}

Rounded corners

Which do you prefer: multiple lines of Javascript? Or a single line of CSS?

div { border-radius: 1.5em; }

Drop shadows

Even the simplest solutions seem to rely on an extra image and plenty of CSS tweaks. CSS 3 resolves it with one declaration:

img { box-shadow: 10px 10px 5px; }

Of course, the problem is that perennial one: lack of support. No modern browser currently supports all of the examples shown above, and it will be many years before we can stop using the workarounds altogether. But I do look forward to the time when they become a secondary consideration – and to what extensive use of the new declarations reveals in terms of creating new workarounds to future problems.

The CSS Advanced Layout module (explanation here) has been updated. After a quick read through, I’ve found only a few changes.

The first is the introduction of the ::slot() pseudo element, which allows (limited) styling of – obviously – a slot. That is, if you had your layout set up like this:

body { display: "ab" "cc"; }
div#div1 { position: a }
div#div2 { position: b }
div#div3 { position: c }

You could style #div2 either with its id, or with:

body::slot(b) {}

This pseudo-element is still at an early stage of definition, and may be changed – or dropped altogether.

Another, more minor change is that the way to define templates, which was previously undecided between display-model or display, seems to have been decided in the favour of the latter. I’d agree with this, as it uses an existing declaration.

Something else I noticed, which is not a change as it was in the original draft, I just overlooked it, is that vertical-align can now be used to position a block-level element inside a slot; that’s right, like inside a table. Rejoice! No more workarounds!

The Advanced Layout module has been described by the W3C as a concept album – that is, an explorative spec; therefore, don’t expect to be seeing it implemented any time soon. You can, however, download a cross-platform Javascript emulator, written by César Acebal, if you want to try it out for yourself.

Struggling with the boxmodel sometimes? Need some help to figure out what the size of the element that’s troubling you really is?

John Allsopp has created the perfect solution to this problem. It’s a bookmarklet called XRAY, And you’ll love it. Click on it once to activate it, and click a second time on any element to display it’s box model!

What’s cool about it too is that it uses some CSS3 as well, including box-shadow, border-radius (webkit only), opacity and rgba!

So go check out XRAY!

You’ve probably seen the ad for them on the right hand side by now if you’ve visited this site before, but we thought it would be good to introduce them in a post as well: a warm welcome to FreshBooks!

FreshBooks let’s you send out invoices through a great online interface, has a nice API, automatically accept all sorts of payments, etc. etc. etc.! I seriously suggest checking out their tools if you do a lot of invoicing, especially as they are NOT expensive.

When you’re at it, check out the great design of their site… It’s one of the best looking commercial sites I’ve seen in a while.

I recently posted a preview of the CSS3 colour module on my own blog, but avoided using any actual examples. This was because of the things that have been implemented, the true power isn’t really seen using a simple example. With opacity and the HSLA/RGBA colour models, any elements that have been coloured just look like they fade to a lighter tint if there is only a white background behind it. Support for SVG colour keywords has also existed for a long time, just without being accepted by the validator.

To show the true flexibility of CSS3 colour, I had to build a more complex example with overlapping elements. I also added a number of other CSS3 properties to show case them while I was at it (Why not?). Due to using a lot of transparency, there are a number of issues with Minefield, where it crawls to a hault then eventually stops responding. This may only be a issue with the Mac build or my hardware, so your mileage may vary. There shouldn’t be any issues with using webKit, except for a number of bugs that I seem to have uncovered. Most of these were hi-lighted in my previous post.

Without further ado, here is the example for you to try out (warning large background image). It is based on a loose mock-up of a Mac OS X Leopard style interface. I needed a background image, so took a wallpaper from Michael Palin’s great Sahara series. The photo is copyright Basil Pao and is of a mother and her child in Tabelot, Niger.

Because the example was designed to showcase the various colour values, I’ve mixed between using opacity, HSL, HSLA, RGB, RGBA (both hex and percentage) and keywords. In a real production site I’d have avoided this and stuck with the same colour models where appropriate. I tend to use keywords myself as they are easier (for me) to remember. HSL (and by extension HSLA) would be very useful when greater control over the colour is needed, but at the current moment it isn’t supported enough to be used. The correct RGB value would have to be used anyway to act as a fallback colour.

The example showcases the difference between HSLA/RGBA and opacity. If you hover over the File or Go menus, I’ve added a sub menu that has opacity applied too it. When hovering over a menu item that is displayed over the white title bar behind it, you’ll notice the text is more white than the text with the mud background behind. This is because opacity is set on the foreground and well as the background. for elements that have been styled using HSLA or RGBA on the background colour, such as the faux-window title bars, contents area and menu bar, retain fully opaque text. While the difference isn’t too great with this example, there can be cases where the difference is quite obvious. It also allows things like just the shadows to have transparency.

I’ve included quite a lot of other CSS3 into the mix. There is liberal use of box-shadow to give the allusion of depth on the windows and title bar. Rounded corners have been added to windows. There is an issue with rounded corners, where if overflow is set (which adds scroll bars) then the corner with the scroll bar ignores the radius (or is displayed behind it). I moved the overflow to a div inside the faux-windows to avoid this problem. I’m not sure how browsers can be fixed to avoid this problem without the spec changing to accommodate things like scroll bars. resize was added to both faux-windows, but there is issues with each element inside the window being resizable independently in Safari, and not being able to resize it smaller (the later wasn’t an issue in earlier builds).

One of the big compatibility issues with current browser support is the difference between overflow using multi column layout. In Safari it doesn’t respect the setting of having two columns, by adding extra columns to the right of the visible columns. This seems smart at first as it avoids the issue of having to scroll to the bottom of the first column and back up to the start of the next column, however it is generally harder to scroll horizontally than vertically. You can also imagine if a height was set and overflow wasn’t used then it could push any content to the right of the columns out of view, such as a right hand side bar. Minefield just uses the two specified columns and makes the content as long as needed. This has issues as you get the scrolling problem mentioned previously. This will be a usability annoyance. My only suggestion is that a column height can be set, and when all available space is taken up without scrolling, a column break is inserted and columns of the same width and height are repeated below until the content runs out. There would have to be some way to specify the vertical column gap though. This would solve the readability issue, a one block of columns could be read at one time, and it will stop and important right sided content (or left in rtl layouts) from being pushed off the screen.

The next CSS3 used was background-size. This was set at 100% so that no matter how big or small the browser window is, all the background image is shown (overflow:hidden; had to be added as the very latest versions of WebKit add scroll bars, unlike previous versions). This currently only works in WebKit. While most of this works fine in WebKit (if you ignore the bugs), one thing that only works in Opera and KHTML is the menu separators. Instead of adding mark-up such as a br I used the nth-child selector to select the exact element where the separator should go, and added the appropriate margin, border and padding. Without there being an element to group related list items, I though this was the best way to go about it, plus it was another excuse to show off more CSS3. Finally I used a attribute selector to grey out the print menu option (or any option in the menu with a URL of #). This is a bit of a hack to demonstrate the technique, but you can see how it could be useful in the real world.

The great power I see coming with CSS3 is that this example looks fairly complex and flashy, yet only uses one image (the background image), and the mark-up is very brief. I could have used even less mark-up and ID/Class attributes, but they were added for semantic meaning. The problem is more that the browser has to do much more processing to work out things like the transparencies so there can be performance issues, especially on older hardware. One can expect that performance will be tuned as support for the new properties are included in final releases.

I haven’t seen any official announcement yet, but it seems that KHTML and WebKit are to unfork. According to the linked article – which also provides an interesting history of the two engines – there is a bit of work to be done, such as importing KHTMLs advanced CSS 3 features, before the unforking happens, but it should mean that WebKit gains a lot more active developers, which can only be good news.