Experimental Lex

Playing with words.

Tag Archives: programming

Page Layout Hacks in HTML5

I have been meaning to share some of my experiences and solutions with advanced page layout using HTML5. This is a tough topic for a number of reasons. First, using HTML5 as an editable source format is a very imperfect practice. Really, it feels like a bunch of hacks you have to perform to make it … stick. Second, I have a feeling that the way we did it this time is not the way we will do it next time. I’m thinking we did not truly use the right CSS and HTML5 solutions available to us. So, I am hoping that we will also uncover more elegant hacks along the way.

So, let’s get started. We will start by discussing the underlying challenges based on the design requirements of the publication.

Tools and Workflow Overview
Like so many web designs, our digital publication was designed in Adobe Photoshop. The ideal magazine-style experience was mocked up to look like pages you might find in GQ or New York Magazine. First, we had the usual Latin text to serve as placeholder for the copy, and later the copy deck was inserted into the PSD one page at a time.

Within the PSD, separate layers were defined for each page and the content for each page was defined as a set of Photoshop text and image containers. You could switch between “pages” by turning off visibility of one layer and turning on visibility in another. It’s an age-old Photoshop trick for creating pages of content using one background and set of styles.

Oh, did I mention that the copy deck consists of a bunch MS Word files floating through the dark matter of our corporate e-mail system? As the copy for each article is updated, there is a massive challenge in getting copy updates into the PSDs, which became the de facto “master copy” of the content under development.

Yes, I did mention that this is an imperfect system.

Choosing the Right Tools and Workflow
I know it might make more sense to use Adobe InDesign as the basis of our page layout and content editing. However, InDesign is not really part of the standard workflow of a web design and development team. Yet. Moreover, the end product is an iPad app that renders HTML5 content with a magazine-style design and there is no automatic workflow to move InDesign pages to a custom HTML5 display solution. Perhaps someday.

Two-Column Page Layout and Paragraph Splitting
The core design called for a traditional page-flipping user experience. The desire was to provide the obviousness of flipping pages in iBooks, yet provide rich layouts with images in a multi-column layout. In our publication design, paragraph text is presented in a two-column layout with full text justification throughout. With two-column or any multi-column layout, text reflow from one column to the next and from one page to the next is a challenge. Even in a single column layout, you need to account for paragraphs that are split between pages.

With word processing and page layout programs, text reflow is a natural part of the software. Pagination is also handled smoothly since the program is always aware of the amount of space consumed by the text based on a multitude of variables, including: font styles and sizes, horizontal spacing between characters and words, vertical spacing between lines and paragraphs, etc.

With HTML, a paragraph is represented by content wrapped in a <p> element, which consists of an opening <p> tag and closing </p> tag. Everything in between is treated as a single paragraph. Even though it is sometimes called the “paragraph” tag, the <p> tag does not provide a way of reflowing between columns or pages. And so, a paragraph that breaks across different columns or different pages must be split into separate <p> elements.

Problems with Broken Copy
When splitting copy across paragraphs, the biggest problem is finding out where paragraphs are split and moving copy between different paragraph blocks. As copy gets updated or when formatting is changed, you have the possibility that the text reflow will result in a “domino effect” as the developer must move chunks of text between paragraphs in different columns/pages. Inevitably, there are mistakes made in this tedious task of moving text that one paragraph to another.

Problems with Full-Justification
This becomes a problem for fully-justified text where the left and right margin of each paragraph is perfectly aligned, since the words and characters are spread out to make this effect happen. Naturally, the last line of a fully-justified paragraph is exempt from this formatting rule. And since we are forced to split paragraphs between columns and pages, the last line of a column or page can look horribly wrong when it falsely assumes itself to be the last line of a paragraph.

Problems with Column Splitting
Our problem with splitting paragraphs is further compounded by page layouts that allow for banner images that span across columns. In the sample diagram below, you can see the different regions identified for column 1 and column 2, top and bottom. The column 1 paragraph text at the top (col1 top) needs to reflow to the bottom (col1 bottom). Again, we have the problem with paragraph splitting and the treatment of fully-justified text.


From the viewpoint of HTML programming, this is further complicated by the fact that HTML content is structured left-to-right, then top-to-bottom. In the diagram above, note how the two “top” areas are surrounded by yellow background. Even though it seems unnatural, the text copy for “col1 top” and “col2 top” are wrapped in the same horizontal <div> container. Same thing for the two areas of text at the bottom. This adds to the difficulty of proofing and fixing text copy.

We are just getting started with this exploration of the many challenges of managing text and page layout in a complex design. It may already seem that choosing HTML5 as the display format is a horrible mistake. Yet, I will go ahead and make two observations:

  1. We are hoping to discover a better approach to managing text copy and page layout as we dig deeper. In our initial development effort, the bulk of the HTML5 content development was handled by an external team. Some of the technical decisions that were made deserve some re-evaluation.
  2. We need a better content workflow and integration model for text copy that will provide better quality. Is it possible for HTML5 to be smarter about content and page layout? We intend to find out through some hardcore experimentation.