More than fifteen years after the internet began to be a mass-market experience there are no longer any excuses for links that don't work, or pages that do not have titles.

 Yet in a recent survey of the top 500 FTSE companies, Sitemorse still found well over two per cent of web pages that did not have a title, and well over 3 per cent failing basic functional tests.

 Since a company's website is the first port of call for virtually all users nowadays, missing images and poor links can give a poor initial impression. After all, if an organisation's  website is put together in a slapdash fashion, what does that say about the business itself? 

Google and other search engines may not properly catalogue or index a site that contains HTML errors, and that can mean less users finding what they are looking for - and in the case of e-commerce sites, perhaps a failure of sales and the consequential hit to the company's bottom line. 

Around a quarter of users, according to recent research, will duck out of an online sale because of technical issues. A massive 82% of consumers said that if a business' website performed badly it would dissuade them from buying goods from that organisation on the web - or even in- store.

Yet recent Sitemorse benchmarks show many online retailers either do not know, or choose to ignore this, with some of the best-known high street names performing very badly on quality issues.

There have been numerous, on-going discussions about whether Microsoft .Net code is Standards compliant or not.  We took part in subsequent discussions after this dialog between one of our Customers - the National Audit Office - and the W3C.

http://lists.w3.org/Archives/Public/www-validator/2010May/0028.html

In the discussions with the W3C following the dialog we got several different reactions from "ah yes looks like our validator is wrong not to highlight these errors" to "no we're absolutely correct in everything we do if you reference Appendix C and Addendum x and subsection something or other......." (this last one is somewhat paraphrased I have to admit).

What we have agreed on is (and this is essentially what the link says) that tags such as id="__VIEWSTATE" are OK if the page is declared as XHTML in the DOCTYPE but NOT if it's declared as HTML.

This changes to the Sitemorse engine were implemented late afternoon on Thursday 11th November 2010.  Audits running AFTER this will use these new rules.

Sitemorse reported these errors in the Code quality section of the Audit reports under the Badvalue error.  .Net users should, from now on, see a reduction in the number of Code quality errors reported, with a proportionate rise in their Code Quality score.

The comments in the link point out that, say, id="__VIEWSTATE" shouldn't cause modern browsers a problem, which is probably true in most cases.  But that isn't the purpose of Sitemorse.  It isn't possible to know just what all browser will do under different circumstances and combination of circumstances.  And as new versions are released they become more "standards compliant" i.e. LESS tolerant of non-standard code (hence IE's compatibility button).  So we tell you about everything that's wrong so that you can make a judgement on whether to correct the code. 

Looking at the results of this years Client Survey it appears that Code Quality is not as high up the priority list as it perhaps should be. It's not always obvious just what the implications can be if you don't keep on top of these errors.

When I'm running training sessions and discuss Code Quality I point out that although there is a W3C standard for HTML that browser must abide by, there is no standard for what the browsers should do when they come across non-standard code. Should they ignore it or assume you meant something else ?

The discrepancies between what browsers do under these circumstances is one of the factors that lead to Webpages not rendering in the different browsers - and there's a proliferation of browsers out there especially with the increase in browsers on mobile devices. With all these browsers out there it's becoming more and more difficult to ensure that your Webpages work across all browsers.

A key way to help with this, though it's not the only thing, is to ensure that all of your code is compliant with the W3C standard.

I came across an example yesterday of a Webpage that was completely jumbled by IE8 (including when I tried viewing the screen in "compatibility mode") yet when I viewed it in Firefox it was fine. It was a real simple coding error where they'd try to put a couple of words in the Meta Description in double quotes.  This made all of the words after the first double quote (double quote is the delimiter for the Description) to be treated as Attributes, which meant they were all errors.

Here's what it looks like:

Clearly something that would have been spotted if the editor had viewed it in IE.

If they'd have checked the page with Snapshot they'd have had the error clearly pointed out to them both in the Page View and the Source View ==>

In the early days of XHTML many sites had problems where code was declared as HTML or XHTML when in fact there was a mixture of the two in both cases.  If Sitemorse had reported every infringement then most sites would have been reported as having thousands of errors under the Code Quality category and people would have felt overwhelmed by the volume of errors we were reporting.  As most browsers coped well with these errors and rendered the pages OK we didn't want to be in a position where either people gave up on Code Quality or were spending ages clearing problems that had no real impact on their sites.  With the volume of errors that would have been reported there was a definite possibility of being in a situation where people "couldn't see the wood for the trees."

We've kept an eye on this and now feel we can be more picky about the differences between HTML and XHTML.  Having previously been fairly relaxed about the use of XHTML features in HTML, and vice versa, we're now making a proper distinction between the two as most sites seem to have got the distinction correct nowadays.

An example of what might typically come up in reports is to do with "empty" tags, e.g. "<br>". These tags do not contain any content, and in HTML they should not have close-tags. In XHTML, all tags should have close-tags, so they must be written "<br />".

So in short:
HTML: <br>
XHTML: <br />

Other tags that this issue often crops up with include, for example, <link>, <meta>, <img>, <input> and <hr>.

The bottom line is if you declare that the code is HTML make sure it is, likewise for XHTML.

Anchor Points or Fragment Identifiers are used extensively to take users to particular parts of a Webpage.  A classic example of this being a site's FAQs page where you'd have a list of clickable FAQs at the top of the page that, when clicked, take you to the full text of the question and the answer which are either lower down the same page or perhaps are part of another page.

The problem comes when these are coded incorrectly or the page changes and the links no longer reflect what's actually on the target page.

Examples:

1. A clickable FAQ entry points to a Fragment Identifier called Q10 which should be located further down the page but Q10 doesn't exist. 
2. A clickable FAQ entry points to a Fragment Identifier called Q10 but there are TWO (or more) Q10s

These errors will be reported under Code Quality under the Unknownid for the first example and under the Bad value item for the second.  We added them to the Code Quality category as these types of error won't cause a failure in the same way as, say, a broken link would (though there are similarities) they just won't work as you intended them to.  For instance if you click on one of the clickable FAQs in the example and no Q10 Identifier exists the Webpage would remain in exactly the same place.  Or in the case of duplicate Q10 Identifiers the browser will take you to the FIRST instance of Q10 which may or may not be correct.

Fragment Identifiers may also be used by a site's Style Sheets (CSS) or by JavaScript on the site.  Again missing or duplicated Identifiers will cause unpredictable and, therefore, undesirable results.

Some sites will see these new checks impact their Code Quality score when they've made limited unrelated changes.  It's important that we extend the checks we do to identify issues on your websites.  The side effect of this could be that we find you more problems to fix but all of the issues we raise could be impacting the visitors to your site. 

I've blogged earlier about IE 8 and how it might impact you as it gets out into the wild.  http://blog.sitemorse.com/2008/06/ie8-standards-compliance-issue.html and generally on the subject of browser compatibility here http://blog.sitemorse.com/sitemorse-features/code-quality/.

Now that the RC is available reality is getting closer and there's less time to get all that testing done.  Recent analysis shows IE 8 having a 1.16% share of connections which puts it well above Opera.

There are some interesting features in the RC that point the finger at looming issues of compatibility,  On the tool-bar, next to the URL box and the GO and Refresh buttons is a new button that appears when IE 8 identifies that a rendering issue has occurred.  Called Compatibility View it's a toggle button it forces a change of rendering engine from IE 8 to IE 7 to keep the page looking as it should.  The user can also add pages into a compatibility list so that IE 8 will then know in the future which rendering engine to use for that page.

There are two worrying aspects to this in my opinion. 

1. It assumes that when faced with a page that is messed up a punter will look around and find the Compatibility View button and click it rather than just abandon the site as they've always done in the past
2. If Microsoft deemed it necessary to build in this capability then they are expecting rendering issues to be a frequent occurrence rather than just an occasional nuisance

So you need to get testing with the RC version now that it's available.

As I often mention at this stage in conversations on the subject - a good starting point in this is to check your Code Quality page on you latest Sitemorse audit and clear up the errors identified and then start manually testing with IE 8 installed.

I found this item at e-Consultancy that confirms what Sitemorse have found over several years now.  Websites are rarely HTML Standards compliant.

Last week, Opera released the results of a survey conducted using its MAMA (Metadata Analysis and Mining Application) search engine.

The engine, which currently indexes 3.5m web pages, is designed to track "how web pages are structured."

One of the key results from the survey was the fact that only 4.13% of the URLs MAMA indexed were validated using the W3C markup validator and only approximately 50% of websites displaying the W3C validation badges actually passed W3C validation.

Just to reiterate WHY having HTML/XHTML and CSS code that is compliant with standards is important for the following reasons:

• It increases the likelihood that visitors using different browsers are still seeing your website as you intended it to be seen.
   
• It increases the likelihood that visitors accessing your website using  devices other than a PC will be able to access it successfully. Don't forget that a significant number of people access the internet through portable devices, for instance!
   
• It helps those with disabilities access your website.  It will affect your "AA" compliance rating.
   
• It can assist with SEO.
   
• I have personally found during the process of developing a website that validation usually results in cleaner code that is less bloated, which can help boost load times.

Most interestingly, Opera found that most of the programs and content management systems often used to develop/publish websites generally fail to produce code that will validate.

According to Opera, web pages created with Microsoft FrontPage validated a paltry 0.55% of the time. Even more highly-regarded programs such as Adobe Dreamweaver didn't fare very well - only 3.44% of its pages passed W3C validation.

The same dynamic was true for popular content management systems - WordPress pages validated only 9% of the time while Joomla pages validated only 6.45% of the time.

The authors of the MAMA study come to the conclusion:

"The most obvious thing to take away from the entirety of the MAMA research is that people are BAD at this 'HTML thing'. Improper tag nesting is rampant, and misspelled or misplaced element and attribute names happen all the time. It is very easy to make silly, casual mistakes--we all make them. Validation of Web pages would expose all these types of simple (and avoidable) errors in moments."

Of course, the authors point out that part of the difficulty in producing W3C compliant markup is that standards are evolving so rapidly and it's hard to keep up.  So regular testing is important.

It's easy for most of us to throw in the towel on standards compliance, especially when one notes that MAMA found that most of the Alexa 500 (some of the most popular websites in the world) failed to pass W3C validation.

This might lead us to ask, "Why does it really matter?"

But as internet content is increasingly consumed on other devices, such as mobile phones, valid markup becomes increasingly important to ensure a satisfactory user experience and accessibility across all of these devices.

The MAMA markup validation report makes for an interesting read and it highlights the challenges that on-line businesses, web developers and internet users face as the technologies we employ on (and in the creation of) web pages make standards compliance an even more challenging task.

Here's a quick extract from the report which covers the CMS and Editor providers.

Validation for CMS and editors

Validation rates in MAMA's URLs were compared with the URLs that used the META "Generator" syntax. This allowed for the identification of text and Web page editors, as well as popular content management systems (CMS). First, the good news. Most of the popular identified CMS systems surpass the validation rates of the general URL population, with the exception of Blogger. It had an exceptionally poor showing in MAMA's URL set.

Now for the (mostly) bad news. The text and Web page editors that identified themselves via the META element simply embarrassed themselves compared to the general population's validation pass rate...except for a lone shining beacon. Apple's iWeb editor definitively won the day in this category. Approximately 82% of pages reporting this editor passed validation--an astounding result considering the next-closest editor pass rate was Adobe Dreamweaver with only 3.4%! Aside from iWeb, all of the popular Web page editors that MAMA discovered had lower validation pass rates than the overall URL set.

I've just come across and article comparing Chrome and IE8 that has some interesting comments on the resources required to run the two browsers.  Perhaps the uptake might not be as dramatic as we first thought.

This is a big deal for Google, which is banking on wider adoption of its hosted application offerings and battling the perception that browsers are unreliable, especially when you start running multiple web applications in a tabbed format. Nobody wants to trust their line-of-business applications to an unstable environment, so Google hopes that Chrome will provide the kind of robustness that can assuage customers' fears.

So both Chrome and IE8 isolate tabs so that an error on one website doesn't crash all the other tabs you have open.

However, this and other new features mean that both Chrome and IE 8 stretch the limits of current PC hardware by gobbling up enormous amounts of RAM while saturating the system with lots of concurrent execution threads.

This new development sees browsers chewing-up more memory than their host OS. IE 8, for example, consumes 332MB of RAM to render a simple 10-site/10-tab browsing scenario. Not only did the 'fresh start' Chrome use nearly as much RAM (324MB) as the legacy-burdened IE 8 during peak browsing loads, it actually 'out-bloated' IE 8 over the duration of the test, consuming an average of 267MB versus. IE 8's 211MB.

Clearly, these are products targeted at the next generation of PC hardware. With nearly 20 percent of a 2GB PC's memory consumed by web browsing and with IE 8 spinning more than 170 execution threads on Windows Vista to complete the same aforementioned 10-site scenario (Chrome spins a much more conservative 48 threads), we'll need to rethink our ideas of acceptable minimum system requirements. At the very least, you're going to need multiple processing cores and many gigabytes of RAM to support this new, more demanding take on web-centric computing.

It will be interesting to see how they perform once they reach the Release Candidate stage.  if it's the same scenario then the uptake of these new browsers will be constrained by punters have enough grunt in their PC's to take advantage of the new and desirable features.

But that isn't an excuse to not keep your Code Quality score as high as possible !

Following on from my posting this week on Google's new Chrome browser   I see there's a huge argument about to kickoff over COI proposals regarding which browsers the public sector should support. You may be forced to change your browsing habits and computer setup to accommodate the guidelines if they were to be accepted

The Central Office of Information quietly published its consultation document on Friday, containing a proposal that public sector websites may snub browsers with a low market share. The COI suggests that web designers need not test against browsers with a share of less than two per cent. The bureaucrats recommend that designers place an advisory notice asking users to switch to a "supported" browser.

It's not the arbitrary figure, apparently plucked out of the air, that has enraged professionals - but the entire approach. The Web Standards Project's Bruce Lawson called it "entirely back-to-front", arguing that designers should code for the web, not individual browsers. Designers should conform to commonly agreed basic standards, rather than browser idiosyncrasies he said.

"The guidelines should be advocating a specific development methodology: they should recommend designing to Web Standards," he wrote. "Costs will be driven down, even if testing is performed across more browsers, because there will be fewer inconsistencies and less recoding to fix inconsistencies."

The guidelines recommend that browsers with less than two per cent share, which leaves Opera, and other browsers in the cold, should be disregarded.

Rather unsurprisingly Opera is apparently canvassing the COI to adopt a Code to Standards alternative.

Oddly, the bureaucrats fails to follow their own logic, with the requirement that Linux should be supported - even though it "fails" the two per cent test. The most popular browser on Linux, Firefox, amassed just 153 visits to the COI site in July, compared to 19,777 from Internet Explorer.

(By the same COI figures, IE accounted for 83.25 per cent of traffic, followed by Firefox on Windows with 8.68 per cent, Safari with 3.99 per cent, and Firefox for Mac with 2.53 per cent.)

And it's particularly harsh on Opera, which not only fails the concession granted to Linux, as its popularity is underestimated because Opera can masquerade as "Internet Explorer" or "Firefox" so web server logs fail to reflect its true usage.

So the rumours of Google joining the browser wars came to fruition this week with the announcement of Chrome.

Looking through the specs I don't see anything revolutionary but then it's based on standard Open Source code so how different did you expect it to be ?  In fact looking at the specs of all the browsers out there it's seems to me to be almost down to particular features that suit the way that YOU use the internet will determine which browser you use. (Unless, that is, you're someone that wont use IE because it comes from Microsoft.)  Even Microsoft seem to be back in the fray in a serious way with IE8 features up there with Firefox 3 and Opera 9. 

I couldn't find anything that leapt off the page and said "here's a great reason to change" so the success of Chrome is going to be down to a couple of things:

• How much effort (money) will Google expend to promote its use
• Delivery method

Both are significant.  I doubt we'll see any record breaking downloads as we did with Firefox 3 but the second has the potential to ramp up the usage over time.  If Google take the stealth route as Apple do with Safari and iTunes we could see numbers rack up by default as users inadvertently end up with Chrome because they've just updated their Google Desktop or whatever.

So we've got another big player in the market which will, hopefully, drive the competition harder to benefit us all.

From a Website owners viewpoint (and therefore a Sitemorse view) this means yet another Browser that may give compatibility issues.  Chrome will be HTML standards compliant to the same degree as Firefox and Opera (and the upcoming IE8) so it will cause similar headaches.

As with the other browsers we recommend you keep your Code Quality score as high as practicable to help towards ensuring compatibility.  See my previous blogs on this subject   http://blog.sitemorse.com/2008/06/ie8-standards-compliance-issue.html http://blog.sitemorse.com/2008/06/firefox-3-hits-8-million-downl.html