Wednesday, November 19, 2014
“Float” – CSS Feature and Symbol of Change
Ever since I started the Bleeding Edge session at the Society for Technical Communication Summit in 1999, I’m asked how quickly something new really emerges to affect technical communication. It doesn’t happen that often but it does happen – Microsoft’s introduction of HTML Help at the WinWriters conference in 1997 turned online help in a new direction in an hour. This column discusses another such example of change, the CSS “float” property. The float property’s impact won’t be as quick or dramatic as that of HTML Help but I think that what it symbolizes for tech comm is just as far-reaching.
The W3C introduced float in CSS1 in 1996. (See http://www.w3.org/TR/REC-CSS1/#floating-elements.) But it remained little known in technical communication until responsive design, promulgated in 2010, came to tech comm through help authoring tools in early 2014. In this column, I’ll briefly describe the float property’s function before turning to the larger issue of what I think it symbolizes for technical communication.
Float is a CSS property that lets us position elements on HTML pages. No big deal, you say. We’ve done that for years using simple inserts. True. What if we need multiple graphics side-by-side on a page? Again, no big deal. Create a table, hide its row and cell borders, and insert the graphics in adjacent cells in a row. Philosophically, using tables for page composition is wrong but it’s worked fine for years. Until responsive design arrived.
Responsive design lets us create one (the crucial word) online output that automatically reformats itself for the device on which it’s displayed. For example, say you have to create online help to run on large-screen devices like desktops and laptops and small screen devices like smartphones. You can create two outputs, each designed for its target device. But now add support for 10” tablets? That’s three outputs. Then 7” tablets? That’s four outputs. At some point, you won’t have enough resources to create and maintain all your different outputs. Responsive design solves this problem.
Responsive design lets you create one output that can detect the properties of the device on which it’s displayed and tailor itself accordingly. For example, three graphics laid out horizontally when displayed on a large screen automatically shift to a vertical format as the screen gets narrower. On the first screen below, I inserted the first group of three graphics in a table. I inserted each graphic in the second group normally – not in a table – but specified a left float for it. On a wide screen, there’s no difference.
As the screen narrows however, like shrinking to tablet size, the graphics in the table can’t shift because the table controls the layout. The result is the horizontal scroll bar. But the graphics in the second group, controlled by the float setting, automatically start shifting to a vertical format shown in the next image.
As the screen narrows further, to smartphone screen size, the graphics in the table still can’t shift but the second set of graphics, controlled by the float setting, automatically shift to a full vertical format as shown below.
Float also lets us move whole columns, change how text aligns next to images, and more. This is what lets us create the “fluid grids” that give responsive design much of its layout flexibility.
The float property can get very complex but it’s easy to understand and apply for most online help and documentation projects. For example, to get the graphics to behave as shown in the figures above, the code is simply this:
Your help authoring tool’s stylesheet editor lets you add the floats without getting into the actual code. You can start experimenting with it now.
Why spend an entire column on a little-known piece of CSS code? In my opinion, float symbolizes four shifts taking place within technical communication.
· Online superseding print – If you only output print, float is irrelevant. But if you output print and online or online only, you should optimize your content for online. Some techniques for doing so have been available to technical communicators for years, like using relative size units (em, rem, or %) for text rather than the familiar points, or embedding index entries. Float is the latest such technique to reach us. The more you think “online” first, the more in tune you’ll be with changes in technical communication.
· Growing interest in output to mobile – For years, computer screens were so large that we rarely had to worry about screen real estate. But growing interest in mobile as a single source output option makes it increasingly important to find automated ways to use the same content on different-sized screens. Programmatically-controlled layout modification techniques like float do that and let us adapt quickly as new output requirements appear.
· HTML5 output – HTML5 output itself doesn’t need floated graphics. But one of HTML5’s benefits is responsive design, and you’ll want to look at using float to make the most effective use of responsive design.
· Increased development rigor – Poor development practices like HTML tags with no end tags and tables created by using the tab key to create columns have largely vanished as our authoring tools and practices improved. Others, like local/inline formatting, are slowly vanishing as more authors use styles. The result is that improvements in programming practices are reaching increasingly esoteric areas like graphic positioning control. We’ll never totally eliminate bad practices and “hacks” but we’ll minimize them through techniques like float.
The symbolic effect of float is that it illustrates how web coding practices are increasingly available to the technical communication world. As technical communication moves away from “writing” and toward “content” and the lines between web development and technical communication continue to blur, techniques like “float” push technical communicators closer to web developers, letting us future-proof our material and our jobs and get into increasingly interesting work.
Neil is president of Hyper/Word Services (www.hyperword.com) of Tewksbury, MA. He has 35 years of experience in technical writing, with 29 in training, consulting, and developing for online formats and tools including WinHelp, HTML Help, JavaHelp, CE Help, XML, RoboHelp, Flare, and others now almost unknown. Neil is MadCap-certified for Flare and Mimic, Adobe-certified for RoboHelp, and Viziapps-certified for the ViziApps mobile app development platform. He is an STC Fellow and the founder and manager of the Beyond the Bleeding Edge stem at the STC summit. You can reach him at firstname.lastname@example.org.
Thanks to Allen Beebe, Cheryl Landes, and Deborah Sauer for their comments.
This post first appeared in the Society for Technical Communication's Intercom magazine (intercom.stc.org)