Felix Ritter’s View Formatted Source :
An extension for SeaMonkey and Mozilla browsers
Improvement Upon Efficiency:
Note: This is less a review of the View Formatted Source, Mozilla Extension itself than it is an extended commentary, regarding more closely the very act of debugging source-code with the aid of a utility such as View Formatted Source.
Assuming that you have an appreciation for a source code formatting utility, such as View Formatted Source, by Felix Ritter, I’d like to describe a recent discovery I made regarding View Formatted Source, and the effort of debugging my markup for a missing <div>.
‡View Formatted Source Excels:
Having no extension of the sort installed in my current SeaMonkey profile, an extension came to mind that I could use to chart my HTML Nodes and track down the loneseme Element. The extension I decided to install, though similar to View Formatted Source in that it creates a definitive separation of the HTML Node Hierarchy, takes at least twice the time to arrive at its formatted markup view than Ritter’s V.F.S., likely due to the amount of processing required to create its rather elaborate topographical view, multi-colored Node-block backgrounds, and other visual niceties not necessarily relevant to the location of my lost Element. My plan was halted, however, because the extension is not compatible with SeaMonkey!
Knowing that View Formatted Source is one of the many extensions made compatible with SeaMonkey, by way of Philip Chee’s XSidebar, I visited the unofficial website for information and help on SeaMonkey to locate the proper installer, and initiated the download.
The effort I put into this article should illustrate how pleased I am with V.F.S.. Regarding overall system performance, there is little to no wait-time (P4, 1.4Ghz AMD Athlon, WinXP, 1GB RAM) for V.F.S. to present its Formatted View. Based on my experience, the markup view output by View Formatted Source, structured for viewing by implementation of Code Folding and Text Syntax-Coloring, is easier to read than that of the source charting extension I first attempted to install.
The absolute beauty of View Formatted Source is realized in the Code Folding option. To discover the <div> I suspected was missing from my markup, it took only two attempts at Code Folding with View Formatted Source. Having been much less experienced in web development during the previous affair I had with this extension, upon my revisiting View Formatted Source I realized the great potential for an improvement in my productivity!
I will definitely be using View Formatted Source more often now that I realized this simple, yet quite effective method for locating mis-matched html tags in my markup. Thanks, Felix!
Preface : Code View
[ click ]
Partitions in Formatting
Why do web developers and designers need so many different ways of viewing their source code? What’s the big deal? Why all the cries for pretty-print, language syntax-based multi-colored text? Why are so many different web browser extensions developed to serve the purpose of viewing HTML markup?
It’s true that many people who work with programming source code do prefer a monochromatic, simple text editor (such as Microsoft® Notepad™), but people who work in hypertext markup language tend to recognize a remarkable increase in efficiency, and productivity in general, when the document source code-view is presented in a more rigidly structured manner.
Background : Code Folding
[ click ]
A Rigid Structure
XML and XHTML markup is by its very definition a rigidly structured (requiring that every† element have a specified opening and matching closing tag) language, so it tends to make sense that any viewing of that markup might also be presented in a structured manner. Consider the effect on the author’s work-load, if the effort to locate errors in XHTML markup can be minimized by offering a presentation wherein the relationship between each opening tag and its matched closing tag is made more easily visible.
Method and Madness
As I alluded in the first paragraph, one of the most common methods of structuring HTML markup uses color to separate different sections. This idea of separation is supported by the very requirements for authoring valid markup, set forth by the World Wide Web Consortium. By using different colors of text to represent different sections of the markup elements– essentially the hierarchical structure, naturally assumed by the opening and closing tags, or HTML Element Nodes– it is perfectly reasonable to assume that it will take less effort to locate, identify, and fix any Elements within that markup which may be without a match.
Another method by which a haystack of code is often partitioned into sections to diminish the difficulty in finding the needle is Code Folding‡. You may be familiar with Code Folding as a feature of your favourite text editor. To Fold code is, not unlike a string of paper dolls, to take one end, or closing tag of an Element and to Fold it so that it meets its starting point, or opening tag. Using this method, for example, an Element <p> which is hierarchically beneath, or inside of a <div> Element might be Folded, resulting in the User seeing only the <div> surrounding it, and an indicator such as a plus sign where the entire <p> was once visible. Once the Folded, clicking the plus sign will once again reveal the <p> element in its entirety.
Will Work for FREE
XHTML (and XML) authors are fortunate to have access to FREE services and software specifically engineered to scan the designated SGML markup, either within a local document, or by providing a URL of published material so the service or software might load the appropriate source from its remote location. Typically, such markup Validation Software (or services available on-line, like the credible Markup Validation Service provided by the W3C) will indicate various types of markup errors, including those caused by the omission of opening or closing Element tags (common errors, often due to simple oversight).
When erroneous markup is detected through the use of Validation services, or by software designed to edit and validate markup simultaneously– like CSE HTML Validator for example– the exact line-number where the error occurs is usually indicated so there is no need for the Author to search the document for the error. Feedback about errors, which may read as ‘…element <p> has no closing tag…’ or a ‘…closing <div> has no opening tag…’, for example, can usually be tailed specifically by search criteria, and may report either verbose or concise details in the scan results– often in real-time during the editing process.
Scripting Languages: Client & Server Side
With the relatively recent, incredible resurfacing of client side JavaScript (as Ajax), or perhaps more commonly with a server-side scripting language– like PHP, for example– it’s often not nearly as easy to visualize the HTML node tree, especially when separate documents act as only a partial contributor to the sum of the output HTML sent to the Browser. When scripting contributes to what the User finally views in the Browser, there are often sections of code which are placed into the document, not by hand-coding the sets of opening and closing XHTML Elements and any text between them, but by way of JavaScript events, Server Side “Include” (or require() in PHP), or via database query where, in each case, entire sections of code may or may not exist in the resulting Browser view. Whether such code is present in the markup output is typically determined by each unique user input.
†Some elements both open and close using a single tag, such as the <img> element, which does not have and opening and a closing tag but a single set of < and > symbols where the tag’s Close is indicated by a single forward slash / appearing immediately before the > which ends the “self-closing” tag. Nevertheless, without the forward slash, the markup would be invalid, and would likely not produce the intended results sought by the author.