The importance of minimizing required markup
If formats are to be interchangeable, there must be standards as to how content will be labeled (using HTML tags, ids and classes) and how it will be structured. Otherwise the sites will be just as inflexible as they are without formats.
So the first step in designing a format that will have broad usage is to define the form of the source content and how it will be marked up.
When requiring specific markup for a format, the simple rules of thumb are:
In normal use, the application provides the content, and then applies one or more formats to provide the layout. If done properly, it should be fairly easy to later choose a different set of formats, to achieve a different layout look.
This implies that the method of providing the source content must be very simple, with a minimum of structure, and marked up in a way that makes the fewest number of assumptions about how it will be displayed. And yet do this in a way that the formats that are applied can be assured that they are manipulating the correct elements.
The biggest problem in creating standard layouts is defining how the source content must be marked up (tagged). This can only be achieved through standards that define which tags will be applied to the source content. Once content is properly tagged, all other structure and properties can be applied.
As it turns out, less is more. The less-specific the tags and the less the starting structure, the more the content can be manipulated. And thus the greater the range of possible future variations on a theme.
As an example, in most web pages, some form of navigation to other locations needs to be provided.
Almost all navigation layers display content to identify a location, and their function is to route the user somewhere or take some action. But there are endless variations. Some might be in the form of menus, other may use some other metaphor. Some might use graphical elements. Some might produce animation effects. Many will permit multi-level menu structures.
Yet the actual semantic content other than display mechanism differs very little from one to the next, because they must be easily understood by the end users. Each navigation approach requires some display content such as text and/or graphics to let the user know what will happen, and some action that will occur if the user activates it. All other details are determined by the specific navigation method chosen used by the page.
Therefore it should be possible to define a standard content data organization for navigation that would work for a wide variety of navigation methods.
A common approach is a navigation menu. And many widget designers require the web developers to mark up their code as a multi-level menu like this:
-
<nav-menu>
<menu-item href="intro.html">Introduction</menu-item>
<sub-menu>Concepts
<sub-menu2>Some Concepts
<sub-menu2-item href="concept1.html">Concept1</sub-menu2-item>
<sub-menu2-item href="concept2.html">Concept2</sub-menu2-item>
</sub-sub-menu2>
<sub-menu2>More Concepts
<sub-menu2-item href="concept3.html">Concept3</sub-menu2-item>
<sub-menu2-item href="concept4.html">Concept4</sub-menu2-item>
</sub-menu2>
<sub-menu-item href="examples.html">Examples</sub-menu-item>
</sub-menu>
</nav-menu>
Note that the sub-menus are clearly marked as being sub-menus, and their menu items are clearly marked as belonging to them. The advantage of this kind of structure is that it is very simple to directly apply styles, as each level is distinctly marked differently from the other levels. There are a number of widget frameworks that work precisely this way.
The problem with the above approach is that a multi-level menu structure is only one possible way to present navigation capability to the user. There can be countless other ways of offering the same navigation functionality, that are not in a 'menu' format.
To create interchangeable layout elements, the source content being layed out must be in a form that is compatible with a large number of different approaches.
Thus a requirement for the developers to provide the navigation elements marked as 'menu' elements is too specific. It is even more of a problem when the 'sub-menu' markup is added.
About the only thing that navigation elements have in common across all of the different presentation methods is the target destination address or action. Some may have no text labels, just images. Others will have no images, just text. While most current navigation layers are menu-like, this is not universal, nor is it likely to remain so in the future.
So marking the navigation elements as 'menu' such-and-such would be imposing menu semantics upon the element content. The naming would look odd if applying a look that was not at all a menu structure.
Marking sub-elements as 'sub-menuXXX' adds no new information. As a matter of fact, it actually decreases the value to the web designer to require such markup, because reorganization of the navigation data would require matching renaming of the tags.
Content should just be content. In a great many cases, it is completely unnecessary to have content marked other than generically.
When using HFL, it is usually only necessary to require just enough separation of the content for the format to be certain of which elements are which. Any markup past that not only clutters the source content, but can make it very difficult to create plug-compatible format libraries.
In the example above, an HFL format can determine the nesting behavior of the navigation data from its hierarchical structure. Those formats that provide a nested menu effect can infer the hierarchy from the data. Those that present the navigation in other ways are not bound by the requirements of the menu versions.
In our example of a navigation layer, for the vast majority of navigation layouts elements could be described as just 'item'. In which case the application code would provide the navigation data like this:
-
<nav>
<item href="intro.html">Introduction</item>
<item>Concepts
<item>Some Concepts
<item href="concept1.html">Concept1</item>
<item href="concept2.html">Concept2</item>
</item>
<item>More Concepts
<item href="concept3.html">Concept3</item>
<item href="concept4.html">Concept4</item>
</item>
<item href="examples.html">Examples</item>
</item>
</nav>
Notice that all levels are just marked with the generic tag <item>. There is no need to mention 'menu' ever, nor is it necessary to spell out sub-menus. There is no need to be specific at all. If the format wishes to create a multi-level menu structure, it has all the information it needs to do so. Other formats may do something else. But all formats can see what is intended.