A mock-up interface using CSS3 Colour
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.
Looks nice on FF2; my only observations are that the 2nd-level ULs only take on the width of the parent LI, and there is a slight gap at the top of the 2nd-level ULs so the menus sometimes disappear if you don’t move your mouse down fast enough.
FF2 doesn’t show the transparency so kind of defeats the point ;) (I use regular none HSL and RGB as a fallback colour). The menu width seems to be a FF bug as it works correctly (or how I intended at least) in Opera and Safari. It did work correctly in FF bug I changed the style to fix other issues and it seems to have hit a bug. I’ll see if I can make changes to fix it.
The gap seems to be because of using em’s and having browser differences. There is no gap in Opera or Safari. I should really have used px when needing precision.
Setting the background to 100% causes unnatural stretching on widescreen monitors.
“no matter how big or small the browser window is, all the background image is shown”
In Safari 3 Windows (haven’t tested Mac as I don’t have access to it), the background will stretch to fill a larger screen, but it won’t squeeze to fit a smaller screen; it’s cropping it instead, so the whole image isn’t displayed. I’m not sure if this is correct behavior or if Webkit is not acting as it should.
You’re right. I didn’t have a widescreen to test on until I got home, so didn’t notice it that pronounced. I’ve corrected it by adding auto after the 100% (horizontal value). When a value is set to auto it keeps the aspect ratio. It seems to be a WebKit bug that it doesn’t scale smaller. The spec doesn’t say anything about only making the image bigger. Mind you it doesn’t say the user agent needs to make it smaller either. WebKit now has problems making an element smaller when it has resize set, so I wouldn’t be surprised if the issue was something similar.
It doesn’t show the transparency on the menu bar at the top because it uses HSLA, but it does show the transparency on the sub-menu because it uses opacity.
Nice mash-up of some CSS3 features! By the way, the
resizeproperty doesn’t work as you might expect…You could have used the HR element for menu separators if you wheren’t looking to demonstrate CSS3 properties.
Slightly off topic:
Has anyone figured out how to install Safari 3 Beta on Mac while at the same time keeping the old v2? I heard that the Mac version was more stable that the PC, but I don’t want to get rid of the old version as I’d like to test my sites against it.
I could have used hr, although I read somewhere that they were being depreciated. i feel they are quite presentational as you don’t always want to group by a horizontal line. There really should be a list group, similar to option groups in the option element and fieldset in forms. Ideally there should really be a menu list. HTML has the nav element, but it seems to be used instead of having a generic div element with a class of nav. I suppose multiple lists could be included inside the nav element to denote grouping.
Saf2/3: Not that I know, but you can just download the latest nightly build of WebKit. It should keep Safari 2 and it will be similar enough to Safari 3. I don’t see a huge difference between the two as Safari 3 wasn’t released that long ago.
Yes, I haven’t used HR myself for many years as I’ve not seen the need for it.
However, for just this purpose of building an application interface, spesificly a menu which often contains separators, I think the HR element is an appropriate one.
.sub-menu {top: 100%}
should fixes the gap in the menu on Firefox and I believe you should get the same result in all browsers that way.
To fix the menu width
add
.menu a {white-space: nowrap}
remove
.sub-menu {overflow: hidden}
change
.sub-menu li {width: 16em}
into
.sub-menu li {width: 100%}
I have only tested this on Firefox, so I’m not sure wheter this may cause trouble in other browsers.
The sub-menus work fine with your fixes, Nox, thanks.
BTW, for anyone who can’t see the example, here are screenshots from Firefox 2, Firefox 3 and Safari 3.
1. ref the ‘cropped’ submenu in Firefox/Minefield.
Those actually do what you want them to do :-)
the .submenu is child of a floated li (shrinkwrap !), submenu takes the width of that floated li. then you set the overflow to hidden, it crops the .submenu li to the width of the floated parent li. remove the overflow and it displays as expected.
2. Performance on Minefield Mac: known issue, due to the large background image. That problem should be fixed soonish when Cairo gets an upgrade.
3. Some baffling bug I see on the latest Minefield Mac builds: the submenus have a huge amount of white-space under each list-item. Checking with the DomInspector, it appears that Minefield insert a [br] after the link. I have currently no idea where that one comes from (obviously not in the source code), and when attempting to build a minimised testcase, all works correctly. Go figure…
Nox/Philippe: Thanks. I’ve fixed both issues. The overflow was actually there as I originally styled the li elements instead of the a element, so the overflow was needed to stop the hi-light spilling out the container. When I changed the menu, I forgot to remove the overflow as it didn’t make a difference in either Opera or Safari. I’m not sure which browsers are correct, but it works in all three browsers without the overflow.
[...] A mock-up interface using CSS3 Colour [...]
HR has been restored in HTML5 and its definition tweaked to refer to semantics rather than presentation. (The presentational attributes are of course all gone.) See
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-prose.html#the-hr
Menu separators imo do belong in the markup. They’re not there to make the menu pretty, they’re there to show its structure.
> Support for SVG colour keywords has also existed for a long time, just without being accepted by the validator.
Actually, they are accepted by the W3C validator; you need to change it to CSS3 mode.
Couldn’t the separators be handled by inserting another level of list into it, so that each subsection of the open menu would be an LI, with each but the last-child styled to have a border-bottom, along with eqyal amounts of margin-bottom and padding-bottom?
Oh, and by the way, I don’t actually see any menu separators. I’m using a recent nightly build of WebKit and the Safari 3.03 beta, but I don’t see them in FireFox 2 either. Am I missing something?
The separator goes under “Web Standards Group” in the “Go” menu, if I’ve read it correctly.
You can make it work pretty easily in Firefox and other browsers who support the + selector, though it’s ugly.
.menu li + li + li + li + li .sub-menu li + li + li + li {
border-bottom: 1px solid silver;
padding-bottom: 0.3em;
margin-bottom: 0.3em;
}
.menu li + li + li + li + li .sub-menu li + li + li + li + li {
border-bottom: 0 none;
padding-bottom: 0;
margin-bottom: 0;
}
[...] A mock-up interface using CSS3 Colour - CSS3 [...]