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.

• 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">
      <thead>
        <tr> <td>Type</td> <td>Name</td> <td>Breed</td> </tr>
      </thead>
      <tbody> 
        <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>
      </tbody> 
    </table>
    

• 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">
      <thead>
        <tr> <td>Type</td> <td>Name</td> <td>Breed</td> </tr>
      </thead>
      <tbody> 
        <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>
      </tbody> 
    </table>
    

• 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: