Andrew's website

Where am I? / Journal / October 2008

Journal entries - November 2008.

11th November 2008

Why do websites look different in different browsers?

A simple answer? Hubris, folly, human frailty, mistakes, greed and then sometimes because they're supposed to.

For a more comprehensive answer we need to get back to the start of the World Wide Web in 1990 at the European Organization for Nuclear Research (CERN), with it's inventor Tim Berners-Lee.

One of the fundamental breakthroughs that Berners-Lee made when designing the original World Wide Web was the marrying together of the Internet with hypertext. What is hypertext? It's the thing you see every time you look at a web page with text and links.

Hypertext did away with the hierarchical nature of the pre-existing Internet when used with another of Berners-Lee's ideas, the Uniform Resource Locator (URL). With URL's everything on the Web has it's own address and can be linked directly. On the World Wide Web, everything could link to to everything.

The hypertext language devised was called HTML. It was simple, clean and rendered text only. To this day, the Web still is essentially a text medium. This was fine whilst the Web was being used by a small essentially academic community. Things changed when in 1993 CERN allowed the Web to go public for free.

The Web grew exponentially, designers and software companies appeared, and everything started to get very, very complicated.

Designers wanted multiple fonts, pictures, colours and complex designs where they could position things perfectly. They started to use markup tags in ways that they were never intended and used "clever" tricks to position elements on the screen, often trying to emulate the design certainties that they had in the print world.

Software companies wanted people to use their software. One of the classic ways to capture market share used by proprietary software companies is what is called lock-in. Give the customer something but implement it in a way that is incompatible with other companies programmes. This is the reason for such things as multiple word processor formats.

We sometimes think of Netscape (stemming from the Mosaic browser) as being at the very start of the Web, but in many ways they were late-comers. The fundamental basis of the Web had already been laid down by Berners-Lee and the World Wide Web Consortium that he founded in 1994. Netscape had to go along with this to a great extent, however, their instincts told them to try to subvert the conventions, try to steal a march on their competitors and grab all-important market share.

Microsoft eventually woke up to the web and wanted the browser market for themselves. Netscape responded and tried to defend their dominant position. One of the casualties of this "browser war" was HTML and cross-browser compatibility. Both sides played fast and loose with the markup, inventing their own tags and rendering pages in the way that suited themselves rather than respecting the previous universality of the Web.

Things eventually got so bad that some people and organisations started to put "best viewed with Netscape" or "best viewed with Internet Explorer" notices on their websites. When Internet Explorer eventually won that first round of the "browser wars" many people simply coded their pages to look good in Internet Explorer.

This was the state of the Web certainly by 2001 when Internet Explorer 6 appeared.

Surely that was a good thing though? Surely we got back to the universality of the Web through the effective monopoly of Internet Explorer?

Well, no. Nothing stays constant and on the Web things can move pretty fast when they get going. The code behind the the websites that were rendering OK in Internet Explorer eventually came to be recognised by more and more people as a disaster. HTML had started out as a clean and simple markup, yet it had been turned by web designers and software companies into an unholy mess.

Things started to change. Netscape, like an zombie that Microsoft thought it had killed, came back from the dead in the form of Mozilla; which was rewritten and eventually became Firefox. Firefox was being developed by people from the Free Software world where standards and interoperability rules. Microsoft after it's victory over Netscape had sat on Internet Explorer and not updated it for years. Firefox was new, modern and gunning for Internet Explorer.

At the same time there was a growing movement of people who were concerned about keeping the Web open and accessible. They had always been there, but now were getting more of a voice with their concerns over issues like cross browser compatibility and access for the blind and partially sighted. This turned into a growing number of web designers who were consciously designing for accessability by using Cascading Style Sheets (CSS), clear document structures and semantic markup. These accessible websites were also perfect for the growing number of devices like mobile phones or a "PDA.

It became clear that unless Microsoft moved then Internet Explorer would simply become superceded. When they started to redevelop Internet Explorer they had two problems. One was the software itself (they had disbanded their Internet Explorer development team years before) and the other was all those websites that would only work in Internet Explorer. Microsoft to it's credit has moved decisively towards the accessible web and cross-browser compatibility in Internet Explorer 7 and the upcoming Internet Explorer 8. The background to that move, though, has been huge pressure from developers and users and the fact that they were now playing catch-up with Firefox and a Web that was moving towards accessability.

However, we still live with the legacy of all this history. Things are getting better with more sites using accessible design techniques, but each of the major browsers still has what is called "quirks mode" to try to cope with all those designers and websites that still use outdated markup and design techniques, or to guess how to render pages that have simply been badly coded.

So, what's the answer to the question "Why do websites look different in different browsers?". Surprisingly, in the end, it's actually an answer alluded to right at the top of this article, "because they're supposed to".

HTML was never meant to be a pixel perfect way of rendering a document and this was the fundamental mistake make by designers and browser makers in the 1990's and early 2000's. Different computers, programmes (including screen readers which use speech to render a webpage), screen sizes and devices should and will display a web page differently according to their setup and users intentions.

Of course there is still the broad commonality of the major web browsers and average computer set-ups with which people commonly browse the web. With modern markup techniques designers can get fairly similar results in the latest versions of graphical browsing software such as Internet Explorer, Firefox, Opera, Safari, Konqueror, or other browsers that use the Webkit, Internet Explorer or Gecko rendering engines.

With modern accessible design, users can now change the colours, layout and fonts of a page completely for their own purposes. For some it seems to be a revolutionary development, but actually it's getting back to the roots of the web, this is the way it was always meant to be.

18th November 2008

Reasons for doing HTML validation

I write my HTML code by hand and being human I make mistakes. Even if you don't always write your HTML directly, mistakes still creep in. Bits of code accidentally get left out, a tag might not be closed, a quotation mark may be left off, or there are just simple typing mistakes. Like a spell-checker, an HTML validator takes my code and makes sure it's "spelt correctly", or more accurately, that it's syntax is correct.

The HTML markup standards are laid down by the World Wide Web Consortium (W3C) and it is their standards that web browsers (graphical, text or speech) try to follow and that a good HTML validator will validate against.

Leaving off a single closing </div> can throw a whole page out of whack. You might spot where the problem is straight away, but an HTML validator will flag it up for you and point out exactly where the problem lies. Add to that the mistakes that some browsers magically fix, though others don't, and you can start to see the real value of an HTML validator.

All of the HTML pages that I write go through this processing, in fact they are checked before they ever leave my computer. It's sensible and easy, you should do it too.

However (there's always a "however"), there are various misconceptions that have grown up about validation. The most prominent is a belief that passing the validation test for your HTML (and CSS) will somehow make your website "accessible" and your code will conform to the latest standards.

Validation does NOT:

These are fallacies, sadly perpetuated by people with good intentions who hope that they've found a quick fix for their coding and website accessability issues. Sorry folks, validating your code is part of the process but there's no easy answer here. You've still got to do the hard sweat and learn stuff for yourselves.

I would add to this the fact that it is still perfectly possible to validate a website against HTML 2, 3 and the old style so-called tag soup of HTML 4.01 Transitional; a potential accessibility nightmare!

NOTE: I'd recommend using HTML 4.01 Strict and looking up how to make accessible websites. A good starting point is the Web Access Initiative at the W3C website:

http://www.w3.org/WAI/

The Web Access Centre on the Royal National Institute for the Blind's (RNIB) website is also very useful:

http://www.rnib.org.uk

In the end, as I mentioned earlier, validating your code is a bit like using a spell-checker or a grammar-checker. Your text may pass with flying colours, but you could still be writing unintelligible nonsense.

OK, lets get down to it. I do it, you should do it, but how is it actually done?

There are a couple of good online validators. The World Wide Web Consortium (W3C) has a validator that can do single pages, or code pasted into a form. Sadly it's only one page at a time so it would be rather cumbersome to use regularly for large websites.

http://validator.w3.org/

The Web Design Group (WDG) have a validator that can do single pages and pasted code like the W3C, but theirs will also trawl a whole website and validate every page it finds. Their validator can be easily installed on GNU/Linux computers through most distribution's package manager. This is what I use on my own computer and it can validate hundreds of offline pages in a few seconds.

The online validator is on the WDG website at:

http://www.htmlhelp.com/tools/validator/

You can also have a go at installing the WDG validator on other systems like Windows or Apple, the instructions are on the WDG website.

Also, have a look at your favourite web editing software, often you'll find that there is a way to validate pages directly in it, or with a plugin. There is also the excellent Web Developer toolbar addon for the Mozilla Firefox web browser that includes quick validation on the W3C site amongst a host of other useful tools.

A last word, to re-iterate. Validating your HTML (and CSS) is good practice. Valid code is far more likely to make a good (and good looking) accessible website than non-valid code, but it is not the whole story.

23rd November 2008

The command line is not a curse.

So often I will read an article, or a comment on some blog, where someone will state emphatically, that Linux (actually they mean GNU/Linux) must get rid of the command line. This is because they say it's too complicated, old fashioned or whatever. They don't understand why anybody would ever want to use a terminal.

It's not their fault. They've been using an operating system where the command line is hidden, in fact there are very, very few programmes that actually use it. Everything for them happens in big graphical programmes and they can't see past that.

I could try to explain why they are wrong at length, but the best way is just to give you a real live example.

Every day I wish to make backups of websites, files and data from my computer and others. Here's what I wish to do.

On a dedicated server (it's in France, so "remote server" is the term) dump data from the MySQL databases and make a reverse incremental backup of them on my computer. From this same dedicated server, make reverse incremental backups of website directories since new images and other media get uploaded there.

Make a reverse incremental backup of the home directory and some other stuff on my desktop computer onto another disk. Make an encrypted copy of the most important data like my .kde directory (settings for my graphical desktop along with email etc.), website data and projects I'm working on onto a USB stick.

Sounds complicated? Well, there are a lot of steps, but I can do it all with one simple command. That's because I've written a bash script (a small text file) that does it all step by step using the actual commands that I would write on the command line.

The GNU operating system is very modular. Each command tends to do one type thing meaning you can combine them in an infinite number of ways to do exactly what you want.

Anybody can write a bash script, it's not programming. This means that you do not always have to try to find some complicated graphical programme that happens by chance (some chance!) to precisely do what you want.

Scripting is only one of the reasons for using the command line. The fact is that not every programme needs a big GUI (Graphical User Environment). For a programme like sitecopy it would be ridiculous. When administrating a remote server a graphical environment is completely superflous and a waste of resources.

So, the command line is not a curse for GNU/Linux users (or BSD users), but extremely useful and vital.

30th November 2008

Don't let the BNP divide our communities

I've just been looking an excellent website set up by Searchlight magazine to counter the lies of the BNP's "Racism cuts both ways" campaign.

I also checked out the BNP's campaign website (I'm not going to promote in search engines etc. it by linking to it here) and it's pretty disgusting. It's full of racist lies and distortions; I'll just mention a single one of their lies here. There are other examples on the Searchlight magazine's website.

The BNP highlight the sad case of a man they name as "Mark Wetherall" and state:

Mark was found, in Whitstable, Kent, with serious injuries and died after five weeks on a life support machine. 18-year-old black youth Curtis Delima and a 15-year-old were later charged with murder and conspiracy to commit burglary.

The BNP refer to the victim of this horrible crime with familiarity, calling him "Mark", but this is where their familiarity ends, since almost every part of what they report, including the man's, name is incorrect.

The mans name was in fact Mark Witherall (notice the "i"), and since one of his assailants names was Curtis Delima, the fascists at BNP headquarters thought they'd found a black bogey man who they could finger for one of their supposed racist murders.

How wrong, a quick search at the BBC news website and it turns out that Curtis Delima is white, along with at least one of the other two convicted for this crime. We don't know anything about the third assailant since he was 16 at the time.

The gutter is the level of the BNP's politics, don't believe their racist lies.

Racism cuts both ways - Don't let the BNP divide our communities

designed with quanta plus Valid HTML 4.01 Strict Valid CSS!