Ten Things You Don't Need to Become a Web Developer

Posted in Article, tagged with careers 31/05/2011 10:03 am

If you are wondering how to become a web developer, or have just started down the road, chances are that you will have come across several factors that you feel may block your entry into the industry.

You may think you don't have the correct equipment, contacts or know-how to become a web development professional. Have you heard people say things like "you need a Mac to develop website properly" or "you must be passionate about design"?

Well, you won't find any of that here. I've been there and come out of the other side with a career in web development.

Clichés are ripe within the web development industry, and they do more harm than good. In an industry where many people contribute their development time for free to open-source projects, it's much better to try to include a wide variety of people, rather than a select few who, to some, may have the cream of the crop equipment or the contacts that money can't buy.

So here is a run down of the things that are not essential to becoming a web developer, viable alternatives to them, and advice to try to get you closer to your goals.

1. Any Apple products

The ubiquitous Apple Mac haunts the portfolio of almost every digital agency. If they're not right there plastered with the agency's work, they're being waved about by the staff or just sneaking in at the edge of an office shot.

No doubt, Mac's are easy to use and aesthetically pleasing, and do lend an air of creativity to a business, but they are expensive, and are certainly not essential to building a website. The computer you are reading this article on is almost certainly powerful enough to build a web site.

I created this site on a PC, with the free tools Notepad++, FileZilla FTP client and XAMPP development environment (for server side programming languages).

2. Any Adobe products

Adobe Photoshop is the industry standard design package for designing websites, and along with Illustrator and Dreamweaver, Adobe's Creative Suite is a very full featured design package. But again, it's expensive, and no web development job means no web development money.

There are some great, free graphic design packages, that, while they might not pack in as many features as other paid for packages, are well up to the job of creating media for the web. GNOME distribute free software, including image manipulation software GIMP and the vector drawing tool Inkscape, and are well worth checking out.

3. An encyclopedic knowledge of everything web

I strongly believe that part of my job is to keep up with current web technologies and standards. Things change so fast that if keeping up isn't one of your priorities, then quite soon you will be less able to deliver the best project work you can.

The flip-side of this is that if you are interested in becoming a web programmer, you will not have to know every technology, every trick and every application - most web developers still don't. Being positive, adaptable and willing to learn will more than make up for gaps in knowledge.

4. An obsession with web standards

This is a contentious one. Without web standards the web would be much worse off than it is today, and future advancement would be hampered without a clear road-map. Web standards are here to stay and will continue to help developers deliver cross-browser web applications.

However, if you have validated your mark-up to W3C standards and find that you have some errors that you can't overcome, don't worry. At the time of writing this article, I checked tumblr.com and amazon.com by the direct input method of the W3C validator and both came back with errors (Amazon had 470!), and people still blog on Tumblr and buy stuff from Amazon.

As an admission, the mark-up of my homepage comes back with one error, due to the tracking code of Google Analytics. If the choice is between obsessing over standards and knowing what's going down on my website, I'll take the latter.

5. A "passion" for design

As a web developer you will no doubt have to do some design at some point, from creating a whole web design to adding a new page following a template, but selling yourself as something you are not is a bad idea, and has the potential to ruin any interview.

Do you really think about design twenty-four hours a day? Or do you have much more specific skills that would be of interest to an employer?

6. Any friends within the industry

When I got my first job as a developer, I didn't know anyone in the industry. I didn't even really know of anyone. I read a few blogs, but I certainly didn't have any contacts.

This is a bad position to be in, but just goes to show that a concerted effort in creating a CV and going through the usual channels of job sites and recruitment consultants pays off (thanks Fiona at Perfect Marketing People!).

7. To be social media genius

I probably had about thirty followers on Twitter at the time of my employment and certainly wasn't going to get a job off any of my mates on Facebook. A social media presence shows that you are digitally inclined and is fully recommended (and come on, it is free), but being a "social media maven" or whatever they call themselves these days certainly isn't necessary.

8. To be top of Google

Again, I don't think my website was anywhere for any good search terms on Google (which has changed recently), but I came number one for my name. Just being findable online is a massive help to any bid getting into a digital career.

9. Expensive hosting

If you are going to take the plunge and create your own, hosted website with your own domain (and I advise you do), you don't need a dedicated server to do it on. You get what you pay for in web hosting, but there are very cheap options for starting out, making it so cheap that you'd be mad not to make your own site.

If you do want a free option, create a blog on Tumblr or Wordpress.com and focus on creating great content.

10. A degree (in computer science)

Degrees are great. They are instant proof that you can be committed to a project and can apply yourself, and will more than likely help you get an interview. But they are not essential for a job as a web dev. I have a degree that is almost completely unrelated to web development (Physics and Philosophy - I did a bit off C++), but this didn't stop me entering the profession. The thing that got me my first job was experience.

The digital creative industries are mostly quite new; there are very few people who can boast 10 years of experience as a web developer (although there certainly are a few). Also, most agencies will want someone who can, at least in part, hit the ground running when they start.

This means that someone with relevant experience, who are relatively rare, will more likely be offered a position than someone without experience - degree or no degree. But how are you supposed to get a job with no experience, and experience with no job?

Bonus! Three Things You Will Need!

1. Experience

As I've already mentioned, making your own site is a great way to gain practice, experience and exposure. A blog is a good place to start, and creating helpful content within a certain niche will help with career focus and SEO within your site.

There are so many free resources online that you should start to teach yourself development as soon as possible. It may seem like a daunting task, but you will be able to put what you have learnt into practice very quickly.

What ever you do, make sure you have an about page with some information about your skills, interests in your spare time and that you are looking for employment, and an easy to find email address so people can get in touch.

2. Experience

If you've created yourself a website, why not create one for someone else? There are plenty of charities that will appreciate someone creating them a website. Chances are you will have to take charity gigs for free, but at your stage of career, experience is worth more than money - you can't buy your way into a job.

You should also ask around your friends and family, and their friends and colleagues. Spread the word that you are prepared to help create a website for someone at a reasonable rate, or just help someone maintain a current website. Getting those URLs on your CV is vital.

3. Experience

Noticing a theme here?

If you've created you own site and got some more experience through charities or friends, why not get involved in an open source project? GitHub is a great network full of people who code collaboratively. If you see a project that is of interest to you, why not fork it and add some extra functionality? Or, you could download a project and create a working demo, with blog posts explaining the finer details as you go.

Whatever you do, make sure you get some experience on your CV. You may hit the jackpot and walk straight into a job from college or university, but if you are struggling, or keep getting passed over for people with more experience, it's time to knuckle down and get some serious coding done!

Oh, and attention to detail is critical. All your hard work may be in vain if you miss a detail as basic as getting a link wrong, so check those URLs on your CV.

And then double check them.

Sloppily typed by Nick Pyett


How To Use The Div Element in HTML5

Posted in Tutorial, tagged with html5, web standards 29/04/2011 9:10 am

Since the days we broke free from tables to structure our web designs, one HTML element has been the most useful and widely used. The div HTML element is almost guaranteed to appear in the markup of any website that has been built to separate content from design and to current web standards. But standards move on; and the future is not looking rosy for the div.

Take a look at the draft specification for HTML5 and there is our old friend the div. But wait, what does that say below?

"Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of the div element instead of more appropriate elements leads to poor accessibility for readers and poor maintainability for authors."

That's right; you're being told (more or less) to stop using the div. There are far more semantic elements to choose from when you are marking-up your content. Are you creating a blog post? Use the article element. Are you adding content that is only partially related to your main content? Use the aside tag. The div tag has no meaning at all, which, when authoring a document, is not helpful at all to the reader.

But it's not the end for the div, as it can still be used to group content. For example:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8" />
  <title>Types of Markup Language</title>
  <link rel="stylesheet" type="text/css" href="did-you-know.css" />
</head>
<body>
<section>
  <hgroup>
    <h1>HTML</h1>
    <h2>Markup for Authoring Web Pages</h2>
  </hgroup>
  <p>You're reading a page made in HTML right now!</p>
  <div class="did-you-know">
    <p>HTML was invented by Tim Berners-Lee (among others), who also helped create HTTP and URL's.</p>
    <p>Tim Berners-Lee now leads the W3C, an organisation that helps develop web standards.</p>
  </div>
</section>
<section>
  <hgroup>
    <h1>XML</h1>
    <h2>Markup for Creating Machine Readable Data</h2>
  </hgroup>
  <p>RSS feeds are an example of commonly used XML.</p>
</section>
</body>
</html>

The div in this example is used to style a part of the document that explains extra facts directly related to the content of the section. (The content is not appropriate for a blockquote, nor is it digressing enough from the section content to use an aside.)

The HTML5 specification goes quite deeply into "sectioning content", or how to hierarchically structure your HTML document. I won't go into it too deeply, but this essentially means a properly sectioned document will break up the document by thematically grouping the content into distinct sections. You can even have more than one h1 element (as many as you need) in one web page.

For properly sectioning content, we can use the section and article elements. If we again look at the HTML5 specification, we find more advice on the div in the section section of the document.

"The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead."

Let's look at another example of how we may use a div. Take the markup below.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8" />
  <title>Types of Markup Language</title>
  <link rel="stylesheet" type="text/css" href="border.css" />
</head>
<body>
<div class="border">
  <section>
    <h1>HTML</h1>
    <p>HTML was invented by Tim Berners-Lee (among others), who also helped create HTTP and URL's.</p>
  </section>
  <section>
    <h1>XML</h1>
    <p>RSS feeds are an example of commonly used XML.</p>
  </section>
  <section>
    <h1>XHTML</h1>
    <p>XHTML was created to be more interoperable with other data formats and is more strict in its syntax than HTML.</p>
  </section>
</div>
<aside>
  <h1>Learn more</h1>
  <p>You can learn more about how to script HTML at <a href="http://htmldog.com/">htmldog.com</a>.</p>
</aside>
</body>
</html>

This is a similar example as before, except this time the sections are much shorter. Imagine we want to create a design of the three sections in a single row (probably by floating them to the left and giving them a width) within a border, with an aside in the same row but floated right. The easiest way to achieve this is by wrapping the sections in a div. I would suggest that it would make no sense to a reader if we used another section element, as we just want to style the section of content, rather than group it thematically.

As a general rule, I would suggest to consider using a div element if the section you are wrapping does not have a header (h1, h2 etc.). This is because headers should be used to title thematic groups and introduce a reader to the section of content. If your section of content does not have a sensible header, then it's probably not a thematic group of content.

(As a quick note, the HTML5 specification is still in its draft stage, so some of this may change in the future.)

Authoring HTML is subjective. In most cases there is no single correct answer. Even the examples I have given here could be marked-up differently and still make sense to a reader, but I hope I have shown you that the div element is still a useful part of HTML that can be used in an effective way to achieve your designs.

Sloppily typed by Nick Pyett


Website Redesign Inspiration

Posted in News, tagged with web design 25/03/2011 1:18 pm

My site has been live for nearly two years now, and so I thought it was time to give it some attention and redesign it. I ply my trade as a web developer, not designer, so was tempted to get someone else to mock up my site, but I like a challenge, and wanted to stamp my own style on my site.

Inspiration

Where to find inspiration? Most design projects will include some sort of brief or branding guidelines, but when you're working on your own projects, you start with a blank canvas. The inspiration for the colour scheme of the site came from my 60's reissue Fender Stratocaster. It's a Mexican copy of an all time classic, but it still has those great strat looks.

Brown and beige aren't exactly sexy colours, but I thought they would work well in contrast with a bright green. Chris Spooner's blog uses beiges, and I really liked this shot on Dribbble by the Dribbble man himself, Dan Cederhorn.

I decided on orange for the link colour, and to keep the main navigation and links very similar to make it clear where the links are on the page.

Layout

The layout of the site is standard for a blog-type site. The most important element to include was the elevator pitch on the home page ("A web developer based in Manchester..." etc.). These are now very common on professionals website's, my last design included one, and they are a great way to communicate what you offer to your visitors. There is a great article from Yoast about summing up your business as succinctly as possible, which explains how an elevator pitch can help your SEO.

Development

I'm a developer so I have to write a bit about the development!

The site is built with HTML5 (I've written a post about how to do that) and a little CSS3. This means that my site will look different in older browsers; the large headers at the top of the pages will not have the text-shadow effect, but I'd rather include the effect for people with up-to-date browsers than use images, or not include the effect at all.

The back end of the site is running on my own PHP framework, and the beginnings of my own CMS. This means that some of the time I could be using writing for the blog ends up being used on actually building it, but its a great learning exercise and interesting to see how much functionality can be included in a CMS.

Now, if I'd got round to building the commenting functionality for blog posts, you'd be able to tell me what you think, but for now you'll have to make do with telling me via Twitter, @npyett.

Sloppily typed by Nick Pyett


Four Things You Need to Make a Site (Work) in HTML5

Posted in Tutorial, tagged with css, hmtl5, javascript, web standards 26/02/2011 10:13 am

This site is made with HTML5, but without a few little extras, the styling and layout would break in all except the most up-to-date browsers. For example, in all versions of IE (except IE 9, which is still currently in beta) the CSS applied to new HTML5 tags would not work, and in Firefox 3.6, the layout would not look the same as in Chrome.

Here is a quick list of things you'll need to get around these problems. None of them are hard to apply, and all the really hard work has been done by other people. Bonus!

1. The New Doctype

From the W3C's working draft of HTML5, finally a doctype you can remember! Without the doctype, certain browsers will enter quirks mode (in order to maintain backwards compatibility for pages designed with standards that are not the W3C's) and you have basically no chance of getting you web page to look right.

<!DOCTYPE html>

2. A Tag Reference

Knowledge is power, and so W3Schools HTML5 tag reference is a good place to start. How you interpret which tag is right for which part of your site is more or less up to you, but remember, the tags are to be used to give semantic meaning or context to the information in your page. Some are more obvious to apply than others.

At this point, you site will probably work with Safari, Opera and Chrome. So yeah, none of the big boys. The next two points include code that you can apply to your page, and are included (with loads of other stuff) in the fantastic HTML5 boilerplate, but if you want a simpler solution you can just include them yourself.

3. A CSS Reset

As mentioned before, even Firefox has trouble with HTML5; the new tags are inline elements by default, so applying display: block to them will fix most of the problems. A good CSS reset will do this and more, and is a great base from which to start coding.

4. The HTML5 Shiv

Now you've got your site working in modern browsers, you need to give IE 6-8 a kick up the backside. These versions of IE do not recognise the new tags at all, and will do all sorts of strange things with them (as they would for any other tag they do not recognise). For this site, IE will decide to push all the content out of the header and into the white content section below. Very annoying.

However, if I include Remy Sharp's (and Jon Neal's, with a little help from Sjoerd Visscher) brilliant HTML5 Shiv (or is it shim?), all my troubles are over. What this does is inform your browser that the world has moved on, and that other versions of HTML have come into being. You're basically having to tell a browser how to do its job, and creating the element in the browser's DOM.

<!--[if lt IE 9]>
<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

All done. Now go! Make a site in HTML5! Or HTML. Or whatever the cool kids are calling it these days.

Sloppily typed by Nick Pyett


I'm Not Dead, I Promise

Posted in News, tagged with 24/02/2011 3:56 pm

Wow, its been ages since I blogged. Look - its been over seven months! That's a capital offence in some circles, and basically SEO suicide. (Or is it?)

But I've not been completely idle. I've been busy on Twitter and keeping up with other blogs. Copyblogger is a great blog and always comes up with interesting posts, Codrops is cool for dev stuff and there are some great UX sites like UX Booth and 52 Weeks of UX. Also check out the Baymard Institute for usability.

The sharper eyed among you will also have noticed I've redesigned my website. But there's also quite a lot of development to it as well. I've been working with CodeIgniter a lot over the past year (making bespoke CMS's, delegate management systems, registration sites, you name it) so I decided to have a stab at building my own PHP framework. Its powering this site at the moment, but is still quite a way off it's first release.

There are still a few more i's to dot and t's to cross on my site, but its coming together. I'll post something soon about the design inspiration. And like I said, I'm not dead.

Sloppily typed by Nick Pyett


How to search Google UK from the address bar in Firefox

Posted in Tutorial, tagged with firefox 26/06/2010 7:53 am

Searching using the default Google search from Firefox's address bar will use Google US, but if you want to change this to Google UK, you can use the following method.

You can edit many of the Firefox's preferences by opening Firefox and typing "about:config" (without the quotes) into the address bar. You will then be greeted by a screen that reads "Hear be dragons!". Click the button that reads "I'll be careful, I promise!" (and make sure you are), and the preferences list will appear. As you can see, there are loads. Type "keyword" into the "Filter:" search field at the top of the page and two preferences will be displayed, "keyword.URL" and "keyword.enabled".

http://www.google.co.uk/search?ie=UTF-8&oe=UTF-8&q=

Firstly, copy the line of text above and then double click on the "keyword.URL" preference. A pop-up box titled "Enter string value" will appear. Paste the text into the input field and click "OK". Next, if the text in the "Value" column of the second preference "keyword.enabled" reads "false", double click on the preference to change it to "true". This will allow the search keyword we just set to be used. With this setting set to "false", any search in the address bar will take you to the closest URL to your search term. You may like this functionality, but the sites you will be taken to will only be in relation to the URL, not in relation to any search engine page-rank or site quality.

Close the "about:config" tab or Firefox itself to close the preferences menu. Other resources on Firefox include my blog post How to view your Firefox bookmarks in a tab and MozillaZine's About:config entries article.

Sloppily typed by Nick Pyett


Google's image replacement technique

Posted in Tutorial, tagged with css, html, seo 03/06/2010 10:50 am

Image replacement is a great technique for anyone wanting to maximise SEO and design on a web page. What with the "do they don't they" question of whether Google penalise pagerank for those using it more or less answered, I thought I'd have a look at how Google do it themselves.

On any Google search results page, you will see their logo at the top left of the page, next to the search box. This image is an image sprite consisting of most of the images used on the page. If we disable images on the page, we are left with a text link back to Google's homepage where Google's logo was. Disabling both styles and images leaves a similar result. Google achieve this with the following HTML.

<h1>
  <a href="http://www.google.com/">
    Google
    <img width="167" height="222" src="nav_logo13.png" alt="" />
  </a>
</h1>

The HTML used is what you'd expect for a text based link, apart from the empty alt text attribute and with the addition of some text reading "Google" between the anchor tags. It is this text that we need to hide (or replace) in order to get the look we need. This is achieved with the following CSS.

h1
{
  font-size: 1em;
  font-weight: normal;
}

h1 a
{
  height: 49px; width: 137px;
  display: block;
  position: relative;
  overflow: hidden;
}

h1 a img
{
  border: 0;
  position: absolute;
  left: 0;
  top: -41px;
}

Let's start with the CSS applied to the image itself. The border property is to remove the default anchor border style. So far, so boring. The position property is more interesting, as it allows us to hide the "Google" text between the anchor tags. Absolutely positioned elements can be positioned with the top, right, bottom and left properties. These properties set the margin (in pixels) between the element and the next parent element with a position property other then the default "static" value.

In our case, the parent element is the anchor. The left property is applied to our image with a value of zero, which means the image will have no left margin in relation to the anchor. As a result of this, the text between the anchor tags is covered by the image. Image replacement complete!

The rest of the styles are only necessary if you are going to use an image sprite. The height, width, display and overflow properties applied to the anchor trim the image so that only the Google logo appear, and the same goes for the top property applied to the image. The font styles applied to the h1 element are to make the text small enough to hide behind the image.

Alt text is used to give context to an image for a screen reader or if images have been disabled by the user. In this case, it is not necessary; the "Google" text between the anchor tags serves this purpose. One criticism you may make of this method is that it generates "double text" if the user has disabled styles but not images, as both the image and text are visible. Please bear that in mind if you would like to implement this method.

If you would like to learn more about the CSS discussed in this article, W3 Schools is a great resource. If you're wondering how on earth I figured out the CSS applied to each element, you need to get Firebug for Firefox in your life!

Sloppily typed by Nick Pyett


How to view your Firefox bookmarks in a tab

Posted in Tutorial, tagged with firefox 14/05/2010 3:02 pm

There are many great add-ons for Firefox (the open-source web browser from Mozilla), some of which allow you to open your bookmarks in a formatted tab. Both Bookmarks Tab and MyBookmarks do this, but if you want something even simpler, copy and paste the following line into Firefox's address bar.

chrome://browser/content/bookmarks/bookmarksPanel.xul

Easy! If you want to be even craftier, you can bookmark the address, right click, choose "Properties", check the box that says "Load this bookmark in the sidebar" and click "Save". You now have a bookmark that will open all your bookmarks as normal when you left-click, or open in them in a new tab when you Ctrl+click or middle-click, just like opening a normal tab window.

Other great Firefox resources include the Basic Bookmarks add-on, a jimmyrcom YouTube tutorial showing you how to speed the browser up with about:config and LifeHacker's guide to FF3.

Sloppily typed by Nick Pyett


No www.

Posted in Article, tagged with seo 23/09/2009 8:30 am

At launch, my homepage joined the ranks of those trying to rid the net of a deprecated convention, and decided against the www.

Why is the www. deprecated? Well, it just isn't necessary, as the people at No-WWW. explain, "Mail servers do not require you to send emails to recipient@mail.domain.com. Likewise, web servers should allow access to their pages though the main domain unless a particular subdomain is required".

So if the www. is deprecated, what are the benefits of not using it? Well, none. The most important thing is that you CHOOSE TO USE IT OR NOT and then stick to it. The problem arises with search engine optimisation, as Canonical SEO explains. A search engine may well list your homepage twice, once with the www. and once without. This is bad for your page rank, because the more inbound links to your site, the higher your rank. With your links potentially being split between two pages, your site will appear lower in search listings.

This problem can easily be remedied, all by adding three lines to your .htaccess file that will direct all the traffic from the www. site to the non-www. site or visa-versa. The .htaccess file is an Apache configuration file located in the root directory of your website. You can edit it through your FTP program. It may be hidden, much like a hidden file on a PC, so go to your FTP program's settings and find and click the box that says "Show hidden files and folders" or similar.

To always remove the www. add this.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L] 

To always use the www. add this after changing "example.com" to your own URL.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

Whether you choose www. or not is up to you. But, answer me this. When was the last time you said the www. whilst discussing a website? Or saw it on an ad? Or typed it into your browser? Without it, devilishly clever URLs have been created, such as http://del.icio.us and http://tr.im. And don't forget, www is the most inefficient abbreviation ever. It has three times the syllables (nine) than the phrase it is an acronym of (three).

Sloppily typed by Nick Pyett


Click to suit your screen

Posted in Tutorial, tagged with css, javascript 25/06/2009 1:05 pm

Fixed and variable width CSS layouts both have their strengths and weaknesses, and have each been adopted widely, but there is a third way.

Paul Sowdens's "style-switcher" article on A List Apart describes (with a little help from PPK) how to use alternate style sheets and Javascript to let a user switch between the style sheets applied to a web page. The most widely known use of this technique is probably Wired.com's text size widget, where by clicking on a smaller or larger text icon changes the size of the article text.

As the style-switcher technique allows us to switch between whole style sheets, it is not just the text size a user can be allowed to adjust. By the same token, whatever styles we put into our alternate style sheet will override the styles set out in the persistent or preferred style sheets, when enabled by the Javascript (as long as they are put in order to cascade properly).

We can now set up multiple alternate style sheets, each with different styles applied, and the user change between them. My homepage is styled with a fixed width of 800px, but a user can click on the links at the top of the right column to change this width to suit their screen, be it a portable device, wide screen or standard.

This approach overcomes the two main issues associated with fixed width layouts, namely, that either they are too wide for your screen and necessitate horizontal scrolling, or, that they look lost in a sea of emptiness on your snazzy high-res screen. It also does not suffer the problem often criticized of variable width solutions; that they can produce paragraph widths too wide as to be comfortable to read. The widths can be chosen and tested before anyone applies them.

And I know what some of you will say before you say it: "If you're using Javascript anyway, why not just use the screen.width property and match the page width with that?" Good point, but this is just another way of producing a variable width layout. Admittedly, you could then use Javascript to choose between alternate style sheets, but we don't want Javascript to choose the width of our page - we can do that for ourselves.

There is no reason, however, that one of these methods should not be available to the user, or even set as default. We could have a standard width for the page, for example, and a "match my screen size" button for those who felt the standard width was not appropriate for their screens. What I am proposing is that users should have the choice over how best to view content in their own browsers.

Sloppily typed by Nick Pyett