Code quality tests check the HTML sent to visitors conforms to standards. For example checking tags have been closed correctly.

To users presentation is critical, if simple things like broken links and images appear on your corporate page the user is given a distorted view that your company does not focus upon quality. Additionally search engines may not properly catalogue or index a site that contains HTML errors.

After the initial effort to design a complete site additions and corrections need to be checked at each stage to ensure they meet the same quality as the rest of the site.

Sitemorse reports analyse the results from hundreds of tests. The Code Quality score is determined via the benchmark table.

NB, if the number of errors detected represent less than 0.8% of the possible errors in the test, the code quality will be equal to or greater than 99.2%. Which will score 10/10 for Code Quality.

ASP.NET records the state of each HTML control on a page through a technology called ViewState which is enabled by default. Viewing the source of an ASP.NET page will reveal an entry similar to the following:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />

The HTML 4.01 specification section 6.2 SGML basic types requires 'id' and 'name' tokens to begin with a letter. As the generic attribute 'ID' is declared as SGML type 'ID' it cannot begin with an underscore.

As of November 2010 Sitemorse reports the following error for HTML pages and no error for XHTML pages:

file/html/badvalue - "__VIEWSTATE" is not a valid value for attribute "id" to tag "input".

Previously to this date Sitemorse enforced the rule for both HTML and XHTML. Although the collection of legal values for token names in XHTML is much larger than that permitted in HTML we enforced Appendix C, our reasoning was as follows:

XHTML is a blend of XML and HTML - to support current browsers, including IE7, XHTML is served from the web server with a "text/html" mime type. The XHTML 1.0 Specification requires XHTML content served with a text/html mime type to conform to certain Compatibility Guidelines outlined in Section C.

Furthermore Section C.3 Fragment Identifiers states:

When defining fragment identifiers to be backward-compatible, only strings matching the pattern [A-Za-z][A-Za-z0-9:_.-]* should be used.

Thus our conclusion was that in order to comply with the compatibility specifications the 'id' attribute could not begin with an underscore.

However, given the widespread use of the '.NET' platform and direct discussions with the W3C we have decided that 'id' attribute values starting with one or more underscores has no negative impact on modern browsers and is therefore acceptable for pages declared as XHTML.

Fixing ViewState in ASP.NET

One of our clients submitted a workaround to force valid ID values for HTML and therefore fully compliant for XHTML pages. The code can be applied either to a Master Page or in individual pages.

Source code for the VB ViewState fix

What is HTML 5?

HTML 5 is the long-awaited successor to HTML 4, the standard web markup language which has been with us for well over a decade now. If the development of a new web standard has mostly passed you by so far, you can expect to hear a lot more about it over the coming months as media interest increases. For example, coverage of the recent release of Internet Explorer 9 and Firefox 4 has focused attention on the abilities of both these browsers to handle HTML 5-based content. However, if you inferred from this that release of HTML 5 is imminent, you'd be wrong - it's a long way off yet.

So what's the timetable?

It won't surprise anyone in the online world to hear that the HTML 5 project has already been running for many years, is behind deadline and growing in complexity by the day.

In point of fact, HTML 5 is being developed by not one but two bodies: the World Wide Web Consortium (W3C - www.w3.org) and the Web Hypertext Application Technology Working Group (WHATWG - www.whatwg.org). Many key players are participating, including the four major browser vendors (Apple, Mozilla, Opera and Microsoft) and a range of other organisations and individuals with diverse interests and expertise.

Work commenced in 2004, but it was not until 2008 that the W3C Working Group published the First Public Working Draft1 of the official specification. The original timetable envisaged that HTML 5 would reach final sign-off by late 2010 but that date has come and gone. At April 2011, the latest plan is to move to 'Last Call' (an invitation to communities inside and outside W3C to confirm the technical soundness of the specification) in May 2011, with a target of 2014 for full 'Recommendation' (i.e. when HTML 5 becomes the officially recognised standard).

Why do we need HTML 5?

HTML 4 has been around for well over a decade now - an eternity in the technology world - and publishers seeking new techniques to provide enhanced functionality are being held back by the constraints of the language and browsers. HTML 5 is an attempt to meet that challenge with an improved, unified and consistent markup language for both content and applications, resulting in significant benefits across the entire panoply of modern web-enabled devices ('interoperability', as it's known).

Just two examples of the key differences between HTML 4.1 and HTML 5:

Better multimedia

One key 'interoperability' challenge is to take multimedia to the next level. Although multimedia has made breathtaking progress in recent years, developers rely heavily on APIs and plugins to make it work - resulting in problems such as the iPhone not supporting Flash. HTML 5 includes video and audio elements designed to enable multimedia to be embedded into web pages directly. This should make it far easier to ensure that multimedia content can be accessed without any problems on a PC, tablet, phone or other device.

More logical page structures

First we had tables and then we had stylesheets - a major leap forward that freed up web page design and led to the incredible sophistication of modern sites. HTML 5 is another logical step forward: new elements have been introduced to identify page sections – e.g. <header> <footer>, <nav>, <article> and <footer>. This should not only make it easier to build and change pages (less reliance on IDs and classes), but it's good for assistive technologies as well, making navigation that little bit easier.

For more details on the numerous differences between HTML 4 and 5, see the W3C article at http://dev.w3.org/html5/html4-differences/

Should we be using HTML 5 now?

HTML 5 is very much a work in progress and there's still a long way to go before it's been thoroughly specified, tested and declared fit for purpose. Although developers and designers everywhere are champing at the bit, Philippe Le Hegaret, W3C interaction domain leader, issued the following note of caution in October 2010: "The problem we're facing right now is there is already a lot of excitement for HTML 5, but it's a little too early to deploy it because we're running into interoperability issues."

Having said that, it would be wrong to suggest that nothing should be done until HTML 5 gets the official green light. This is all part of the non-stop evolution of web technology and developers are quite naturally already experimenting with innovative features such as the <video> tag. However, there's a very long way to go before compatibility and stability issues have been ironed out, so you need to be clear about any risks you are taking. This is a time not to get over-excited by the hype, or to allow yourself to be swayed by web agencies who see opportunities for extra business!

For more information on HTML 5 compatibility issues, see www.caniuse.com

Is it ok to change my doctype to HTML 5?

Some online pundits are already advocating changing all your doctypes to the new, simpler HTML 5 version: <!DOCTYPE html> since many of the tags defined in HTML 4 are still supported in the newer version. Sitemorse recommends against it simply because it's far too early. HTML 5 is supported by hardly any browsers at this point and there's no reason to risk any kind of confusion with your page coding. Mislabelling a page runs the risk that it won't validate properly, and labelling an HTML 4 page as HTML 5 is not only incorrect, it provides no useful benefits.

Does Sitemorse support HTML 5?

Sitemorse does not currently officially support HTML 5 as the new standard is still a long way off from being finalised. However, we have partial HTML 5 support that is intended to prevent its use producing spurious errors in Sitemorse reports. We are constantly monitoring the situation and are happy to answer any queries you may have relating to your use of HTML 5 and its impact on your Sitemorse reports.

References

1. W3C Working Draft 22 January 2008: 'HTML 5: A vocabulary and associated APIs for HTML and XHTML': http://www.w3.org/TR/2008/WD-html5-20080122
2. W3C press release: 'W3C Confirms May 2011 for HTML5 Last Call, Targets 2014 for HTML5 Standard': http://www.w3.org/2011/02/htmlwg-pr.html.en
3. Steve Jobs: 'Thoughts on Flash': http://www.apple.com/hotnews/thoughts-on-flash

Useful links

W3C: http://www.w3.org/

WHATWG: http://www.whatwg.org/

Infoworld.com: 'W3C: Hold off on deploying HTML5 in websites': http://www.infoworld.com/d/application-development/w3c-hold-deploying-html5-in-websites-041

W3C: HTML5 differences from HTML4: http://dev.w3.org/html5/html4-differences

CanIUse.com: http://www.caniuse.com/

Article published: April 2011