Author Archives: gwilym

Practical collective.xdv

Last year I published an overview of collective.xdv. A new and very promising way of theming Plone. Now that we’ve used it a few times I thought I’d document some the process we went though.

Firstly read the documentation:

It’s very good and shows you the best way to structure your theme.

Our setup:

  • Plone 3.3.5
  • CMF 2.1.2
  • PIL 1.1.6

Setting Up Collective.xdv Best Practice

The collective.xdv documentation has a very good description of the best way to setup  collective.xdv read it. I won’t go in to the full details as they are well documented but the basic points are:

  • Setup a Plone product
  • Use css registry to serve the css, instead of serving through XDV. This gives you the all the advantages of managing CSS through CSS registry (compression etc).
  • Create your html/css templates.

In our setup I turned off all stylesheets but kupustyles.css, authors.css, kupuplone.css, kupudrawerstyles.css when serving through XDV. I also created a new stylesheet to pull in what we needed from the admin theme. By adding back in on a case-by-case basis you can avoid CSS conflicts with your themes styles. Of course if you’re completely mad you could decide to restyle the admin interface (good luck with that).


There were a few snags we ran into. Here’s how we fixed them:

no styling with portal_factory

We ran in to an issue with our Plone setup and portal_factory. The transformation stopped working when you added content, leaving you seeing the default plone theme. Very confusing. Apparently it’s fixed in 3.3. but for whatever reason we had to use this monkey patch:

Here are some great tips for using collective.xdv as well:

IE conditionals

By default I was removing comments from both the theme and content. (<rules />) . As the IE conditionals are wrapped in comment tags I had to add them back based on their order.

<append theme='/html/head' content='/html/head/comment()[3]' />
<append theme='/html/head' content='/html/head/comment()[4]' />

Lack of applyPrefix support for Plone 3

Plone 4 has a option to parse a stylesheet for relavtive URLs and apply an absolute prefix. You’ll have to do this manually with Plone 3.

Styling the Search Box

I’m not a fan of Plone search box so it was nice to be able to just pull out the action attribute to use:

<prepend theme='//*[@id="search-form"]' content="//*[@id='portal-searchbox']/form/@action" />

Using Conditionals to Select Templates

Using Plone’s default body classes or defining your own you can specify which template to use based on class name. This is a big win as you no longer have mess around with macros or the main template. For example:

<theme href="one-column.html" css:if-content="" />
<theme href="two-column.html" css:if-content="body.two-column" />
<theme href="three-column.html" css:if-content="body.three-column" />

Pulling in Content

You could bring in content piece-by-piece – writing rules for each element. I found this was time consuming and difficult. In the end it made more sense to pull in the all content from each column. If you want to re-work the HTML of a standard portlet it’s better to use inline XSL (more on that in the next article)

<replace content='//*[@id="portal-column-content"]/div/*' theme='//*[@id="content"]' />


From my perspective:

  • It gives control of the templating to the front-end dev / designer.
  • It allows working in parallel with Plone devs rather then them waiting for templates to be completed.
  • Using collective.xdv dramatically sped up the time we had a skinned site we could show to the client.
  • We cut the time we spent doing donkey work and increased the time we could spend on worthwhile development.

I’ll leave it to the Senior Developer to give the pros from an experienced Plone developer:

  • No mangling of reference HTML templates as they are implemented in TAL by Plone Devs
  • improved team workflow as HTML/CSS Designer/Dev can work in parallel with Plone Devs
  • lighter workload for Plone Devs as there is much less HTML to implement in TAL
  • reduced need to explicitly remove unwanted elements from TAL templates – they can mostly be ignored by xdv
  • flexibility in layout between pages – i.e. one-column, two-column, three-column layouts don’t require a mass of macros and modification of main_template to achieve. This can instead be pushed up to the XDV layer.

Jonathan Stark – “Building mobile apps with HTML, CSS and JavaScript” workshop

Jonathan began with an overview of the current mobile landscape. In a nutshell it’s a minefield of platform fragmentation and device fragmentation.

“‘It’s brutal to develop natively across platforms”

Jonathan Stark
So what to do? Well, we then looked at three approaches; native, web and hybrid. All have their advantages but hybrid looked the way to go for most mobile use cases. In Jonathan’s words the advantages are:
  • Web files bundled in native executable
  • Access to device APIs
  • Sell in native app stores
  • Not perfect, but pretty damn good

Next we looked at some useful guidelines for the mobile use case. A nice summation would be “Do one thing and do it well”.


We looked at various CSS3 features; advanced styling, transforms, transitions, animations etc. There’s a wealth of information out there on these so I won’t go into too much detail. Here are some interesting pointers:
  • android requires text-shadow to have a blur value.
  • box-shadow has performance issues, particularly on Blackberry (consider using media-query to turn off for Blackberry).
  • border-image is particularly interesting, as it does away with sliding doors css.
  • animations are hardware accelerated on iOS.
  • be careful of z-index on transforms. By default on it stacks above static positioned elements.
  • box-reflect works with form elements.
  • box-shadow takes up space like borders.
  • box-reflect works on <VIDEO> tag.
  • Talk of hardware acceleration for animation in the next version of Android  (Ice Cream Sandwich).
  • using lots of CSS3 gradients, animations, box-shadow will cause performance issues, tread careful and test often.
I liked the look of CSS animations. I have some reservations of how manageable they will become on medium to large projects. Having written code based animation sequences in Flash I know from experience it can get pretty complicated managing dependances and interactions. Using LESS, or SASS looks like an absolute must for using CSS animation on anything but the smallest projects.


Next up was looking at some of the useful offline features of HTML5. Namely; web storage, web SQL database and application cache. My personal favourite was web storage – it looked easy to use and very useful for state maintenance. Application cache also looked great but I can see huge problems debugging, even Jonathan struggled to demo it properly.

Phonegap, jQTouch and Sencha Touch

Here we looked at the various frameworks for building hybrid apps. Again there is a ton of info out there. Jonathan was obviously keen on jQTouch but I actually think Phonegap looked the more promising platform for development. It seemed to have a good balance between ease of use, learning curve and features. Sencha Touch looked really powerful, whilst  jQTouch looked lightweight and quick to build with.


In the final part of the day Jonathan showed some great debugging tools. If you’ve ever had to debug mobile CSS you know what a pain it is to debug on the device itself.  The stand out star for me was weinre, a really fantastic tool for debugging mobile apps.  The basic premise is it gives you access to the webkit inspector on your laptop which in turn is linked to the phone browser. It allows you to see exactly what is happening on the phone and allows live editing as well. Pretty amazing really.


Jonathan’s workshop has re-enforced my opinion that writing mobile apps for all formats is best done using HTML5 / CSS and JS.  The key benefits are:
  • write once*
  • The skills are already available and less costly than hiring native specific developers
  • one central code base
* They’ll always be some platform specific code needed.
All the slides and downloads from Jonathan’s talk are available here:

CSS3 Flexbox

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.

display: box

To define an element as a flexbox we set the display to box.

.flexbox {
display: -moz-box;
display: -webkit-box;
display: box;

Example 1


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;

Example 2

Box-orient is inherited i.e. child elements will also be aligned horizontally.

Example 3

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;

Example 4

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;

example 5

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;

Example 6

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;

example 7


This reverses the order of elements.

#main {
-moz-box-direction: reverse;
-webkit-box-direction: reverse;
box-direction: reverse;

Example 8

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;

example 9

Justify is a nice attribute, equally spacing elements within the parent container.

Final Example

example 10

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.

About us: Isotoma is a bespoke software development company based in York and London specialising in web apps, mobile apps and product design. If you’d like to know more you can review our work or get in touch.

Plone Theming or: How I Learned to Stop Worrying and Love collective.xdv

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:

  • easily portable between projects.
  • full control over CSS/HTML and JS output.
  • working in parallel with the development team.

So lets look at the various theming options for Plone.

“Plone theming is getting a bit complicated”

You’re not wrong. From what I can see you have 2 options:

  1. Write a custom stylesheet. It’s amazing what you can do with CSS, but that alone won’t cut it. We need to able to specify the HTML output to meet our high standards of accessibility and design.
  2. Create a ‘vanilla’ theme product. Creating a Plone theme is not for the faint hearted and to be honest it had me stumped. You really need to have a solid understanding of Plone and Zope to create anything worthwhile and while that is not necessarily a problem it’s certainly not my area of expertise.

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….

Deliverance / Collective.xdv

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:

<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 / prepend content:

<append content='/html/head/style' theme='/html/head' />

this adds all the styles from Plone.

Discard content:

<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.