A Picture Says A Thousand Words
Source Charts plainly express the most amount of information possible within the current viewport.
Since eyesight is the most efficient way for the human brain to process large amounts of information, visual cues which convey code structure and tag information enables the brain to take in the maximum amount of information in minimal time.
In the screenshot to the left, you can tell immediately how deeply nested the span tag is. You can even tell the types of tags its ancestors are. All without scrolling or reading a single tag.
It's Better Because...
Whitespace is both an inefficient and inaccurate way to navigate the DOM.
When we have to build invisible code boundaries mentally - which always includes some devised series of manual actions (clicking, finding, reading, etc.) - we experience forced breaks in cognitive processing. As the DOM becomes more complex, more productivity is lost. It doesn't take long before mentally navigating the DOM becomes impossible.
Work smart to work hard.
One example of how whitespace fails humans is demonstrated in the Apple February 2014 SSL/TLS bug.
The extra "goto fail" line in the image (left) is indented, implying to a human that it is attached to the preceding if. But in reality, it is not.
This rogue goto was the sole cause of the failure.
Would the bug have been found more quickly if the source charting interface had been applied?
An image of the same code overlaid with a source chart (left) makes it obvious that the goto is outside the scope of the if.
Another article about this bug brings in to question the effectiveness of current code review tools, and is worth a read.
Typical browser "View-Source"
Theatre of the absurd, anyone?
Using View Source Chart bookmarklet (VSCb) is very easy - click the bookmark to launch, and click individual containers to collapse and expand pieces of the page DOM.
Hovering your mouse cursor over any container, even one whose top and bottom are out of view, will display that container's entire opening tag in a tooltip.
This allows you to easily see the opening tag of any container in the viewport.
A lesser known but very useful debugging / inspecting technique
is decreasing the font size (Ctrl + -) to zoom out of the chart. This is useful
when viewing the charts of highly complex pages. Hovering your mouse over a
container will still display the container's opening tag in a normal-sized,
Bookmarklet Demo using Chrome
VSCb's Color-Coding Convention
The color convention is easy to learn and makes scanning the DOM a breeze. You can also use it to debug a web page with a bit of acquired skill.
The bookmarklet is easy to customize if you know CSS. Just paste into an editor and have fun!
Often times, a P tag is involved in a chart anomaly, because the Firefox, Safari, and Chrome browsers do not automatically make a correction when block level elements are mistakenly placed inside a P tag.
Hence, when this type of error has occured, your charts will display container mis-matches or, as seen in the capture to the right, empty-ended containers.
Find the error using the process of elimination: begin collapsing "well" containers nested within this chart manifestation.
As you can see in the capture below, the P tag is not always the culprit.
In this screenshot, the first red flag that something is wrong is that the body tag is out of it's black-dashed-bordered container: a closing div is there instead.
Notice the iframe container: the ending iframe tag is outside its container.
In this case, the easiest way to find a mismatch is by hovering your mouse next to the end tag and comparing it to the opening tag displayed in the tooltip. Here, the tooltip displays an opening div tag, but the container has a closing span tag.
So why would I use other browsers who display charts based on corrected and rendered source code?, You ask. It is because of something I call "Green Code".
What is Green Code?
Green Coding is a method of relying on the client browser to finish building the page for you - something heavy traffic sites do to reduce file size, hence saving bandwidth.
Writing green code is very simple: omit the end tags of certain elements. Because browsers' HTML parsers make corrections to markup, you can omit even end tags that aren't supposed to be optional.
Viewing Source Charts in Chrome, Safari and Firefox will reveal the corrections the browsers have made to the original markup (and the result of script-generated markup). Using VSCb in these browsers is the best way to be sure your page is being parsed exactly as you want it to be.
Chrome - Safari - Firefox
This capture is from a page in which the closing span, td, and tr tags have been commented out. The commented tags are seen, followed by the identical tags the browser replaced them with! Even ending span tags are inserted by the browser, which are not on the end-tag-optional list.
Opera - Internet ExplorerConversely, viewing the same Source Chart in Opera exposes the errors of the missing end tags. The closing span, tr, and td tags are not inserted into the DOM view (though the browser has made the corrections), and as a result, the subsequent tr and td tags appear inside the span tag's container, indicating an error.
Similarly, IE returns many, but not all browser corrections.
The Moral of the StoryVSCb for Opera is a wonderful debugging tool when you want to see your original markup in charted form. VSCb for IE is also a useful debugger.
VSCb for Chrome, Safari and Firefox is vital for Green Coding, or for simply viewing the final stage of your code after the browser gets through with it.
See this Google Webmaster article for more info on optional end tags.