The tragic story of HTML
HTML started off as a simple markup for text. It was really basic way to do add a little bit for formatting to what was at the time a text only web. The tags where simple: links, text, bold, italic. Then there was some layout tags left, right, center. Then more layout tags, table, div, span and font. Pretty soon HTML was being used to represent the graphical visions of designers. On top of this we layered all the tools that developers want to build web applications, and as a final touch we added CSS and XML to abstract the look and feel as well as the data from the document.
If you look at the source of a webpage today it's very difficult to state what parts are graphical elements, what parts are content and what parts are data driven. It's all mixed in together.
A typical HTML document it's a complete mess. Since HTML can be edited by hand there are many conventions and many correct ways to implement the same design. At the same time there are many ways that may appear to be correct in one browser but will completely fail on another browser. HTML is inefficient to write, all browsers have subtle interpretation issues, there is always a multi-browser and platform testing issue. What you see is never what you get (WYSINWYG).
- Raw HTML can define text as well as layout in the same line - This makes it hard to internationalize or translate. How do you know that if you change the text you're not inadvertently changing the layout.
- Raw CSS can define layout but it can also describe Code like interactions such as hovering, hiding and repositioning elements dynamically.
- Raw JavaScript can manipulate page elements but it is also often used to fetch and update data sections and display text.
If we wanted to design a modern web-browser without the confusion and history of HTML limitations it would be broken up into four proper parts.
- Text
- Data
- Layout
- Code
1. Text - The text part would contain a list of text blocks. Each block would be a string of text with optional number/letter style tags. <1> <2> <3> within the text. A document could have any number of text sections and these text sections could have descriptive names such as title, description, introduction, etc. These descriptive names would be optionally used by the code or layout section to be described later.
2. Data - The data part would contain a list of data blocks. The data block would either be in-line like XML or would refer to an external document. External data would update dynamically and could trigger events that could be used in the code section.
3. Layout - The layout portion of a document would contain just layout, it would contain, sizing information, position and orientation, accessibility keys and alternative layouts for alternative size devices. It would apply colors, fonts and attributes to the tags within both the text and data sections. Images would be treated as layout elements but descriptive text would stay in the text section. Links, buttons and other elements could also be defined in the layout but any text or labels would continue to stay in the text section.
4. Code - The code section would be the glue that could tie these sections together. The code section would dynamically change layout, request updated data and change one text block for another.
This approach allows you to separate the page technologies by job function. A developer doesn't have to concern himself with layout and look and feel issues. A graphic designer can make the site look cool and not worry about the text. An international translator can translate the text without worrying that this will impact the code or the layout.
The text section is where most writers would enter content, it's where bloggers would put their text, it's where lawyers would enter notes and it's where web site owners could make text changes.
The data section is where database administrators could enter data or SQL queries.
The layout section is where a graphic designer could add a cool look and feel elements.
The code section is where a developer could wire it all together.
By separating the concepts you allow better tools for each one.
-Internationalization tools would optimize the tools that deal with text
- Accessibility tools would read the text and layout without the graphical aspects of the layout.
- Layout tools would allow you to create rich graphics and presentation allowing you to absolutely position elements where you want them.
Template Template Templates
Here's where it gets really cool. A template can be any combination of the 4 core elements with one or more elements being dynamic. For example if you have a design with text being dynamic and layout, data code being part of the template then you have a typical blogging template. If you keep the Text, Data and Code but change the layout you have a presentation template suitable for creating applications for a cell phone or TV. If you change the text but keep everything else you have an international version.
Tools Tools Tools
Any new approach has to begin with WYSIWYG. This means that the tools have to be visual. Designers want to be able to design it on the screen and have it show up the same way. This means that the language and schema of the markup is second chair to the tool that creates it. The quality of the design rests more with the designers tools then the schema that creates it. A great schema with terrible design tool yields terrible designs. A great design tool with a terrible back-end schema leads to version 2.0 where you fix the back-end. ;)