In the preface to my book DOM Scripting, the first of my acknowledgments is a thank you to View Source. Thanks to that one little piece of browser functionality, I was able to learn HTML, CSS and JavaScript.

In these days of RESTful APIs, there are even more sources to be viewed. Whilst deconstructing a message from the oracle of Fielding, Paul gives some straightforward advice on being true to the ideals of , including this:

Above all, don’t kill the bookmarking experience and testing with bog-standard, service-ignorant browsers.

Replace the word “testing” with “viewing source” and that single sentence encapsulates the baseline support I expect from a web browser.

In recent years, the bookmarking aspect has been suffering not through any fault of the browsers but because of overzealous use of Ajax and through the actions of developers using POST when they should be using GET.

Equally worrying, I’ve noticed that the second piece of functionality—viewing source—is also under threat in some circumstances. Here the problem lies with the web browser, specifically Safari. Entering the URL for an RSS file, or following a hypertext reference to an RSS file, will not display the contents of that resource. Instead, Safari attempts to be “smart” and reformats the resource into a nicely presented document.

Now, I understand the reasoning for this. Most people don’t want to be confronted with a page of XML elements. But the problem with Safari’s implementation is that it breaks its own View Source functionality. Viewing source on a reformatted RSS feed in Safari will display the HTML used to present the feed, not the feed itself. Firefox 3 offers a better compromise. Like Safari, it reformats RSS feeds into a readable presentation in the browser. But crucially, if you view source, you will see the original RSS …the source.

I’ll leave you with some writings on the importance of View Source through the ages:

Have you published a response to this? :


Remy Sharp

First off: I’m playing devil’s advocate here, so don’t burn me too much!

View sauce was also my own personal teacher as to acquiring my skills over the last decade. However, the web is changing - or even changed. We don’t use tables for layout, we know better. We also use server side compression and minification to speed the delivery of the payload.

This is where view sauce will suffer (obviously not as badly as if the browser re-interprets the original source). I would, and am, arguing that JavaScript and CSS should be compressed. Even the HTML can be compressed if the site is high profile enough (see But! This all depends on the application.

High/medium performance sites, I believe, should minify, thus mangling the view sauce (though don’t go changing your class names to ‘a’, ‘b’, etc).

Blogs, demos, show off sites should remain uncompressed to allow people to still learn (but you still need to consider your user - and whether compressing helps).

However! There’s one big factor that means we can still learn from compressed CSS + HTML: Firebug. Firebug translates the markup in to a nicely laid out format, and we’re all good to learn again - along with the simple fact that in 2009 client side engineering is a recognised practise - and there’s much more learning resources available.

Those are my thoughts. Roughly :-)

# Posted by Remy Sharp on Saturday, January 31st, 2009 at 2:16pm

Matt Henry

Absolutely. When modern browsers HTML-ify XML feeds, it makes it painful to try poking at a site’s API. Fortunately, there’s always cURL, which is only ever exactly as smart as you want it to be in how it handles HTTP responses.

# Posted by Matt Henry on Saturday, January 31st, 2009 at 3:16pm

Chris Messina

Have you talked to the folks at Apple or on the WebKit team about this (folks like David Hyatt or Maciej)?

Additionally, is this behavior duplicated in Chrome?