Intro: Hypertext Formatting Language

HFL: Hypertext Formatting Language

At first this may sound like one strange language, but as it turns out, the syntaxes of these four languages actually rarely collide with each other. By having one single formatting language, it is now possible to programmatically apply formatting that is specific to the content, and all in one place.

It is a very rich language that has tremendously powerful features, with over 5 years of development and testing.

What is structure-oriented editing?

Structure-oriented editing occurs when a program understands the structure of a document, and its editing actions can be specified relative to that structure.

Because HTML is a hierarchical description format, a structure-oriented editor for HTML must be able to see the hierarchy, and manipulate it. A structure-oriented editor can find and manipulate document structure as easily as a text-oriented editor can find and manipulate text strings.

Almost all web programming languages have text-editing capabilities. Server-side languages like PHP and Python have methods to insert and modify text strings within an HTML page.

Text-oriented editing can be useful when all that is needed is to make very small changes to a page, such as filling in certain fields. But it is very inadequate when one attempts to do any kind of structural modification or layout, because the application cannot 'see' the page structure nor its elements. Everything is just strings.

Program code can be written with text-oriented editing to create almost any desired effect, but because all actions are text actions, most such code by its very nature tends to be very verbose. While an experienced programmer can usually figure out what such code does with careful thought, the very verbosity of the code makes what it is trying to do obscure.

This is because all modifications are done as text strings. Any action beyond a simple text insertion is complicated, because everything is text. To locate certain elements requires searching the content as text. To compose output the application code must assemble HTMl structure and CSS formatting as text.

The code that makes such changes will always be a set of text operations, and that code will often bear little resemblance to the actual code being generated due to the cluttering of all of the text manipulation actions.

Text-oriented editing does not make changes based upon the semantics (or meaning) of the content. The actual HTML structure, attributes and CSS properties are just text.

But in order for a programming language to manipulate the HTML content and associated properties in a way that is clear and concise, it is necessary for the language to understand what it is working with, that is, manage them as actual structures.

In technical terms, one should be able to manipulate the page semantically, not just textually.

One should be able to navigate through the HTML structure, examine properties at each level, and be able to reorganize the structure at will. This is structure-oriented editing. A structure-oriented editor should be able to move elements around, make insertions, deletions and modifications and guarantee the final integrity of the HTML that is output.

To be fair, there do exist libraries that do have some capabilities to identify HTML components and manipulate them to some degree. But these require function calls to find content and make changes. Again, the code making changes bears little resemblance to the output. The details may be there, but are buried under a lot of code. The code is obscure, and not readable.

But what if that code looked exactly like the HTML, attributes, CSS and javascript that it was inserting or modifying? Not as function calls containing strings, but exactly the way it would look in a HTML source file? What if the web language natively understands HTML structure and uses attribute, CSS and javascript syntax, so that manipulations and changes can be written as some combination of them?

That is HFL.

It inherently understands the page's HTML structure and properites, and manipulates them as objects with exactly the same syntax as HTML, CSS and/or javascript, in any combination.

An example

  • Suppose we wished to highlight a particular row in an existing table in order to show it as the 'active' row, based upon the results of a database query. (Perhaps the table itself was generated as the result of an earlier database query.) To do this, we would need to apply a class to the row that matches the value returned from the query. The table might look like this:
    • <table id="pets">
          <tr> <td>Type</td> <td>Name</td> <td>Breed</td> </tr>
          <tr> <td>Dog</td> <td>Fido</td> <td>Dalmation</td> </tr>
          <tr> <td>Cat</td> <td>Fluffy</td> <td>Persian</td> </tr>
          <tr> <td>Cow</td> <td>Bossie</td> <td>Jersey</td> </tr>

  • If the query returned that the active row was for the cat named 'Fluffy', we would want modify the parent <tr> element of the <td> element matching that name so that the table would now look like this:
    • <table id="pets">
          <tr> <td>Type</td> <td>Name</td> <td>Breed</td> </tr>
          <tr> <td>Dog</td> <td>Fido</td> <td>Dalmation</td> </tr>
          <tr class="highlite"> <td>Cat</td> <td>Fluffy</td> <td>Persian</td> </tr>
          <tr> <td>Cow</td> <td>Bossie</td> <td>Jersey</td> </tr>

  • In a string-oriented editing language, code would have to be written to search for the table, make sure that it had the corrent id value, then parse for each of the row <tr> elements, and parse each of them for the second <td> element before a string comparison could be done. Then the code would have to insert the ' class="highlite"' string just past the 'tr'. This code would be large, obscure, and because everything is a string, might not modify the correct segment of the page code.
  • In HFL, the structure-oriented editing statement to do this would simply look like this:
    • table#pets { tr:all { td:2 {
        if ($text == 'Fluffy') parent {class="highlite" } }}}

  • What this says is: check each second <td> HTML element within each <tr> HTML element of the <table> HTML object that has the id named 'pets', and if its text value is 'Fluffy' set its class to "highlite".
  • Notice that the statement is a combination of a hierarchical version of CSS, with a javascript 'if' statement inside, and an HTML attribute assignment. What will be changed, and what that change will be, should be clear to any web designer and not require strong programming skills. It's intent is clear, and it is terse and readable.
  • Most importantly, it will make the change accurately.

So what does that get you?

It may sound like this is strictly a code-readability issue, or perhaps an ease-of-use issue, but it goes far beyond those.

In HFL, most source files are simple text files that are quite readable, because almost all of the cluttering HTML structure can be left out. HFL scripts can easily construct such structure, and by leaving it out of the source files, different structures and effects can be easily substituted.

Each layout script can be designed to have any number of optional features, and thus can be applied to a very wide range of contexts. A well-designed layout script file, or 'format' can define not just a single effect, but an entire class of simiilar effects. For example, a 'navbar' format could support not just one type of navigation bar, but all kinds of variations. Designers would just invoke the format, and perhaps supply options to specify a particular configuration.

Because formats can call other formats, complex layout effects can be created by combining simpler ones. A unique page-level format can be created by calling component-level formats, who in turn can call element-level formats and special-effect formats. The entire source file for a page can be reduced to just the content to be presented, and a reference to a page-level format file.

Click on the 'Show Page Source' button on the left to see the HFL source code that created this page. Compare it to how this page is displayed. When you wish to close the slide-out page, click on this page again. (This button will be available on all of the pages of this manual.)

Note that the source file contains very little HTML structure. Most of the HTML tags are for highlighting certain ranges of text. All of the rest of the HTML is constructed by the format file of the applyFormat($FMT); statement.

Putting all together:

Why is creating formatting libraries important?

Formatting libraries allow sites to be created that can evolve without a major effort for each change, because the structure and formatting effects are constructed around the content rather than the content being inside of the structure.

Sites that endure need to be able to evolve. The conventions of how sites should work and be used is always changing, often due to changing technologies. An example of this is the conversion of sites to work across many device types, such as PCs, phones and tablets. Entire sites have to be redesigned to work using multi-platform frameworks such as bootstrap. This conversion requires a major effort for most sites. With formatting libraries, it would not. It would be a simple matter of choosing a different format.

Formatting libraries would allow anyone to create attractive and effective websites or web pages, regardless of their skill. And they can automate a large number of construction actions, allowing the source files to be simple and readable.

Currently, creating attractive websites requires skills that are generally beyond the abilities of most website owners. This generally means that to create attractive sites, a site owner must hire a professional. This is not only expensive, but the site owners are often unable to make any significant changes to their own sites without further professional assistance.

With well-designed formatting libraries, it is possible to create attractive sites by selecting a base layout from a list, and then tuning the look by swapping various sub-components to achieve an aesthetically pleasing result.

This concept is not entirely new. Many ISPs offer sample site designs as starting points to new clients. The clients are presented with a palette of different looks, and can choose one as a basis for their site. The clients then substitute their content for the sample content, thus creating their first page.

The problem is that building a site this way locks the site owner into a particular layout and appearance.

A different layout or appearance almost always requires a different HTML structure including different classes and id tags, and then matching CSS and possibly javascript changes. Because the content is embedded within the HTML structure of the site, switching to a different look requires modification of every page. It is usually easier to just start over, and move the content being displayed piece by piece into the new structure. Either way, this is usually a major amount of work.

Even using templates such as those in DreamWeaver® does not solve this problem, because again, the content is still stored inside of the templates themselves. And to go to a different structure involves the same kind of surgery as for single page files.

A better solution would be to apply formatting information to the content, rather than have the content inside of a formatted HTML structure. The application of the formatting information would then build whatever HTML structure, CSS and javascript was needed around the content. And because the content would be separate from the HTML structure, it would be far simpler to later switch or modify appearances and layouts of sites. A new layout definition could build a different structure, without ever having to touch the original content.

Under such a system, the entire look of a site can be easily modified or replaced with a different look later by choosing a different layout definition. This allows sites to adapt to future changes, and opens the possibility that site owners could make changes to their sites themselves, without professional help.

Because the content would not contain superfluous structure, the source files for a page or site can now be clean, very readable and easy for anyone to modify.

This is what HFL is designed to do.

Next: Background