HTML5 Doctor » Validation

Your Questions Answered #3

Richard Clark — Thu, 22 Oct 2009 13:52:44 +0000

We’re back with our (semi) regular round up of answering readers HTML5 related questions. Right, let’s not mess about any longer and dive straight in with the questions.

Multiple use of tags

Daniel Davis asked:

Dear Doctor,

Just a quick confirmation please.

Am I right in thinking that nav, like header and footer, can be used more than once in a single page? For example, surrounding a menu at the top of the page and surrounding next/previous buttons at the bottom.
Come to think of it, is it fair to say that all tags except html, head and body can be used more than once?
Thanks in advance, doctor.

I’ll be back soon about my dodgy knee.

You’re correct all the elements you mention can be used more than once a page. If you see this article about the header and this about the footer – they show that you can use them multiple times on a page. Also you don’t really need html, head or body tags, as all browsers will assume them anyway but it’s also safe to leave them included.

— Hope that clears things up Rich and Bruce

HTML5 + Javascript Client Web App

Girish asked:

Is it possible to create a complete client side application using HTML 5 (it will embed chat clients, stock ticker) + JavaScript, and then bundle is with underlining Firefox 3.5 engine, so that user can install it as a desktop app on Linux, and then it runs in its own window using firefox 3.5 engine. The app will store everything in local storage – like url, usernames etc, and will not interact with any local server.

It would pure HTML5 + JavaScript based client web app which would be packaged, and can be installed or launched from startup scripts.

Or instead of using firefox 3.5 engine, we can use Mozilla Prism to convert it to web app, and then bundle it, is it possible?

Technically it should be possible. Certainly the HTML5 offline applications API (via the manifest) gives you all that ability to create a client side app and it run locally without a web connection.

However, the browser is the problem. Prism might be a good way to deploy this as a standalone app, but I don’t know if Prism is running the latest Gecko engine (or whether that comes with the JS engine, etc) – and even if it does – Firefox 3.5 currently has a pretty severe bug with the offline applications: it doesn’t work!

I have logged the bug with Mozilla and I know they’re working (in fact, I believe they’ve fixed it and are now testing).

The alternative is to use Fluid (a Webkit based app) – but again, that’s only if they have updated to the latest Webkit and thus including the offline applications API (that said, quickly looking at the Fluid site, their in-progress version may have the latest Webkit).

Regarding launch from start up scripts – you could achieve this though the custom scheme handlers (but this is just Firefox IIRC): http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#custom-handlers

Equally, there may be an API that you could exploit via the standalone browser, either Prism or Fluid.

— Good luck! Remy

MIME or DOCTYPE, which one prevails

Pedro Estébanez asked:

Hello doctor,

I have found this site a very good resource for web developers and I thank you for your effort.

Now, my question:

There is a lot of discussion about hot to tell the browser we are using HTML5 or XHTML5 by setting the Content-Type HTTP header. But then I don’t know the true role the DOCTYPE plays (apart from keeping quirks mode from being activated and validation).

For example, if I compose my documents as XHTML with an according DOCTYPE and my server serves them as text/html, why XML mode is not triggered in the browser?

Thanks in advance.

Did you see this article on the site from Bruce? HTML5, XML and XHTML5 and this one from Remy HTML5 Boilerplates.

Also see this (linked in Bruce’s article) for some advice on using the right mime type. http://www.webstandards.org/learn/articles/askw3c/sep2003/.

— Cheers Rich

Outline Algorithm

Mike Taylor asked:

In Section 4.4.11.1 of the current HTML5 spec, the outline algorithm is described–yet it’s not super clear in what ways this is useful to users or developers. It would be great if some more light could be shed on the topic!

Thanks for the awesome blog, btw.

The outliner basically allows you to easily see the heading structure of a site. The outline can then figure out from the heading structure where in the outline it should sit, should you want to only parse a section of the code into another site or page for example. (I realise this isn’t totally clear). Also check out the HTML5 Outliner for checking your work.

Bruce covered it a little bit in his section article – “With very few exceptions, section should not be used if there is no natural heading for it. Check your work in the HTML 5 outiner tool. If you see any instances of “untitled section” that corresponds to a section, you’re probably doing it wrong. (It’s fine for a nav or aside element to be untitled, however).”

We’ll try and cover it in more detail in a future post but I hope this helps for now, Rich.

HTML5 and xmlns

Ad Taylor asked:

I hope this isn’t a stupid question BUT …

If I am using the html5 DOCTYPE and I am still using xhtml syntax do I need to define the xmlns in the html tag (i.e. xmlns=”http://www.w3.org/1999/xhtml”)?

Thank you for taking the time to do this.

We said, Not a stupid question, but a simple answer: No!

— Ta Bruce (HTML5 Shrink)

Developing to a changing spec

Sam Rayner asked:

I read the Super Friends Guide to HTML5 Hiccups – http://www.zeldman.com/superfriends/guide/ and it’s worried me a little.

I’ve recently been developing personal projects using HTML5 as I find I learn best ‘on the job’ and wish to become familiar with the new spec by putting it in to practice. However, it sounds like I’ve misinterpreted bits and often used new elements such as footer in the way the Super Friends describe rather than in line with the spec.

I really want to continue enjoying the benefits of HTML5 in my own non-critical web work but it seems I run the risk of having to return to it all at a later date and amend stuff due to changes in the spec.

What do you think the best course of action is? Continue with 5 but keep going back and fixing old projects? – Could become a real hassle.

Continue with 5 and leave non-visual discrepancies as they are (the code may be slightly off but it’s styled fine)? – Goes against all of my natural instincts to do things right.

Return to 4 and use class names as apposed to the new elements for the time being?

I realise this is the risk I take developing with a developing spec but I’m worried if I wait until everything is set in stone I’ll still be using HTML4 years from now!

Thanks a lot,

I understand your concerns with the spec changing from day to day. It’s hard to keep up with (there’s 6 of us and that’s tough enough).

Although I’m sure you’re aware in footers case, its content model has now been changed to allow it to act more like header.

I think essentially you have three choices for your development or a combination of the below currently:

Continue working as you are with new HTML5 elements and change them as the spec becomes more defined
Use HTML4, with HTML5 class names (as you suggested)
Use only the simplified doctype and those elements that will only be benificial in the future or add progressive enchancement (e.g. inline elements such as time.)

Its going to be a while until we can use HTML5 in development projects but in my opinion there isn’t any reason to not use it on personal projects now. You have to judge it on a case by case basis, but whichever parts you do you will be futureproofed to some extent.

— Cheers Rich

HTML5 and Browser Compatibility

A lot of people ask this type of question regularly so here’s a few links that we think are useful.

That about wraps up this round of questions, we’ll be publishing more soon, but in the meantime don’t be afraid to keep asking the doctor about HTML5.

Share and Save:

Your Questions Answered #3 originally appeared on HTML5 Doctor on October 22, 2009.

Absent Elements and Validation

Richard Clark — Tue, 25 Aug 2009 14:30:14 +0000

We received the below question from Guy Carberry who was wondering what effect changing the doctype on your HTML or XHTML pages to the HTML 5 doctype will have on those elements that are deprecated current draft.

The Question

There are several aspects to consider from this question so lets start by taking a look at Guys question in full.

Jeremy Keith says that we can change the Doctype declaration on XHTML 1.0 syntax pages to and it will immediately become HTML 5.

I'm a bit confused about what that means for the Absent and changed elements and attributes info detailed here: http://www.w3.org/TR/html5-diff/#absent-elements

"Some attributes from HTML 4 are no longer allowed in HTML 5. If they need to have any impact on user agents for compatibility reasons it is defined how they should work in those scenarios."

So if this is that case, how can you switch the doctype declarations and all be fine?

Thanks for your help,

Guy.

The Doctors Response

In answering the question we will need to break the question down into the following:

Which elements or attributes are deprecated?
Do I use any of those elements or attributes on my site?
How much do I need to worry about validation?
What effect will this have for backwards compatibility?
Can my content be accessed in all my target browsers and user agents?

Lets consider each of these in some more detail below.

1. Which elements or attributes are deprecated?

The elements deprecated (from HTML 4.01) from the HTML 5 specification are: basefont, big, center, font, s, strike, tt, u, frame, frameset, noframes, acronym, applet, isindex, dir

You can find a list of those elements and attributes along with detailed reasons of why they've been removed by reading HTML 5 differences from HTML 5.

2. Do I use any of those elements or attributes on my site?

If your site uses any of the above named elements or attributes you may consider changing them to more semantic elements as introduced in HTML 5. Alternatively you may decide to remove them and use CSS for presentation in the case of or

Guy told use that he works for a large university. The site uses a large number of tags which have been removed from HTML 5 as detailed above. To solve this issue for Guy, I feel he has three options if he wishes to make the site: HTML 5:

Change the doctype to HTML 5 and leave the elements in. (Bear in mind the HTML won't validate)
Change the doctype to HTML 5 edit the elements to become elements as advised by the specification
Do nothing and leave the site as HTML 4.01 or XHTML

It's difficult to be able to advise Guy on which option he should choose without knowing the full extent of the effort involved to implement these solutions or knowing the sites goals and project teams views on validation. Speaking of validation, the whole area is a minefield and it's what we'll attempt to cover next.

3. How much do I need to worry about validation?

While validation is undoubtedly important for your markup and your CSS, in my opinion it isn't crucial to a site. Allow me to explain, we recently received a couple of emails pointing out that this site doesn't validate. While there were some errors that have now been corrected, a primary reason why is the use of ARIA roles in the markup. These attributes currently aren't allowed in the current specification, however there is work underway to make this happen.

To illustrate this point let's look at Google, the search giant. If you look at the source on Google's search pages you'll see they use the HTML 5 doctype.

However, those pages don't validate because they use the and

elements amongst others things that we already know have been removed from the specification. Does this mean that users stop visiting Google? No.

Remember too that the specification is yet to be finalised and may still be changed (thus breaking you're perfectly valid docments), in partnership with this changes to the specification may not immediately take be implemented in the validators. We also need to bear in mind that HTML 5 takes a "pave the cowpaths" approach to development, meaning that the Hixie, et al will look at what authors already do and improve upon it.

4. What effect will this have for backwards compatibility?

Leading on from the point about Google as mentioned previously we know Googles site not validating doesn't matter but is it still backwards compatible? Yes. As far as we know, all the browsers support the tag. It's the validators that don't. If you want to use an antiquated element you can do, the browser will still handle it - it just won't validate.

In terms of backwards compatibility there is no reason why you couldn't start using new HTML 5 elements in your HTML 4.01 or XHTML 1.x documents, it could even be described as progressive enhancement. For example, why not include the element? It won't validate but maybe that doesn't matter? The browser will still be able to render video, hence "paving the cowpaths". Having said that if you're going to the effort of including new elements why not go the whole hog and change the doctype too?

5. Can my content be accessed in all my target browsers and user agents?

Again to look at Google, it still renders in older browswers and devices but to all intents and purposes it's HTML 5. Another aspect that the specification defines is that new features should work in or not break in older browsers.

Remy pointed out in a response to Guy that

Remember that the browser is still going to handle this, regardless of whether HTML 5 supports this or not. Just like and XHTML document although doesn't validate with frames, it still renders fine and still supports frames.

So from that we can conclude that browsers will still render deprecated elements or practices.

Summary

To wrap up I think we can answer Guys question by saying yes, changing the doctype will make your site HTML 5, but whether or not it validates is in essence an entirely personal or business decision. Whether this means you are making use of all the benefits of HTML 5's new elements, javascript API's or offline storage is a whole different subject.