html5
Hello guys,
For designing by company's website, my boss is putting emphasis on html5.
Which one is better XHTML or HTML5 ??????
Can you refer me any tips and tutorials to learn html5????
For designing by company's website, my boss is putting emphasis on html5.
Which one is better XHTML or HTML5 ??????
Can you refer me any tips and tutorials to learn html5????
My preferred standards for any new sites, in order:
I am happy sticking with HTML 4.01 Strict for the time being. Browsers are, simply, never going to drop support for HTML 4.01 while they still support HTML5; implementations are generally robust and widespread. It is a respectable choice and beyond reproach.
As for HTML5, it's the standard of choice for the cool kids, though there are few tangible benefits for the majority of visitors to the majority of sites. It might break in IE with JavaScript disabled (even nowadays, around 1–2% of visitors browse without JS), or those few using FF2 or below. Inevitably, you will be alienating a small number of visitors, though probably not as many as you will if you intentionally omit to support IE6—another "hip" trend nowadays.
Finally, I would not bother with XHTML. For reasons too numerous to discuss, it simply did not take off as it should have, and frankly you won't get any benefit out of it.
- HTML 4.01 Strict
- HTML5
- Any XHTML doctype
I am happy sticking with HTML 4.01 Strict for the time being. Browsers are, simply, never going to drop support for HTML 4.01 while they still support HTML5; implementations are generally robust and widespread. It is a respectable choice and beyond reproach.
As for HTML5, it's the standard of choice for the cool kids, though there are few tangible benefits for the majority of visitors to the majority of sites. It might break in IE with JavaScript disabled (even nowadays, around 1–2% of visitors browse without JS), or those few using FF2 or below. Inevitably, you will be alienating a small number of visitors, though probably not as many as you will if you intentionally omit to support IE6—another "hip" trend nowadays.
Finally, I would not bother with XHTML. For reasons too numerous to discuss, it simply did not take off as it should have, and frankly you won't get any benefit out of it.
You'd better stick to HTML 4.01 because HTML 5 is not supported by most of the browsers
Short answer: It's safe to use some HTML5 stuffs, but not all.
You can safely use the new structural elements in all modern browsers, and with Remy Sharp's http://html5shim.googlecode.com/svn/trunk/html5.js you can even style said elements in lesser versions of IE.
http://www.modernizr.com/ allows you to use feature detection so that you only use HTML5 and CSS3 where it is supported.
One of my favourite things about HTML5 is the new input types, and what makes them even more brilliant is that if a browser doesn't recognize the input type, it falls back to a default input type="text". So if the users’ browser supports HTML5, great, if it doesn’t - no harm done.
Personally I have used HTML5 on 4 client projects so far this year, including a council site. If the government can do it, anyone can do it. And the more I use it, the more reluctant I am to go back (and used to be one of those annoying XML people!). HTML5 saves me time coding. It is a joy to use.
The edge cases are of course IE8 and below without JavaScript enabled. The site will still work; it just won’t be styled properly. So if you have to deal with perfectly styled versions for these browsers if there is no JavaScript (which generally is less than 1% of the population), then perhaps you cannot use the new structural elements. Check the stats for your particular site.
And of course you can only take advantage of the new JavaScript APIs where they are available. This of course should not prevent you from using them, use them when you can and use a fallback if you must.
Why should we spend so many resources on designing and developing for ancient browsers anyways? Reward people with modern browsers by giving them a great experience by using HTML5 and related technologies. Design for the future, not for the past.
HTML5 + CSS3 + WAI-ARIA + Microformats is pretty cool stuff, even if you don't end up using it on this project, you should definitely look into it. Of course you can use css3, WAI-ARIA and microfomrats with HTML4 as well. And with XHTML (which is my language of choice if I can't use HTML5).
You can safely use the new structural elements in all modern browsers, and with Remy Sharp's http://html5shim.googlecode.com/svn/trunk/html5.js you can even style said elements in lesser versions of IE.
http://www.modernizr.com/ allows you to use feature detection so that you only use HTML5 and CSS3 where it is supported.
One of my favourite things about HTML5 is the new input types, and what makes them even more brilliant is that if a browser doesn't recognize the input type, it falls back to a default input type="text". So if the users’ browser supports HTML5, great, if it doesn’t - no harm done.
Personally I have used HTML5 on 4 client projects so far this year, including a council site. If the government can do it, anyone can do it. And the more I use it, the more reluctant I am to go back (and used to be one of those annoying XML people!). HTML5 saves me time coding. It is a joy to use.
The edge cases are of course IE8 and below without JavaScript enabled. The site will still work; it just won’t be styled properly. So if you have to deal with perfectly styled versions for these browsers if there is no JavaScript (which generally is less than 1% of the population), then perhaps you cannot use the new structural elements. Check the stats for your particular site.
And of course you can only take advantage of the new JavaScript APIs where they are available. This of course should not prevent you from using them, use them when you can and use a fallback if you must.
Why should we spend so many resources on designing and developing for ancient browsers anyways? Reward people with modern browsers by giving them a great experience by using HTML5 and related technologies. Design for the future, not for the past.
HTML5 + CSS3 + WAI-ARIA + Microformats is pretty cool stuff, even if you don't end up using it on this project, you should definitely look into it. Of course you can use css3, WAI-ARIA and microfomrats with HTML4 as well. And with XHTML (which is my language of choice if I can't use HTML5).
| stevenjotello wrote: |
| Do not bother with XHTML. For reasons too numerous to discuss, just not taking off as it should have, and frankly, will not receive a benefit from it. |
I quite like the strictness of xhtml. Validating against this using the W3C validator is always of great help when debugging. As such using XHTML strict has been a major advantage and time-saver for me.
| Linda wrote: |
| I quite like the strictness of xhtml. Validating against this using the W3C validator is always of great help when debugging. As such using XHTML strict has been a major advantage and time-saver for me. |
The strictness of XHTML is actually one of my dislikes! I like the flexibility and terseness of HTML; for example:
| Code: |
| <table>
<thead> <tr> <th>Column 1</th> <th>Column 2</th> </tr> </thead> <tbody> <tr> <td>Value 1</td> <td>Value 2</td> </tr> </tbody> </table> |
Can be written as:
| Code: |
| <table>
<thead> <tr> <th>Column 1 <th>Column 2 <tbody> <tr> <td>Value 1 <td>Value 2 </table> |
Not to mention that horrible stuff XML namespace invocation! I don't mind that for actual XML where I might use namespaces!
@Jordan - are you saying you like to write bad code?
There is nothing bad about small code - that examples is perfectly valid HTML 4.01 Strict. I sometimes write numerical tables like this:
If I have more than one row of header cells, I'll indent them like the data rows:
This is entirely accessible and valid HTML. It uses some "short-hand" syntax tricks such as "omit optional tags" as described by the W3C specification.
It is invalid in XHTML but people still do it accidentally, a hint that they don't actually need XHTML. It's also invalid in XML, which nobody uses for web pages.
| Code: |
| <table>
<thead><tr><th>Header A<th>Header B <tbody> <tr><td>1.1<td>1.2 <tr><td>2.1<td>2.2 <tr><td>3.1<td>3.2 </table> |
| Code: |
| <table>
<thead> <tr><th colspan="2">Header A<th colspan="2">Header B <tr><th>Header Aa<th>Header Ab<th>Header Ba<th>Header Bb <tbody> <tr><td>1.1<td>1.2 <tr><td>2.1<td>2.2 <tr><td>3.1<td>3.2 </table> |
It is invalid in XHTML but people still do it accidentally, a hint that they don't actually need XHTML. It's also invalid in XML, which nobody uses for web pages.
If you think that missing out optional table closing tags is "bad code," I really look forward to seeing what you think of Anne van Kesteren's 100% valid markup.
But seriously, HTML has its own grammar. Forcing it to follow XML well-formedness rules at this stage confers little advantage on 99.9% of the web. In fact, the main thing it seems to have achieved is to confuse authors about how actual HTML works; see the proliferation of invalid self-closing syntax in non-XHTML documents, or the fact many people are only now rediscovering attribute minimisation and optional tags!
But seriously, HTML has its own grammar. Forcing it to follow XML well-formedness rules at this stage confers little advantage on 99.9% of the web. In fact, the main thing it seems to have achieved is to confuse authors about how actual HTML works; see the proliferation of invalid self-closing syntax in non-XHTML documents, or the fact many people are only now rediscovering attribute minimisation and optional tags!
Just because it's valid doesn't mean it's good code.
I have seen a lot of "valid" code that is rather poor, in that it is difficult to read, poor indentation, loads of extra divs, unsemantic class names, etc.
And yes, I consider unclosed tags one of those.
And I think XHTML is good for beginners in particular, in that they don't have to remember which tags to close and which to not close. Just close everything.
I have seen a lot of "valid" code that is rather poor, in that it is difficult to read, poor indentation, loads of extra divs, unsemantic class names, etc.
And yes, I consider unclosed tags one of those.
And I think XHTML is good for beginners in particular, in that they don't have to remember which tags to close and which to not close. Just close everything.
| Quote: |
| I consider unclosed tags one of those [factors indicative of bad code]. |
Unclosed tags are verboten in XML for a reason—it makes parsers easier to write, which was one of the goals of XML. That's fine for XML, but HTML as a language does not conform to XML rules, and proscribing an entire grammatical feature of a language is not something that one should do lightly.
XHTML and HTML are different languages; they have different grammars, different parsing rules and open up different possibilities for document authoring. XHTML lets you do some neat things, like extend your documents with new XML vocabularies or integrate them more closely with your XML back-end technologies. HTML, especially with HTML5, lets you be more tersely expressive, if (like 99.9% of XHTML document authors) you don't actually use any of the advanced features of XHTML.
Let me try to demonstrate this with two equivalent, but very different, documents. First, a valid XHTML document:
| Code: |
| <?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="style.css" type="text/css"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Simple XHTML document</title> </head> <body> <p>A simple <abbr xml:lang="en">XHTML</abbr> document.</p> </body> </html> |
And the valid HTML version:
| Code: |
| <!doctype html>
<title>Simple HTML document</title> <link href="style.css" rel="stylesheet"> <p>A simple <abbr lang="en">HTML</abbr> document. |
The first used some of the lesser-known best practises for XML authoring:
- An XML declaration—recommended by the W3C.
- A stylesheet attached to the document as a processing instruction. (For example, see the W3C's HTML Compatibility Guidelines.)
- The xml:lang attribute, which is sufficient to indicate which language is being used in an XML-compatible UA. (And, incidentally, introduces the predefined namespace "xml:".)
- For that matter, the use of namespaces at all (as per the xmlns attribute) is something I wouldn't like trying to explain to someone who didn't understand XML beforehand!
While the second uses some features particular to HTML:
- Shorter DOCTYPE courtesy of HTML5.
- Default type value of "text/css", also courtesy of HTML5.
- Optional closing paragraph tag.
- Optional opening AND closing tags: html, head and body.
Now, I'm not going to pretend that all of those features are always a good idea in practise. But they are all completely legitimate and justifiable parts of their host specifications. In particular, if you're not targeting a parser that supports those XML notions I mentioned earlier, you are probably not getting any benefit out of using XHTML! I say this as someone who has used XHTML previously for compound XHTML 1.1/MathML documents, and had to be familiar with things like XML namespaces. (That's probably why see so much value in using shortened notations when I feel that the meaning remains unambiguous: I do not see any reason for putting myself through that verbose extra syntax when I can possibly avoid it.
The point I'm trying to illustrate, and hope I have succeeded in doing just a little, is that XHTML and HTML are very different languages, and there are good reasons that they are different. Anne van Kesteren's HTML misses out lots of optional tags, sure; but it's also very carefully-written, correct and hardly difficult to read.
Last edited by Jordan Gray on 12 Dec 2010 11:13 pm; edited 1 time in total
By-the-by, it is interesting to note that HTML5 renders a lot of those arguments academic by allowing you to use XML-style self-closing tags in HTML (previously invalid) or exploit some of the more desirable extensions to XHTML (vis-à-vis MathML and SVG) without switching wholesale to XML's draconian parsing.
yeah I'm not sure why we're arguing really.
Sure, I used to be one of those really annoying XML people, but I've been using nothing but HTML5 since this summer, and I love it.
Of course I still close my tags, even the self-closing ones, so obviosuly I still have some issues. But hey, this thread is about HTML5 so, can we agree that
1) HTML5 rocks
2) it is a much better solution that xhtml 2 would have been
3) If you're one of those annoying XML people, you can still use your beloved syntax in HTML5, but if you prefer to use HTML4 conventions you can
And yes, I do find code with no indentation difficult to read.
Sure, I used to be one of those really annoying XML people, but I've been using nothing but HTML5 since this summer, and I love it.
Of course I still close my tags, even the self-closing ones, so obviosuly I still have some issues. But hey, this thread is about HTML5 so, can we agree that
1) HTML5 rocks
2) it is a much better solution that xhtml 2 would have been
3) If you're one of those annoying XML people, you can still use your beloved syntax in HTML5, but if you prefer to use HTML4 conventions you can
And yes, I do find code with no indentation difficult to read.
HTML5 really looks promising, from a coder as well as a user's point of view. I suppose this will make websites a lot faster, provided the browser supports it. Does anyone know which browsers support the new format yet? I bet Internet Explorer will be the last to join the club, as usual....
Last edited by BStevenson on 07 Jan 2011 05:14 pm; edited 2 times in total
Last edited by BStevenson on 07 Jan 2011 05:14 pm; edited 2 times in total
There is nothing bad to use HTML5, almost all browsers now supporting HTML5. HTML5 helps you to build your site search engine friendly and user friendly.
Tags like <Header>, <Nav>, <Article>, <footer>, <aside>, <description> etc. enhance your good site structure.
HTML5 eased the multimedia, simply you can use <video> and <audio> tag.
Tags like <Header>, <Nav>, <Article>, <footer>, <aside>, <description> etc. enhance your good site structure.
HTML5 eased the multimedia, simply you can use <video> and <audio> tag.



