Rigid Book vs Fluid Web

Most of this site contains vast amounts of textual information arranged in discreet packages, each of which is sub-divided into specific blocks – otherwise known as books and chapters.

For novels published through traditional printed media, once a particular font has been chosen (Times, Garamond, Baskerville, etc), it’s formatted as justified text within the page of whatever book size has been selected (A5, 6″ × 8″, etc), and that’s how things remain unless it is re-set as part of a new edition, or the entire design is reduced in size when issued as paperback from an initial hardback release. This rigidity (= consistency) of output even allows an author to create special effects within known boundaries / borders, such as creating columnar layouts, displaying images, changing fonts for drop-cap or body effect (e.g., to distinguish different narrators), and allowing the textual equivalent of what in cinema would be overlapping dialogue.

In theory, the ‘epub’ format would be ideal as it’s just a compressed version of the html that underlies the current web pages, though minor changes would be needed to account for differing colours and fonts. However, it has been surprisingly difficult to get even the simplest of layouts to convert properly across three sample readers on just the Android platform, and though the program Sigil which was used to create the actual epub did a very good job and was easy to use, maintaining two sets of incompatible code was deemed too messy as it could too easily lead to differing versions of text.

When displaying text within a web-page, however, precisely duplicating the printed page by forcing text into a specific width can be extremely restrictive, whilst having all of the text covering the full width of what may be a very wide screen (1920 is fairly common now because of HDTV, whilst high-end monitors exceed this) can lead to visual overload and difficulty in scanning the lines. Allowances also have to be made for people re-sizing their viewing arena, or using the zoom facility on their browser, all of which operate in different ways and can affect the manner in which text is displayed, not just its apparent size.

A decision was made to use the middle 50% of the screen, and in removing the first-line indents for each paragraph, to open up the space between them; hopefully this will meet the majority of needs whilst allowing a fully fluid layout. The biggest problem with this arrangement is when encountering multi-columnar layouts, for where in a fixed-width setting I have written lines and paragraphs to align with one another and finish at the same time (or where they don’t, to have spanning lines appear ‘nested’ one within the other), duplicating this in a fluid environment can lead to lots of empty space. It was decided to keep the columns as separate entities with no lines crossing between them, thus maintaining the parallel structure but sacrificing the neat endings.

This effect can be seen in the short example below, where the text flows within a containing element, which has been achieved by using css (which is far easier to maintain) :

This should look the same as the following example, which uses true table cells; if not, then you need to update your browser :

left left left left left left left left

centre centre centre centre centre centre

right right right right right right