/ 
Marpa-R2-11.001_000
River stage two • 39 direct dependents • 56 total dependents
/ html_fmt

Name

html_fmt - Reformat HTML, indented according to structure

Synopsis

html_fmt [--avoid-whitespace=[yes|comment|no]]
  [--no-ws-ok-before-end-tag|--no-ws-ok-before-end-tag]
  [--no-ws-ok-after-start-tag|--no-ws-ok-after-start-tag]
  [--added-tag-comment|--no-added-tag-comment]
  [uri|file]

Description

Writes its input to STDOUT, reformatted and indented according to the HTML structure. With no arguments, html_fmt looks for its input on STDIN. If it has an argument that looks like a URI, html_fmt treats that argument as a URI. If it has an argument that does not look like a URI, html_fmt uses that argument as the name of its input file. html_fmt considers its argument to "look like a URI", if it starts with alphanumerics followed by a colon.

When reformatting and indenting, html_fmt takes measures to avoid introducing whitespace that will affect the way in which the HTML displays. The standards differ on whitespace treatment; when the standards agree they often allow considerable latitude to the browsers; and specific implementions will exploit the allowed latitude in different ways, or exceed it. All of which is to say that html_fmt's attempts to avoid introducing whitespace are not always successful.

html_fmt supplies missing start and end tags. If html_fmt cannot find required start and end tags, it supplies them. html_fmt's grammar is very liberal in its interpretation of what is valid HTML. Finally, if this is not sufficient to turn the input into valid HTML, html_fmt will treat problem sections of the input as noise or "cruft", ignoring them in determining the structure of the document. html_fmt never rejects its input, whatever its contents.

When html_fmt adds a missing start tag, it follows the new start tag with a comment. When html_fmt adds a missing end tag, it preceeds the new end tag with a comment. When html_fmt classifies characters as "cruft", it adds a comment to that effect before the "cruft".

pre and script elements receive special treatment. The contents of pre and script elements are not reformatted. When missing tags or cruft occur inside a pre element, the comments to that effect are placed before the <pre> start tag. The contents of script elements are not examined.

Options

No single set of reformatting choices is anywhere near adequate to the variety of standards, renderers and application requirements out there. Ideally, html_fmt would have many options customizing its behavior. As of this writing, there are only a few.

avoid-whitespace

When adding indentation, html_fmt runs the risk of introducing whitespace that will change the way in which the document is displayed. How html_fmt deals with this risk is controlled by the the --avoid-whitespace option, which may take one of three values: yes, no and comment.

If the value of the --avoid-whitespace option is yes, html_fmt does not add indentation in whitespace-sensitive places. This avoids clutter but, because of the missed indentation, the structure of the document becomes harder to follow. yes is the default value.

If the value is comment, HTML (SGML) comments are used to achieve proper indentation without introducing whitespace. This works, but does get a bit cluttered.

If the value is no, html_fmt adds whitespace whenever it is convenient for formatting, regardless of whether or not it may change the way in which the document displays.

added-tag-comment

The --added-tag-comment option is a Boolean. If set, whenever html_fmt supplies a missing start or end tag, html_fmt will include a comment to that effect. If the boolean is unset with --no-added-tag-comment, html_fmt will be silent when supply missing start and end tags. --added-tag-comment is the default.

ws-ok-after-start-tag

The --ws-ok-after-start-tag option is a Boolean. If set, html_fmt will add whitespace after an start tag when that is useful. If the SGML standards are adhered to, the added whitespace will not be rendered. However, the HTML standards, while they allow SGML-adherent behavior for whitespace after start tags, do not require it. In some case in practice, browsers will render whitespace found after start tags.

If --ws-ok-after-start-tag is false, html_fmt will not add whitespace after start tags. But it increases the ability of html_fmt to make its output readable, but may result in a change in what some browsers display.

ws-ok-before-end-tag

The --ws-ok-before-end-tag option is a Boolean. If set, html_fmt will add whitespace before an end tag when that is useful. If the SGML standards are adhered to, the added whitespace will not be rendered. However, the HTML standards, while they allow SGML-adherent behavior for whitespace before end tags, do not require it. In practice, browsers will often render whitespace found before end tags.

If --ws-ok-before-end-tag is false, html_fmt will not add whitespace before end tags. --ws-ok-before-end-tag is false by default. This is always safe, in the sense that it will not change what is there to be rendered. But it limits the ability of html_fmt to make its output readable.

Example

Given this input:

<title>Test page<tr>x<head attr="I am cruft"><p>Final graf

to this command:

html_fmt --avoid-whitespace=comment --ws-ok-before-end-tag

the output is

<html>
  <!-- html_fmt: Preceeding start tag is replacement for a missing one -->
  <head>
    <!-- html_fmt: Preceeding start tag is replacement for a missing one -->
    <title>
      Test page
      <!-- html_fmt: Following end tag is replacement for a missing one -->
    </title>
    <!-- html_fmt: Following end tag is replacement for a missing one -->
  </head><!--
    html_fmt: this comment is to avoid introducing whitespace
  --><body>
    <!-- html_fmt: Preceeding start tag is replacement for a missing one -->
    <table>
      <!-- html_fmt: Preceeding start tag is replacement for a missing one -->
      <tbody>
        <!-- html_fmt: Preceeding start tag is replacement for a missing one -->
        <tr>
          <td>
            <!-- html_fmt: Preceeding start tag is replacement for a missing one -->
            x<!--
              html_fmt: this comment is to avoid introducing whitespace
            --><!-- html_fmt: Next line is cruft --><!--
              html_fmt: this comment is to avoid introducing whitespace
            --><head attr="I am cruft"><!--
              html_fmt: this comment is to avoid introducing whitespace
            --><p>
              Final graf
              <!-- html_fmt: Following end tag is replacement for a missing one -->
            </p>
            <!-- html_fmt: Following end tag is replacement for a missing one -->
          </td>
          <!-- html_fmt: Following end tag is replacement for a missing one -->
        </tr>
        <!-- html_fmt: Following end tag is replacement for a missing one -->
      </tbody>
      <!-- html_fmt: Following end tag is replacement for a missing one -->
    </table>
    <!-- html_fmt: Following end tag is replacement for a missing one -->
  </body>
  <!-- html_fmt: Following end tag is replacement for a missing one -->
</html>

Acknowledgements

The starting template for this code was HTML::TokeParser, by Gisle Aas.

Copyright and License

Copyright 2022 Jeffrey Kegler
This file is part of Marpa::R2.  Marpa::R2 is free software: you can
redistribute it and/or modify it under the terms of the GNU Lesser
General Public License as published by the Free Software Foundation,
either version 3 of the License, or (at your option) any later version.

Marpa::R2 is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser
General Public License along with Marpa::R2.  If not, see
http://www.gnu.org/licenses/.