View source has a posse
Jul 22, 2009 In Web Culture By Chris MessinaView Source demands a place in a web application’s interface, equally accessible to developers and hobbyists of all levels of expertise, because it is a feature for everybody — not just for experts. Even if it’s technically advanced, it’s an essential part of the interface as the first entry point for so many people in understanding the way the web works. The tradition of View Source is essential for preserving transparency, spreading knowledge, techniques, and emerging practices for these modern applications built with HTML5, CSS3, and JavaScript. Wherever possible, we must intentionally include the facility to view the source of an application. It should be obvious by now: View Source has a posse the size of the entire web.
Imagine that you were charged with designing a browser from the ground up. Imagine the benefit of 20 years’ hindsight to help you develop the best browser the web has yet seen. Where would you begin?
After years of dormancy, the browser market is once again heating up with competition among several new contenders, many of which are open source. Jockeying alongside popular browsers like Chrome, Safari, Firefox, Internet Explorer, and Opera are a new breed of hybrid application frameworks like Silverlight and Air that are built on browser technologies, but shed many of the traditions of the web because they require proprietary extensions, platforms, and costly tools. These hybrid models defy the basic premise of the transparency and universality that has made the web the most powerful ecosystem ever created by man.
One unsung element that has widened the reach and inspired a generation of web builders is a tiny little menu command called View Source.
View Source lets you, as a user, view the source code of every web page. Importantly, this lets people peek behind the scenes to see how web applications work; and because of this, people can copy this code into their preferred text editor (bundled with their favorite operating system), make a few tweaks, save it in HTML format, and view changes instantly, without a complicated or heavy development environment. People can change code at the level of a single paragraph tag, or splice together whole portions of web pages from different sites. This light-weight development methodology single-handedly distributes the power of the web.
Lest we devolve into an argument about property and copy rights, let us consider the benefits of the "View Source" model:
- View Source provides a cheap and easy way to view web code. It lets users inspect applications in ways that desktop applications typically do not. But it’s especially important that View Source is directly available in the browser interface, one-click away. After that, all you need is a text editor.
- As a result, everyone can learn from everyone else without having to ask for explicit permission. This gives the web a great deal of forward momentum by baking in a competitive model that favors initiative, iterative improvement, elegance, and solid design thinking (since you’re always looking to do something a bit cooler — more easily — than your competitors).
- View Source is vital to the building blocks of the web — HTML, CSS, and JavaScript — that are free to use and implement. Their continued development is overseen by the W3C standards body, rather than by any individual company. This is important because it provides an indispensable alternative to proprietary formats as new and improved browsers are released.
- Transparent data formats help to maintain the longevity of information. Having direct access to source code reduces your reliance on secondary technologies to parse or read it. Put another way, HTML documents that were created in 1999 are just as readable in 2009.
The point is that View Source is more than a vestigial organ of the internet; it provides more than just access to the guts of a webpage.
So how do Silverlight and Air handle the View Source feature? Well, they don’t, at least by default. As hybrid application frameworks, they bury or obfuscate the source viewing options, in exchange for simplicity and control.
Now, technically speaking accessing source code is still available under some circumstances. Air app developers can choose to include a special JavaScript file called AIRSourceViewer.js to make it possible to view the HTML and JavaScript content of their application. Silverlight requires secondary applications like Silverlight Spy or an add-in like Reflector Silverlight Browser to get at the source of an application. But these do not come standard, and both require Internet Explorer (and therefore Windows).
Remember, the value of View Source is that it is directly available in the browser interface, one-click away; these hybrid models violate this pattern. As a result, they inhibit peer-to-peer learning. They encumber technologies that are otherwise free to use and implement (e.g., if IE is the required development platform, they are not completely FREE); and by obscuring the inner workings of web applications, they sacrifice the transparency and universality that has contributed to the web’s success.
Even Google’s Chrome browser has relegated the View Source command to a developer sub-menu. Taking into consideration the omission of this functionality in Silverlight and Air, might this be suggestive of an overall industry trend?
Why should anybody care? Well, because View Source should not be turned into an expert feature! View Source demands a place in a web application’s interface, equally accessible to developers and hobbyists of all levels of expertise, because it is a feature for everybody — not just for experts. Even if it’s technically advanced, it’s an essential part of the interface as the first entry point for so many people in understanding the way the web works.
Looking forward, as the web plays an increasingly critical role in society, we will need increasingly complicated applications. However, the tradition of View Source is essential for preserving transparency, spreading knowledge, techniques, and emerging practices for these modern applications built with HTML5, CSS3, and JavaScript. Wherever possible, we must intentionally include the facility to view the source of an application, which begets the question: who should address the omission of this functionality in platforms like Silverlight and Air? It should be obvious by now: View Source has a posse the size of the entire web.



Follow the Conversation
11 Comments so far. You should leave one, too.
I use Chrome all the time and I never noticed that. You are right. Its under Developer menu is a hassle to click! But at least you can still right-click in the page to get view source easier than IE or Firefox.
Excellent write, Chris. I think Chrome’s relegation of the feature isn’t so much an industry trend, but a UI consideration: it’s obvious that the designers of Chrome have really fought to cut everything out they found secondary to browsing. However, I fully agree (and despise) that Flash and other proprietary plugins like Silverlight are very opaque.
@Eeyore – My Firefox has “View page source” right in the context menu, just like (I assume) Chrome does. Not sure how one is faster/slower than the other. Beside that, though, why use the mouse? Keyboard shortcuts will be faster than context or application menus.
I agree that we need to keep View Source easily accessible. I know I use it all the time, even as a professional web developer, to learn new tricks. I really wish, actually, that View Source could be expanded/enhanced to include Javascript and CSS as the browser interprets it, that way you get the full view of a site and not just the markup, ‘cause, really, in this day and age, markup alone doesn’t get you much.
Chrome and Safari 4 have “inspect element” in the context menu, which is used much more often. When you click it, you’re thrown right into a dynamic view of the DOM, where you can view the properties of the element you clicked on, view the area taken up by other elements in the DOM, and alter DOM elements and certain kinds of CSS rules. You can also see scripting errors, MIME-type errors, and a load-time (or filesize) waterfall for the page.
(It’s all working in Safari 4, but Chrome has a buggy, slightly-cut-down version. They had better get it working, soon.)
As for Air, I got annoyed the other day that I couldn’t view the source. I’ve become used to seeing what goes where, and it seems TweetDeck has nothing but text selection in its right-click menu. There’s no menubar, even if you press ALT (something that works in IE7/8 and Live, which is one thing I liked about them), and the options of the program itself are fairly general.
(Oh, Chrome has View Source in the context menu, too! I never noticed that.)
(It also has View Page Info, which verifies Identity, looks for an encrypted connection, and checks my first visit.)
I find myself using Viewsource more frequently to check my own site than to look at others unless I want to find a template reference or something like that. I prefer Firefox to IE because the source is more organized. I am still avoiding Chrome because I use too many Firefox Plugins. Will be interesting to see what happens in round two when the Google/Firefox agreement comes up again.
I admire people like you who take the time to do all this research and then to share the results with others. Due to time constraints I will have to come back and read all the articles you have linked to.
Thanks for the share.
I wouldn’t call this research, seems like opinion to me. There is a huge assumption that developers want to share their source. If the user experience or a proprietary algorithm [that makes the most sense on the client side] in your application gives you a competitive edge I don’t see why you would want to let the competition see the HTML and JavaScript source for it. It is analogous to Google exposing their search algorithm.
I’m sure view source is good for the “posse” but it does not give a developer any control over what is viewable and what is not.
My opinion is that spam bots (as an example) would have a much more difficult time on the web if sources weren’t exposed since more code security could be involved.
Hi Chris,
Interesting article overall. Your points of view about view source make a lot sense and I agree it’s behind the explosion of the web both in a good and in a bad sense because it fosters mindless copy and paste patterns that sometimes lead to poorly designed and poorly crafted websites which ends up lending a less than optimal reputation to the web.
As a professional web developer, there’s another thing that bothers me about view source: I spend a lot of my time writing code. Time that I would rather spend with my family and friends. I regard the code I write as a result of my own effort and a product of my work and, although I’m a very giving sort of person that ends up publishing most of the code I write (my own, not my employer’s ;) ), I like to, at least, choose when and how to do it.
There’s another thing about your article that confuses me: Why do you compare Silverlight and AIR with the Open Web. You should be comparing Silverlight and Flash/Flex (which, by the way, has a cross-browser, cross-platform, view source feature that the developer may choose to use).
I must respectfully disagree with this article. Particularly the statement, “View Source should not be turned into an expert feature!” Only people who are trying to do development—even really, uber-simple, lightweight, development—need to access View Source.
It’s 2010 and something special has happened since ten years ago. Practically everyone surfs the web now. It’s hard to believe it, but there used to be big front-page Tech News section articles in the newspaper that kept going over the fact that “now a whopping one in four people in the U.S. have accessed the Internet”.
The people who surf web sites now are extremely rarely going to want access to developer functionality such as View Source. This functionality is treated as advanced features because that’s exactly what it is—it’s a feature that is reserved for us, the advanced users of the web browser. Most users don’t do anything in a web browser except use the Address bar, the Back button, and Print. That’s really all they need.
For the rest of us, it’s all still there.
Regarding Silverlight and Flash not having View Source, that’s a good thing, too. It is in the content author’s right to try to do what they can to keep their secrets. That is a debate we will never agree on, needless to say if I invent something delightfully unique in a user interface, I want the credit for it. Some of it is worth sharing, but having what makes me unique kept unique to me is part of what drives me as a developer. We all want to feel like we’ve contributed something special. We all have egos. I am not Chinese; as far as I’m concerned, everyone does not own everyone else’s ideas, and I’ll fight to the end any attempt to make things that way.
Hi Jon, I think you raise some good points. Even after the Web started to take off, there was a sort of dichotomy between folks on the Web versus folks on AOL or CompuServe. That has changed, supporting your point about many users not caring. And there is certainly a niche demand for things like code obfuscators and DRM that will always be there.
Still, though, I believe the inclusion of “view source” was pretty revolutionary, and embodies the philosophy of the Web. The Web was never supposed to be a place where a small cadre of priests produced content that the masses of plebes would consume passively. The idea of “universal access” was baked into the very architecture of theWeb; from the use of markup to the use of URIs. It’s why W3C insisted on royalty-free, and why accessibility for people with disabilities has been a key feature from the start. We all take it for granted now, so it’s easy to forget how tremendously different this was about the Web — and it was this way on purpose. It was the primary underlying philosophy of the Web; far more so than the other things like “open source” or whatever.
Of course, you can argue that we missed the target on the “universal access” goal, and in many ways that is true. But I would prefer to keep the original ideals in mind and always strive to reform toward them, rather than toss them out in the name of progress. Wouldn’t it be better to have as close to universal access as possible, with as many people as possible empowered to create pages, and then offer the “black box” or obfuscation as an option only for people who really wanted it?