The Goal of HFL Formats

CREATING HFL FORMATS

The goal of HFL formats

HFL formats are packages of content and layout that combine to produce a layout effect. They are usually HFL code and any necessary associated content such as HTML, CSS, javascript, images, etc.

The goal of HFL formats is to create re-usable libraries of interchangeable layout effects. The idea is that users should be able to create their own layouts by assembling pieces a la carte. That in turn requires that the choices of the layout components share the same requirements as much as possible.

When designed properly, an HFL format should be flexible enough to work in a wide variety of applications. While only the simplest formats will work anywhere, it is usually quite possible to build formats that have broad applications. It is the responsibility of the format designer to see that the format makes the fewest number of assumptions about the context in which it is used, so that users can use them without having to know too much.

A prime example of the power of HFL formats is the encapsulation of widgets in the javascript toolkit jQuery. There are countless widgets available in jQuery, with many duplications and variations on a theme. Most of the variations have specific requirements, such as the HTML structure that the content must lie within, which classes and ids must be assigned to the HTML elements, and so on. To move from one jQuery widget to a different implementation usually requires re-working the source code to meet the requirements of the new widget's designer.

An HFL wrapper format around a widget can greatly reduce the conflicts between widget requirements. It can standardize the external interface, and create or modify the content to match the requirements of each specific widget.

Well-designed formats are user-friendly, by providing not just the format's base functionality, but sample code and images as well. If a format depends upon the web designers creating .css code to support it, it should provide sample .css statements. If the format requires images, sample images should be provided so that the format user can understand what goes with what.

Marking up the content: choice of tag names

Creating interchangeable format libraries is only possible if there is some standardization of the HTML tags used to mark up the source content.

In normal use, the application provides the content, and then applies one or more formats to provide the presentation, or 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 content must be very simple, with a minimum of structure, and marked with a convention of tags so that the formats can be assured that they are manipulating the correct elements.

But what would make sense as the correct way to tag (mark up) the content for one type of presentation might not make sense for a different presentation. To be able to swap the layouts requires that the respective formats agree upon how the content should be marked.

This can only be achieved through tag-name standards.

The rule of thumb is: less is more. The less-specific the tag, the more it can be manipulated. And thus the greater the range of possible future variations on a theme that can be provided by formats.

In order for a tag to be recognizable by a wide range of possible formats, the tag should define its content's purpose without defining its presentation.

For example, in most web pages, some form of navigation to other locations needs to be provided. A common approach is a navigation menu, or 'nav-bar'. But that is only one possible way to present the navigation capability to the user. There can be countless other ways of offering the same functionality, that are neither in a 'bar' nor 'menu' format.
About the only thing that navigation elements have in common across all of the different presentation methods is the target destination address. 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' or 'navbar' such-and-such would be imposing menu or navigation-bar semantics upon the element content. In other words, it would imply what its presentation would be.
A better tag then would be just 'nav', because it could be application to a much wider range of presentations. Similarly, the navigation items need not be marked other than as the generic term 'item'. The user would then only need to mark the navigation content with just enough information that it can be presented, whether that be as a nav-bar, a drop-down menu or some other method.

Minimizing the content the user has to provide

In order for a tag to be recognizable by a wide range of possible formats, the content the user must provide should be kept to a bare minimum.

Again, the rule of thumb is: less is more. The less the user provides, the more the content can be manipulated. Formats can easily add any necessary structure or properties, so any that can be added should be left out of what the user must provide.

Not only are additional structure and properties unnecessary in most cases, addtional elements can actually interfere with the ability of formats to recognize important elements and make structural changes.

Display elements like <a> tags and properties like widths and margins all limit the ability of formats to create dramatic presentations. These elements might not only have to be removed, but can make it difficult or impossible to make reliable identifications of the real content.

As a example, suppose we wish to create a navigation element within a format. What is the minimum information that the user should provide? Most navigation mechanisms such as nav-bar menus, drop-down menus, and image-based navigation panels all have common elements. For most common pages, these elements have some kind of label, be it text or graphics, and often some kind of action, such as a hyperlink, or invoking a script.

And that should be the only content that the user normally provides.

EXAMPLE:
- <nav>
    <item href="intro.html">Introduction</item>
    <item href="concepts.html">Concepts</item>
    <item href="scopes.html">Scopes And Features</item>
    <item href="io_functions.html">Built-in Functions</item>
    <item href="using_fmts.html">Formats</item>
  </nav>
Notice that the user provides just the minimum amount of information needed. The user provides no HTML structure, nor additional properties such as marking the items with <a> tags. All of that can be constructed by the formats.
By not providing that additional information the door is open to presenting that navigation information in better, more interesting ways, such as animations. The less the user provides, the more the format can do.

	The Goal of HFL Formats
	Introduction Introduction Background Why A New Language? HFL Transformations HFL Formats HFL Language Differences Getting Started Install HFL Compiling HFL Files The HFL Preprocessor Parse mode Tutorial Index Of Commands Concepts Basic Concepts Cells Scopes Clip Pools Modal Scopes Pseudo-Variables Temporary Classes Advanced Concepts The Evaluator Aligning Content Scope-lists Scopes And Features HFL Scopes Defining Scopes Variables Cell Properties Flow Control And Functions Advanced Scopes Built-in Scopes Objects Code Generators Generating Javascript Code Built-in Functions Input/Output Functions String Functions Array Functions Hash Functions Filename Functions Object Functions Logging Functions Other HFL Functions Debugging The HFL Debugger Debugger Inspector Commands Cell Inspector Commands Other Inspector Commands FAQ Formats Using HFL Formats Creating HFL Formats The Goal of HFL Formats Minimizing Required Markup Format Organization

	CREATING HFL FORMATS The goal of HFL formats HFL formats are packages of content and layout that combine to produce a layout effect. They are usually HFL code and any necessary associated content such as HTML, CSS, javascript, images, etc. The goal of HFL formats is to create re-usable libraries of interchangeable layout effects. The idea is that users should be able to create their own layouts by assembling pieces a la carte. That in turn requires that the choices of the layout components share the same requirements as much as possible. When designed properly, an HFL format should be flexible enough to work in a wide variety of applications. While only the simplest formats will work anywhere, it is usually quite possible to build formats that have broad applications. It is the responsibility of the format designer to see that the format makes the fewest number of assumptions about the context in which it is used, so that users can use them without having to know too much. A prime example of the power of HFL formats is the encapsulation of widgets in the javascript toolkit jQuery. There are countless widgets available in jQuery, with many duplications and variations on a theme. Most of the variations have specific requirements, such as the HTML structure that the content must lie within, which classes and ids must be assigned to the HTML elements, and so on. To move from one jQuery widget to a different implementation usually requires re-working the source code to meet the requirements of the new widget's designer. An HFL wrapper format around a widget can greatly reduce the conflicts between widget requirements. It can standardize the external interface, and create or modify the content to match the requirements of each specific widget. Well-designed formats are user-friendly, by providing not just the format's base functionality, but sample code and images as well. If a format depends upon the web designers creating .css code to support it, it should provide sample .css statements. If the format requires images, sample images should be provided so that the format user can understand what goes with what. Marking up the content: choice of tag names Creating interchangeable format libraries is only possible if there is some standardization of the HTML tags used to mark up the source content. In normal use, the application provides the content, and then applies one or more formats to provide the presentation, or 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 content must be very simple, with a minimum of structure, and marked with a convention of tags so that the formats can be assured that they are manipulating the correct elements. But what would make sense as the correct way to tag (mark up) the content for one type of presentation might not make sense for a different presentation. To be able to swap the layouts requires that the respective formats agree upon how the content should be marked. This can only be achieved through tag-name standards. The rule of thumb is: less is more. The less-specific the tag, the more it can be manipulated. And thus the greater the range of possible future variations on a theme that can be provided by formats. In order for a tag to be recognizable by a wide range of possible formats, the tag should define its content's purpose without defining its presentation. For example, in most web pages, some form of navigation to other locations needs to be provided. A common approach is a navigation menu, or 'nav-bar'. But that is only one possible way to present the navigation capability to the user. There can be countless other ways of offering the same functionality, that are neither in a 'bar' nor 'menu' format. About the only thing that navigation elements have in common across all of the different presentation methods is the target destination address. 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' or 'navbar' such-and-such would be imposing menu or navigation-bar semantics upon the element content. In other words, it would imply what its presentation would be. A better tag then would be just 'nav', because it could be application to a much wider range of presentations. Similarly, the navigation items need not be marked other than as the generic term 'item'. The user would then only need to mark the navigation content with just enough information that it can be presented, whether that be as a nav-bar, a drop-down menu or some other method. Minimizing the content the user has to provide In order for a tag to be recognizable by a wide range of possible formats, the content the user must provide should be kept to a bare minimum. Again, the rule of thumb is: less is more. The less the user provides, the more the content can be manipulated. Formats can easily add any necessary structure or properties, so any that can be added should be left out of what the user must provide. Not only are additional structure and properties unnecessary in most cases, addtional elements can actually interfere with the ability of formats to recognize important elements and make structural changes. Display elements like <a> tags and properties like widths and margins all limit the ability of formats to create dramatic presentations. These elements might not only have to be removed, but can make it difficult or impossible to make reliable identifications of the real content. As a example, suppose we wish to create a navigation element within a format. What is the minimum information that the user should provide? Most navigation mechanisms such as nav-bar menus, drop-down menus, and image-based navigation panels all have common elements. For most common pages, these elements have some kind of label, be it text or graphics, and often some kind of action, such as a hyperlink, or invoking a script. And that should be the only content that the user normally provides. EXAMPLE: <nav> <item href="intro.html">Introduction</item> <item href="concepts.html">Concepts</item> <item href="scopes.html">Scopes And Features</item> <item href="io_functions.html">Built-in Functions</item> <item href="using_fmts.html">Formats</item> </nav> Notice that the user provides just the minimum amount of information needed. The user provides no HTML structure, nor additional properties such as marking the items with <a> tags. All of that can be constructed by the formats. By not providing that additional information the door is open to presenting that navigation information in better, more interesting ways, such as animations. The less the user provides, the more the format can do. Previous: Using HFL Formats Next: Minimizing Required Markup