CSS3 transform enables the rotation of elements including HTML text. If you intend to use it you should be aware that Firefox 3.6.8 and below has very poor baseline alignment.
The heading is just about acceptable. Content text is not.
Firefox 3.6.8:
Webkit:
So be warned if you intend to use CSS transform on text.
CSS3 brings us a host of new features. Whilst most people will be familiar with gradients, text-shadow etc. I’d like to draw your attention to one of the lesser known modules in CSS3: flexbox. What’s interesting about Flexbox is that you can use it now if you use a Gecko or Webkit based browser (no IE sadly and Opera’s support isn’t there yet).
What does Flexbox bring us that we didn’t have before? Well it gives us a whole raft of new ways of controlling layout and flow. What we now achieve with floats we can do far more successfully and with more control with Flexbox.
I’ve never liked floats, they always seemed a hacky way of structuring HTML. Unfortunately with the meager positional CSS available, floats ended up being the best way of creating flexible fluid layouts. Let’s look at some examples.
To define an element as a flexbox we set the display to box.
.flexbox {
display: -moz-box;
display: -webkit-box;
display: box;
}
Notice that by default flexbox elements are aligned horizontally. If we want to change that to vertical:
.rule {
-moz-box-orient: vertical;
-webkit-box-orient: vertical;
box-orient: vertical;
}
Box-orient is inherited i.e. child elements will also be aligned horizontally.
Observant viewer will have noticed that Firefox (3.6.8) ignores the width and height setting on the child boxes, whilst Webkit respects it but overflows the content.
So if you want child elements to be aligned vertically, you’ll need to set the containing element to box-orient:vertical.
We can reorder elements as we like, using box-ordinal-group.
#box-2 {
-moz-box-ordinal-group: 1;
-webkit-box-ordinal-group: 1;
box-ordinal-group: 1;
}
The immediate application of this should be obvious, for the first time we have way of defining display order without reverting to all the hacks we’ve had to use up to now (floats, relative positioning, negative margins etc). Powerful stuff.
Box-flex allow the content to expand to fill the available space.
.rule {
-moz-box-flex: 1;
-webkit-box-flex: 1;
box-flex: 1;
}
Notice once again the difference between Webkit and Gecko; whilst Webkit expands the main block to the browser window, Gecko expands to fit the content.
Box-flex fills space in proportion to the value given. Quoting the specs:
“All flex is relative. For example, a child with a box-flex of 2 is twice as flexible as a child with a box-flex of 1.”
To explain this better lets look at an example:
#box-1 {
box-flex: 1;
}
#box-2 {
box-flex: 2;
}
#box-3 {
box-flex: 7;
}
For ease of calculation I’ve given the H1 child element a width of 50px, and the containing element a width of 600px. So the available space is:
600px – 150px = 450px
Working out the ratio is:
1 + 2 + 7 = 10
450px / 10 = 45px
this produces:
box 1 width: 50px + (45px * 1) = 95px
box 2 width: 50px + (45px * 2) = 120px
box 3 width: 50px + (45px * 7 ) = 365px
Further more you can set relative spacing whilst having fixed width paddings and margins. If you tried that with floats you’d either have to use percentage margins or have boxes bouncing all over the place.
Box-align works in the opposite direction to the orient setting. i.e. if the element is set to horizontal, box-align controls alignment in the vertical and vica versa.
#main {
-moz-box-align: stretch;
-webkit-box-align: stretch;
box-align: stretch;
}
#box-1 {
-moz-box-align: start;
-webkit-box-align: start;
box-align: start;
}
#box-2 {
-moz-box-align: center;
-webkit-box-align: center;
box-align: center;
}
#box-3 {
-moz-box-align: end;
-webkit-box-align: end;
box-align: end;
}
This reverses the order of elements.
#main {
-moz-box-direction: reverse;
-webkit-box-direction: reverse;
box-direction: reverse;
}
Notice the inconsistency between Gecko and Webkit again. Gecko aligns the right hand column, whilst Webkit aligns to left but reorders the elements.
Box-pack controls alignment in the direction set by orient.
#main {
-moz-box-pack: justify;
-webkit-box-pack: justify;
box-pack: justify;
}
#box-1 {
-moz-box-pack: center;
-webkit-box-pack: center;
box-pack: center;
}
#box-2 {
-moz-box-pack: start;
-webkit-box-pack: start;
box-pack: start;
}
#box-3 {
-moz-box-pack: end;
-webkit-box-pack: end;
box-pack: end;
}
Justify is a nice attribute, equally spacing elements within the parent container.
The classic 3 column layout. Notice the navigation appearing first, also note that the background colour extends to the full height of all boxes.
Sadly flexbox is not supported by IE and looks unlikely to be supported by IE9. So it will be a while before these techniques become mainstream.
A recent project reminded me how much I like the “just enough documentation” approach, and how inefficiently web design is often done.
Tasked with redesigning an Agile project management web application (to improve usability but not re-brand), I used the following process:
1. Paper sketching for a day or so to get my ideas straight about page and widget layout. This is the best time to explore wildly different alternatives, and make most of the big decisions.
2. Wireframes in Omnigraffle of the key pages. Since the visual style wasn’t changing, I could do high-fidelity wireframes closely resembling the final design. I work on a large format, so there’s ample space to overlay notes and state changes, as well as alternative ideas. The wireframes were shared with the client on a continuous basis for feedback.
Lots of things weren’t wireframed, including less critical pages, and many dynamic states.
3. I did only two pages in Photoshop, in which I did just enough to give me my final measurements, and the few image elements that needed cutting out. I refined designs a little from the wireframes, but most of this I left to the next stage. The wireframes and this stage together took about 5 days.
4. HTML and CSS. Because in my design I was switching from a fixed-width layout to a liquid layout, you can only really appraise the design once you implement it, so it was imperative to get to this stage as quickly as possible. It is also far, far more efficient to fine-tune margins, typography and colours in CSS than in Photoshop. Furthermore, I could quickly mock up most dynamic interactions – of which this app has plenty – in jQuery (which I had not used before but was ridiculously easy to pick up.) How much more effective than doing so in wireframes, where you (and the client) have to imagine how it will “feel” to the user and you can never be sure whether it will work?
By far the bulk of my time – about 2 weeks – was spent working in HTML and CSS. Pages or elements that weren’t wireframed were much quicker to design directly as HTML and CSS, without the duplication of effort. New ideas inevitably arise during this stage, and are immediately incorporated. I occasionally went back to paper or Photoshop or Omnigraffle to work out small details, but there was no need to keep those design documents “up to date” – they had served their purpose. The client was able to appraise the designs exactly as it renders in the browser, and the resulting artifact was also ready to be integrated into their back-end.
Not only could the client and I be confident about how the design will actually look once implemented, I could also ensure that accessibility measures were built in, as well as the ability for it to be easily re-skinned. (As the app is sometimes white-labelled.)
Conclusion
If I reflect on the design process on many past projects, most seem ridiculously inefficient. Where UX designers had to exhaustively wireframe every single page and every possible interaction, with complex state diagrams for all the dynamic elements. And to keep the wireframes up to date throughout the course of the project. Where designers had to mock up dozens of pages in Photoshop, with everything finalised to the last pixel (but usually omitting hover effects and never considering liquid layout or browser differences). All the foregoing needing to be done before a client will sign it off and a single line of markup can be written. The front-end developer reduced to an automaton incapable of taste or decisions, who just had to implement the Photoshop mockups to the pixel, and all interactions exactly as specified in the wireframes. It was usually impossible to refine aspects of design or interaction at this stage (everything having been signed off), let alone adding new ideas, despite it being the most fluid.
Obviously this won’t suit all projects or clients. For example, I had the advantage of not starting from scratch, and a client who was prepared to work in this way. It was a relatively small project with few stakeholders. On some projects there may be good reasons for an exhaustively documented waterfall process. But very often in my experience it was simply because it was the only way the agency knew how to work, due to the excessive compartmentalisation of skills, and an inadequate understanding of the meaning of web design. And my, what a lot of time and money it wastes.
Recently I’ve been tasked with looking at how we can improve our Plone theming process.
One of the problems that most teams come across on any web project is how to spend less time doing the basics and more time solving the unique problems that each project throws up. This seems to be especially true when it comes to skinning / implementing user interfaces. No matter what framework / CMS I’ve used (and I’ve used plenty) it’s often hard to square the circle between what we want as output and what is actually produced.
Another aspect that can eat up time is having to implement user interface changes during development. Even with the best sign-off procedures, designs, and by extension HTML templates are often subject to change. With that in mind the key objectives we are looking for in a theming method are:
So lets look at the various theming options for Plone.
You’re not wrong. From what I can see you have 2 options:
I could probably grab some developer time here at Isotoma to help me put together this ‘vanillla’ product, but even that doesn’t answer our needs in the level of flexibility we require. There must be an easier way….
The future of Plone theming lies in Deliverance / Collective.xdv and will be at the core of Plone 4 theming (so I’m told). You can start using it now though. (see this excellent tutorial to get started )
It took a little effort to get a working buildout, mainly because I couldn’t get lxml working on my mac (necessary for collective.xdv). So I installed it on an Ubuntu VM which worked just fine.
Once I’d got it working it didn’t take me long to realise the potential of this new way of theming. In a nutshell, it allows you to have whatever output you want. Not only that but it allows template development to happen separately and in tandem with the main development effort.
Let’s have a quick look at how it works. At it’s simplest level you have 2 files: theme.html and rules.xml. The theme.html file is a standard html template and you can write this however you want. It is the rules file where it gets interesting. I won’t go in to the full details (see here for a full description) but here are some examples of what you can do.
<replace content='//*[@id=”content”]' theme='//*[@id=”content-area”]' />
this replaces the element in the theme.html with whatever content Plone produces within #content element.
<append content='/html/head/style' theme='/html/head' />
this adds all the styles from Plone.
<drop theme='/html/head/comment()' />
This removes comments form the theme.html appearing in the site.
It uses Xpath, something that I’m familiar with and very easy to learn. With deliverance it gets even easier because you can use CSS 3 selectors. All-in-all you have a very powerful way of theming Plone whilst having a fantastic level of separation and flexibility.
I’m very hopeful that collective.xdv / Deliverance will be the solution we are looking for and I’m really looking forward to using it on forth coming projects.
Probably not new, but I can’t find mention of it anywhere so I’ll post it here:
#foo.bar,
#foo.baz {
background: blue;
}
In the CSS above, #foo.baz effectively neutralises #foo.bar in Internet Explorer 6. It will never be applied. The same happens even if you separate the grouped selector into two statements like this:
#foo.bar {
background: blue;
}
#foo.baz {
background: blue;
}
Anyone seen this before? It’s hard to think of a short description, or something to Google for. “IE6 grouped selector with combined id and class selector bug”.
I worked around it by removing the classes from the selector (which was fortunately possible in this case.)
And before you ask, one of our largest clients is a multinational corporation whose internal IT policy has standardised on IE6.
[Update: As usual, spelling out the problem helped me find other mentions of it here and here.]
Natalie Downe of Clearleft has written a very useful presentation entitled CSS Systems, or, “Writing Maintainable CSS”. These are principles and patterns for writing HTML and CSS that makes it easier to hand over to other people to maintain, and generally more robust. It’s very relevant for agencies like us, and I was pleased to find that the system we developed internally (documented on the company wiki) correspond with hers about 99%. This blog post consists of comments, additions, qualifications, agreements and occasional disagreements with her presentation.
Best Practices for Speeding Up Your Web Site — part of an excellent series of articles on the Yahoo Developer Network.
They mainly focus on the front end, as that is where you’ll get most bang for your buck. They make frequent reference to YSlow, a Firebug extension that looks extremely useful.
The presentation here is also strongly recommended, as it makes succinct arguments for all the techniques. (View on Slideshare to see it full-screen.)
Some things were familiar to me (and most are already standard practice for my colleagues), many weren’t (e.g. avoid @import for CSS), and some I know of but haven’t been convinced of before (e.g. CSS sprites). I was quite intrigued by this example of CSS sprites in use on Google. (When using CSS sprites, remember to consider their accessibility to screen readers, and don’t use if you want them to print.)
After the furious controversy and rationalisation unleashed by Microsoft’s embrace of version targeting from IE8 onwards, we were thrilled by their u-turn on the decision yesterday. Instead of acting like IE7 unless instructed otherwise, “IE8 will, by default, interpret web content in the most standards compliant way it can.” Big sigh of relief.
And today Microsoft released the first IE8 Beta. Thanks to John Resig for his excellent review, pointing out all the significant improvements as well as omissions. As Resig points out, it’s primarily my JavaScript-coding colleagues who’ll see the greatest leaps forward, but I’m amazed and happy to see support for ARIA, meaning we can finally improve the accessibility of Ajax-based web applications. And I love the Firebug-like integrated debugger — you can even use it when in IE7 mode!
In the review, Resig makes one comment that resonated with me: “I simultaneously feel both joy and anger in seeing these fixed. Happy that they’re being released and anger for the fact that I had to struggle through them and that they now consume some portion of my brain.” Joy and anger. That’s exactly what IE8 makes me feel. We’re made to feel grateful for the fixing of years-old bugs that on any normal software product wouldn’t have been tolerated for longer than a few months.
It’s always fun to find another bug in IE6. This XHTML/CSS kills IE6 out right. It is cut down from a real project and had us amused for a while.
This seems to be the minimal set that causes the crash. The negative margin is required too.
We swapped the <p> for a <span> in the end.
<head>
<style>
#inner DIV {
background: #cccccc;
}
#outer P:first-letter {
margin: -1px;
}
</style>
</head>
<body>
<div id="outer">
<div id="inner">
<div>
<p><a href="">ie6 breaks</a></p>
</div>
</div>
</div>
</body>
</html>
It’s a fairly common practice to specify a site’s primary font as { font-family: Helvetica, Arial, sans-serif; } That way, people with Helvetica installed (primarily Mac users) get the real thing you intend instead of Microsoft’s half-baked rip-off. Other people get Arial, and are none the wiser.
However, I got burned recently by some unintended side effects. Basically, Helvetica on the Mac has a much smaller line-height than Arial (which is identical cross-platform). On 11px sized text, the difference is 2px, more for larger text. This has ugly consequences wherever pixel amounts matter, which is most places except body text, for example navigation menus or when you’re trying to vertically align an icon with a text label.
Even worse, it’s impossible to work around without JavaScript-based platform detection. Since I draw the line at that, I have dumped Helvetica in most cases except headline sizes. To this typographical purist at least, the differences are invisible under ~18px.
Isotoma is a software services company based in York, specialising in Open Source solutions.
Recent comments