`View Source...` as seen in the Internet Explorer 8 on Windows XP.

Because, of course, we “built” websites back then…

Funny how terms are just naturally used and then dropped over time, with the people using them casually behaving like they’d never said it before. Build websites? Kinda true, but not really accurate when you observe what goes into actually creating the site these days…

It was an exciting time for my friend and I – we were quite uninterested in a lot that happened at our small high school, and learning how the ‘guts’ of websites worked was something that just felt right to us, and was something we had a mutual and instant passion for.

Why “View Source…”? What’s the attraction point?

“View Source…” was/is a feature in Internet Explorer and Netscape Navigator that allowed people to literally ‘view the source code’ of the website they were browsing. Now, the reason for it being included as standard in publicly consumed web browsers I don’t know, but I do know that it was probably one of the biggest catalysts for a number of people getting into coding for web, and continues to be so today.

When faced with a Web page whose layout or technique seems particularly worth emulating or even copying outright, the question “How did they do that?” can be answered in seconds.

Shirky, Clay “Shirky.com” http://www.shirky.com/writings/view_source.html 1998.

So why discuss this now?

It appears that there’s movement in the camps. There are some that believe that the “View Source…” feature, and indeed many child technologies built upon the same premise, is either defunct and useless or should be removed altogether to ‘protect’ the source code of websites, effectively closing up the web.

There are others that believe that “View Source…” is not useful at all and actually hinders the design process. I disagree, and am going to explore this through my own personal experience. I won’t be giving such technical explanations as some have, but rather from the view of a designer who is still relatively new to all of the techniques employed by people around the place and who still finds “View Source…” a valuable tool to have in one’s repertoire…

First-things-first – Troubleshooting 101

For those who are just starting out constructing websites, it’s unlikely you’ll be familiar or have any idea how to use such tools as Firebug and the Web Inspector, so you’ll most likely be working with a text editor of some sort.

Personally? I started out using Windows Notepad and Internet Explorer. Now it’s a little different as I have a wonderful colour system for my coding in Dreamweaver (never use “Design View”!!!) and Firebug helps to view my live code as I work when something just doesn’t want to give.

I recently read a post by Alex Russell about “View Source…” and how it is still relevant to him and his design practices. He agrees that there’s no quicker way to see the results of your tweaks to a site design than by using two simple tools.

Quote from Alex Russell about Required Tools...

Using “View Source…” today

From my point-of-view, the BIG difference between using Firebug and “View Source…” is the fact that I get to see all of the page code, or only inspect what code I can see on the screen.

The first step I take if I want to peek under the “hood” of a site that I like is to right click and select “View Source…” (or View Page Source as it is in Firefox…). This brings up the entire source markup in a separate window for me to examine and explore.

Few things are more exciting to me than finding a really sexy web design and having the chance to learn how they’ve done some of the things they’ve done.

The biggest drawback to either of these methods, for me at least, is the fact that you cannot “view” the back-end coding, (ie. PHP, Rails, etc.) in an active / interactive way like you can with HTML. Learning back-end code is infinitely harder for me without the ability to use “View Source…” to learn how to construct the document.

The other thing I use “View Source…” for, and cannot use Firebug for, is collecting the “address” or URI of the jQuery plugins and CSS files used on the page so I can then view those code sets as well and learn how things were constructed.

It used to be that I would “save” a web page and all associated files would download and be placed in a folder called “example webpage_files” or something to that effect. But it seems to leave out things like the jQuery plugins because they’re not deemed “essential” to the construction and delivery of the page in the browser.

So, I manually save each attached file and play with the source code, one at a time or all together to get different effects happening. This is how I’ve advanced from some shmuck with grandiose dreams of working as a web designer to someone who might actually be able to do it professionally within the year!

Taking over an established site

I cannot stress enough the importance of viewing the source code of a site you’ve been asked to work on before accepting the job.

Developing strong work standards and a stable and clean system for coding your designs is a great thing, but can put you at risk of becoming fastidious about how you lay out your code.

I have a mild OCD when it comes to certain things – lining up pens and paper on my desk to parallel or forty-five degree angles, etc. – and it has begun to creep into my work when writing code.

Evil Code Vs. Good Code - which is which, to you?

I use camelCase, multiple lines and indentation for selectors within properties and their children. (see here for example). It’s what works for me, and I understand that some don’t feel the same way.

But to illustrate my point, the above featured image shows code on the left that I find all too often in the source of site that I thought would have wanted to promote a little more readability in their code…

The one thing I haven’t gotten the hang of yet is fully commenting my designs – it always distracts me from the progress I’m making as I code, and so often forget to do it, or at least go back and do it later. “View Source…” reveals this when you look at the code of my page. (If you opened my CSS file for this blog, and went right to the bottom, you’d find all my additions in there with no real structure because I didn’t take the time to put the code in the correct spot provided by the original author of the code.)

Learning what one thing does is a step towards learning how to code!

This demonstrates the process of how I find something I like and want to learn, so I use View Source...

When I started my obsession with learning to code for the web, I started with “View Source…” and my best friend. Between the two of us, we had a working understanding of HTML and basic CSS and javascript awareness within a couple of months.

Living together again after over a decade since we first started out on this path, we’re both launching our first professional sites for something more than shits-and-giggles. The best thing about this is that we’re back to helping each other with code again.

In the time that he had between classes at uni, while I was at work, he got his head around more PHP than I’ve had an opportunity to even read, let alone experiment with – and I’ve got a slightly better grasp on CSS and how it interacts with HTML than he does. It’s a great asset having each other around.

…view-source helps turn the entire web into a giant learning lab, and one that’s remarkably resilient to error and experimentation. See an interesting technique or layout? No one can tell you “no” to figuring out how it was done. Copy some of it, paste it into your document, and you’ll get something out the other side.

Russell, Alex “Infrequently Noted” http://alex.dojotoolkit.org/2010/01/view-source-is-good-discuss/ 2010.

But I digress. Learning to code is as simple as viewing the source code of the page you’re looking at, finding the text that’s displayed in a certain area, and then looking at the bracketed-properties that surround said text. Rinse. Repeat.

Copy a whole chunk of code, and the corresponding CSS details, and paste it into your own code. Tweak it a little and save your changes. Press “CTRL / CMND + R” or F5 and watch the changes refresh on your page as you work – simple! If you completely break something, (as is bound to happen at some stage), simply click undo. If you’ve gone one step too far and rendered your page FUBAR, then just delete it all and start again. Go back to the source code, copy-paste-tweak-save-refresh.

With patience and a decent level of concentration, you’ll be churning out HTML markup in next-to no time!

A note before I leave…

Save View Source!

Thomas Bradley, whom I found through Alex Russell’s blog post, recently started a web site called “Save View Source” – http://saveviewsource.org/

If you feel the same as I do, that the “View Source…” feature is an invaluable tool for designers, especially n00bs like me, to learn how to code, then please visit his page and spread the word.

Further reading

I’d like to recommend a couple of discussions that bring up other points I’ve overlooked on purpose as I didn’t really have the time or energy to express my opinions about them – either that, or these guys are way smarter than I am and can talk geek a lot better and I found their discussions much more entertaining than my fumbling ramblings.

View-Source Is Good? Discuss. – by Alex Russell
http://alex.dojotoolkit.org/2010/01/view-source-is-good-discuss/

Save View Source – by Thomas Bradley
http://thomasjbradley.ca/blog/save-view-source

The End of Days for “View Source”? – by Michael Mahemoff on Ajaxian
http://ajaxian.com/archives/the-end-of-days-for-view-source

View source; How important was it, is it, and will it be? – by Alex Russell again on Ajaxian
http://ajaxian.com/archives/view-source-how-important-was-it-is-it-and-will-it-be