HTML5 Zone is brought to you in partnership with:

I spend my spare time combining the luxury life of having no kids and a wonderful girlfriend with the agonizing pressure of blogging under my Onderhond monicker. As a front-end developer I am raised and nurtured at Internet Architects, a Belgian company investing a lot of time and resources in making the web a better place Niels is a DZone MVB and is not an employee of DZone and has posted 109 posts at DZone. You can read more from them at their website. View Full User Profile

Cleaning Up HTML, Part 2: Ordinal-Group Magic

05.28.2012
| 2127 views |
  • submit to reddit

Recently I reasoned why mixins and skins could change the way we write html in the near future, this article is the second and final part in a small mini series on how css could improve our html patterns. Rather than look at the joy css preprocessors can bring us, this time we'll be digging into the actual css3 spec. Our target? The ordinal-group property belonging to the (still experimental) flex-box spec. It's a little piece of wonder that will end up a valuable asset in our quest for reusable html.


flex-box and ordinal-group

Rather than explain the entire flex-box module I'll just link to a rather extensive Smashing Magazine overview. It tells you everything you need to know about flex-box and ordinal-group. The short version goes like this: ordinal-group allows you to visually re-order structural elements that reside on the same dom level and are grouped underneath the same (immediate) parent. Basically we can use css to visually rearrange dom sibling nodes without actually touching the dom. To see this in action, Jordan Moore made a very nice ordinal-group demo (resize to mobile resolution).

I would like to make one side-note before continuing. The ordinal-group example in the SM article is not at all representative. While you could indeed use the property to pull sticky posts to the top of a list, not only will you get into trouble when paging is introduced, there are also more fundamental issues with this solution. Sticky posts actually belong on top of a list because people are supposed to read them first. The same goes for people using assistive technology, so structurally they belong in the front, using ordinal-group just for display won't cut it and is actually a bad practice.

While there are still obvious limitations to using ordinal-group (it doesn't work with dom nodes that reside in different parts of the html), it fixes a very common design requirements/css shortcoming that has plagued html for years. It all has to do with source order versus display order, so let's find out what ordinal-group can do for us.

Because it looks better with the image above the heading ...

You know how some designs require you to put element above the heading that don't belong there, structurally speaking? A product image in a product grid or the publish date/author in a news article. Designers like to take elements like that and place them above the heading of the content type. Frankly as a html guy I don't really care, I just put the heading first and offload the difficult bits to the css guy (hello paddings and position:absolute), but there are some situations where even that is not possible.

/* html */ 
<article class="product">:
 <header>
   <h1> ... </h1>
   <div class="image"><img src="..." alt="..." /></div>
 </header> 
</article> 
/* css */ 
.product header {display:box; box-orient:horizontal;} 
.product header h1 {box-ordinal-group:2; box-flex:1;} 
.product header .image {box-ordinal-group:1; box-flex:1;} 

Even though it's a bit verbose, the code above allows us to keep a logical html structure while the css assures us that the image container will be shown above the heading. A real life saver, as variable content often breaks the padding/pos:abs trick. With this method to our disposal similar issues will finally belong to the past (at least when browser support allows it). Truly a tremendous help if you want to write consistent and reusable html code.

One negative aspect of ordinal-group is that it only works on dom nodes that reside on the same level. This may urge people to drop structural containers in favor of more css flexibility. After all, the more elements that reside on the same dom level, the more you can play with visual order. While understandable, this is actually a trap that could seriously degrade the quality of html and should not be positively advertised nor endorsed.

Sadly, no float support for flexbox items

One other recurring design requirement is to have a block of content positioned to the right of inline flowing content. To use a very simple example: just think of a float:right image at the beginning of a text section. Things get tricky when the text section needs a heading to the left of the floated block. The only way to do this is by placing the image first in source (before the heading) while the heading and content flowing around it come second. Another typical requirement in such a situation is that when no floated block is present, the content reflows to fill the gap left by the floated block. (For a more in-depth look at this issue, check my content layout headaches article.)

This sucks because you really don't want to put the image in front of the heading. It makes sense from a css point of view, but for someone who cares about logical structure it's close to committing a mortal sin. Ordinal-group could've provided the solution here, sadly float and ordinal-group don't mix too well. Whenever a float is set the display property of the element reverts to block and all the magic is gone.

Conclusion

There is definitely potential in the use of ordinal-group, if used wisely and purposely. As always, there is also plenty room for abuse and mis-interpretation. Ordinal-group is a property that allows us to keep a consistent html structure while the presentation of elements may differ in ways that were only possible by changing the actual source order. Make sure you always start with the correct and logical html structure, then fall back on ordinal-group to rearrange the visual display.

Published at DZone with permission of Niels Matthijs, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)