Description:

The target implied by the link text is not the actual target of the link. This may be misleading for users. This can easily occur when links are updated.

Example:

<a href="http://www.example.com/">www.example.net</a>

Description:

A file used as an image in an HTML page is being served with a MIME type that indicates it is not an image, or that does not match the actual image file format. For example, a JPEG image served with a MIME type of image/gif.

Description:

An image used in an HTML page is being resized by HTML or CSS attributes, or is an unexpectedly large file for the dimensions of the image. Resizing an image in HTML or CSS can increase the page weight unnecessarily.

Description:

The image file is corrupt and could not be decoded as a valid image.

Monday, 15th August 2011: We have today enhanced Sitemorse Snapshot by including the results from the Spelling module in the Snapshot report.

All Sitemorse users have unlimited access to run Instant Snapshot on any website, running our full range of tests, checks and measures on the page in only a few seconds. If your subscription includes the Spelling module then any time you test a page on a site covered by this subscription (for example your own home page) we will include the results of the Spelling module in the Snapshot.

The Spelling icon displays a green tick if all the words visible on the page, the page metadata and any accessibility "alt" text was found in the relevant language dictionaries or your own custom word list.

If one of more words are unknown to us a red cross is displayed. Clicking this icon presents a list of the unknown words and a snippet of context. Users with Snapshot Developer edition are also told the line number of the source code and the HTML tag the word was found in.

If the word is correct, such as a company name or part of internal terminology you can click the add button to add it to your default custom word list. Following this decision future tests of the same site will ignore the word.

This enhancement is also available for any standard Sitemorse report. Each time we check a site for you (including weekly audits, adaptive page monitoring and ad hoc testing) we store the Snapshot of the page. Spelling results will now be included in the Snapshot window.

Monday 9th May 2011: In response to feedback we have expanded and simplified the way we display broken links in the Function area of a Sitemorse report.

The new page layout is designed to be clearer to first time users which page is broken and which page(s) needs attention. As well as telling you the HTML tag and link content we now also include the line number. In the case of a PDF file we will now tell you which page on the PDF that the link was found on.

Many of you have been using Snapshot for some time to locate and fix broken links. So we've made this even easier by giving you direct access to the Snapshot - both Page and Source view - next to each broken link. Just click the blue icon to locate the problem link on your own, familiar, page.

One change our advanced users will notice is that previously if a broken link was found on the same page more than once we reported it just once (both errors were counted in calculating your Sitemorse score). This caused a little confusion when thinking you'd corrected the error when only one had been fixed. To resolve this we now list each individual broken link, together with the line number, tag name and content and Snapshot views.

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

Monday 6th December: We have this week rolled out a couple of small changes to the cookies testing in Sitemorse. The first change is very simple and straightforward - to help users repair reported problems, the diagnostic messages will now include the name of the problematic cookie.

The second change is that, while we still report errors found with cookies, the testing system will now accept the faulty cookie, and send its value with subsequent requests that are part of the same test. This should help alleviate the situation where the web server being tested sees that the cookie has not been accepted, and repeatedly attempts to set it with every request - leading to hundreds of diagnostic messages about the same cookie.

Monday 19th April 2010: Sitemorse now checks ID attributes for duplicates and checks to see if any fragment identifier included in a link actually exists.

Duplicate fragments, for example declaring two or more tags with the attribute 'ID="dupid1"', are reported under Code quality page 1:

file/html/badvalue Fragment identifier 'dupid1' used more than once

Links containing a fragment identifier which doesn't exist on the target page are flagged under Code quality page 2.

For example, if a page includes the link '<a href="#unknownid1-1">unknown local id 1</a>' but the corresponding ID 'unknownid1-1' does not exist, we raise the following failure:

file/html/unknownid '#unknownid1-1' not found

April 2010: We've been making some improvements to the way Sitemorse handles the differences between HTML and XHTML.

New diagnostic messages:

'/' in middle of attribute list

For example, <foo a=1 / b=2>

Close-tag X has extra '/'

For example, </div />

Missing </X>

We no longer allow implicit closes in XHTML i.e. <link ...> instead of <link ... /> or <p> with no </p>

Tag X should be closed using the minimized form

We are more specific about Appendix C violations. e.g. <hr></hr> doesn't say "Tag X does not need a close-tag", instead in XHTML mode it displays this new message instead:

Tag X should not be closed using the minimized form

For example, <p /> - another Appendix C violation

Minimized self-closing tags (e.g. <tag/>) are not allowed in HTML

For example, if you try to use <link ... /> in HTML mode

Attribute Y to tag X must take a value of Z

In XHTML mode we are more specific about boolean attributes, e.g. <input checked /> or <input checked="yes" /> or indeed anything except <input checked="checked" /> will give this message. In HTML it still says "Attribute Y to tag X does not take a value"