Is this finally the era of wysiwyg web design?

You may have wondered why a web designer’s life has to be so hard and, in particular, why you can’t create pages in a simple wysiwyg environment, like those used for print or PDF documents.

This dream of “code-free” rich design is finally being realised – so is the future of the web going to be wysiwyg? Before I look at modern authoring tools, let’s remember why the problem arose in the first place.

The beauty of wysiwyg authoring was that you could concentrate on design without having to worry about coding

It was because HTML is a page mark-up language, as opposed to a page description language such as PostScript, which specifies every detail of a page’s appearance, from each line’s placement within multiple columns to the fonts to be used. HTML was devised to say nothing about presentation, but merely to divide a text into structural segments using semantic tags. Tim Berners-Lee’s HTML represented every page as a single column, and delegated typographical choices on how to render the text – typeface, size, alignment, leading and so on – to the viewer’s web browser.

However, from the moment Mosaic/Netscape’s popularity made the web graphical, both consumers and creators began to demand more design choice, and software developers met this demand with dedicated authoring tools: Adobe PageMill and PageMaker, Microsoft FrontPage and Publisher, GoLive CyberStudio, NetObjects Fusion, QuarkXPress and scores of others. All of which promised to make web design as simple as print design with visual, code-free, wysiwyg design modes.

First-generation wysiwyg

These wysiwyg packages let you add box containers for text and style them by choice of typeface and size, although most shied away from advanced capabilities such as multiple columns, adjustable leading and text runaround. However, some DTP packages went the whole hog, promising to output any print design for browser delivery, and soon even office productivity applications were promising to let users “print to the web”.

The beauty of wysiwyg authoring was that you could concentrate on design without having to worry about coding – you could leave all the HTML and graphics to be generated by the authoring tool, and all you needed to do was preview the results and check everything was how you wanted it before posting to your server.

The difference between this wysiwyg dream and harsh reality became apparent soon enough. You suddenly discovered that your beautifully crafted design looked a complete mess on Macs, or that the scrolling marquee tag was supported only in IE, or that your careful choice of fonts had been ignored. And most embarrassing of all, your entire page looked as expected only because it had been rasterised into a GIF of gigantic size!

The realisation dawned that web publishing isn’t the same as printing, nor even local previewing. There were good reasons why Tim Berners-Lee restricted HTML as he did: returning to a streamlined structural text mark-up was the only reliable way to deliver content to the multiple platforms and browsers used by a huge and diverse web audience, and to make content easy to find by search engines. HTML’s lack of design power wasn’t an easily rectifiable oversight, but reflected the nature of the medium. Web designers needed to work within the limitations of cross-platform browsers, to work with HTML rather than against it.

This return to the drawing board didn’t mean cutting out design completely, since you could still divide up your pages to create a simple layout using table tags and specify font tags – although the latter had to be used sparingly and specified as font families, falling back to generic “sans” or “serif” if an end user didn’t have your preferred font installed. Such HTML-only design was certainly rudimentary, but with judicious use of web-optimised bitmaps it was possible to give your pages character, branding and impact.

Former print designers began to appreciate the beauties of HTML and simple web design: keeping tight hands-on control over your own HTML meant you could be sure that the results would be streamlined, efficient and guaranteed to work across all browsers and platforms.

Armed with new understanding, it became apparent why automatically generated wysiwyg code had failed. Building complex layouts from multiple nested table elements, dozens of table cells held together by transparent GIF-based spacer img elements, and hundreds of font tags specifying typeface and size over and over again, created an unreadable and unmodifiable rat’s nest of code that was a travesty of Berners-Lee’s HTML vision. The fact that HTML wasn’t PostScript had never been more obvious, and this first attempt at wysiwyg web authoring was dead in the water.