Background
The original intent of HTML was to be a pure markup language, hence the name HyperText Markup Language. But along the way, HTML stopped being pure markup. A pure markup language should only mark up (or 'tag') the content to be presented, and do nothing else. It is the job of some other layer to define how that content should be presented.
But in the early days of browsers, HTML was interpreted to have semantics, not just be pure markup, mostly to make the code less verbose. Tags such as <B> and <I> were interpreted as directing the browser to do something, such as make the text bold or italic. This trend continued, until a large number of browser behaviors react directly to many of the HTML tags, and take action upon them, such as the <TABLE> tag. Modern web pages rely heavily upon this behavior in order to compose specific looks.
While this may seem to be a moot point, it actually is not. HTML not only tags (marks up) various pieces of content, it also defines the structure around that content. A large number of HTML tags affect the layout of pages (such as the <DIV> and <TABLE> tags) which ties the display structure to the content. This means that to make an overall change to the appearance of a site, one cannot simply swap formatting information. It is usually necessary to restructure every affected page. This gets even messier because in most sites, some of the formatting is controlled by HTML tags, and some by properties.
In later years, CSS was added to allow a fair amount of formatting to be defined outside of the HTML code. But CSS is highly dependent upon the structure of the HTML code. Any change to the HTML requires matching changes to the CSS code. And CSS cannot modify the structure of the HTML DOM.
Javascript was added later, and it is a full programming language. With javascript, one can create pages that could respond interactively with the user, as well as calculate a large number of visual effects. And javascript can create and modify the HTML DOM structure.
Between CSS and javascript, it is now quite possible to define detailed layouts, such as just how bold something is, by assigning the content a class, id or span, and then applying CSS code to it. As a result, formatting tags like <B> are being removed from HTML (deprecated).
But while javascript does permit construction of detailed layouts, it can only do so at run-time. It cannot create the HTML, CSS and javascript source files themselves. And the resultant site definitions are almost always virtually unreadable and incomprehensible without intense study.
How does HFL improve this?
HFL allows you to create your own tags that have semantics (meanings) that you define yourself.
Unlike pure HTML with CSS, an HFL tag can invoke a script that can construct or modify almost any portion of the page or site. This includes copying and constructing files such as CSS and javascript support files.
Because HFL scripts run at compile-time, they can do almost any kind of modification or feature that can be done by javascript, including very detailed layouts.
This allows effects that go far beyond what is possible in HTML with CSS, because HFL tags bound to scripts can construct structure and apply properties. This is something that CSS cannot do.
HFL files can be compiled in an offline step, so that you have all of the flexibility of a programming language, but with no additional runtime overhead when the site is accessed.
Best of all, the HFL syntax includes HTML, CSS and javascript syntax, so the code will be immediately understandable to anyone familiar with these languages. Unlike Python, PhP and other web languages, HFL is not a completely different syntax.
The result is that you can create your own tags, and have them make whatever changes or additions are necessary to create the semantic effect desired, in a language that is very familiar.
Once a tag is defined and its associated HFL code is bound to it, you can just use the tag whereever you need it. The code is clean and simple, as was the original intent of HTML markup.