Popular Posts
-
MailShadowG is an application that will allow you to sync Outlook with Gmail. MailShadowG is a product of Cemaphore Systems , a California b... -
Dark designs can be really stunning. I mean, really . In Web 2.0 designers try to do their best to impress their visitors and in many cases ...
-
"Coming soon" pages are a great way to tide over your visitors until you finish your new website. They can be used as a teaser fo...
-
It’s quite easy to get stuck in creativity blocks, but it’s damn hard to get out of them. Particularly if you are out of time and don’t want...
-
If you are like me then, you definitely enjoy a good advertisment and also spread the word about that product or service. Even if is about c...
-
The Indian finance ministry has begun a public competition to select a design for the symbol of ...
-
BADGES Web 2.0 Badges - A set of free badges to download and use in your own designs. Fresh Badge - Quickly generate your own badge. adClu...
-
We can all learn a lot from what those around us are doing. One thing I tell the clients I work with is if you can’t lead, then follow a lea...
-
I have used every one of these resources as a graphic designer and website developer and have hand picked all of these resources based on th...
-
Navigation menus have really important role in any website. For big sites full with a lot of pages and articles, drop down menus and tabs ar...
Another look at HTML 5
Sunday, June 10, 2007
It has become evident to me that some of my previous comments about HTML 5 and what is going on in the HTML Working Group are the result of misunderstanding and overreacting on my part. I no longer think things are quite as bad. I still believe there are some problems that need to be solved though, so I’m going to try once more to explain my feelings and suggest a few things that I think would improve the situation going forward.
My personal reason for writing web related articles and tutorials is that I am really passionate about doing what I can to make the Web a better place that everybody can use. That thinking can be applied to many aspects of web design and development, but since this is about HTML 5 I’ll be focusing on creating markup in this article.
I want to improve the Web
I really want the Web to work better, for more people, than it does today. In order to make the Web a better, more accessible, user-friendly, and interoperable place, I believe that developers, designers, CMS vendors, and authoring tool vendors all need to be educated. We all need to adopt best practices in our work, and encourage others to do so as well. Writing tutorials is one way of doing that, but I don’t think it is enough.
Tutorials, blog posts, and books only reach those who find and read them. Unfortunately that means most people who work with the Web read little, if any, material that helps them improve their knowledge of HTML. I think that is quite obvious when you look at the current state of the Web.
So, while tutorials and guides do help, they only help those who want to be helped and know that they need help. They do not help people who want to do things right but are unaware that they are using HTML incorrectly. If they or their clients knew they were doing things wrong, many of those people would learn how to do things right. At least that’s what I, perhaps naively, want to believe.
Backwards compatibility and error handling
And that leads me to HTML 5, backwards compatibility, and standardised error handling. Backwards compatibility in browsers I don’t really have a problem with. I realise that it is necessary, though I don’t quite understand why browsers can’t treat new content (content that somehow claims to be HTML 5) in a different way than they treat current content. I am told that it is too expensive for browser vendors to do so, which sounds odd to me. But I am not a software engineer, so what do I know. They are probably right about that.
Error handling then. Yes, error handling is definitely necessary. People will always make mistakes, and standardised error handling is great for interoperability. But here is where my opinion differs from that of most browser vendors (and many others). I really am naive enough to think that browsers somehow making the user aware of errors in the markup will eventually lead to an improvement (and no, I do not believe that the W3C can force browser vendors to display error messages). Let me try to explain why.
Users will have one more way of judging the quality of the site they are visiting. They can already judge a site’s apparent quality by graphic design, content, and ease of use. I think they should also be able to easily judge the technical quality of a site. “But users don’t care about the code!”, you say. No, of course they don’t. That isn’t the point. The point is making them aware that they are using a site that is well crafted (or not, in most cases), and to make them start questioning why some sites have errors and others don’t.
All developers, not just the educated ones, will be able to get immediate feedback when they are using non-conforming (HTML 5-speak for invalid) markup. I believe that a decent number of developers will want to fix that, which probably requires them learning what they are doing wrong and how to do it correctly. A counter-argument to this is that developers should install browser extensions that provide this functionality. But most don’t do that, and never will.
I am not saying that browsers should stop rendering when they encounter an error. Nor should they display a modal alert or open a window that displays the erroneous markup. An inconspicuous icon of some kind, perhaps in the browser status bar, would be enough. Two different examples of how that can be done are provided by the HTML Validator extension for Firefox and the iCab browser. My point is that it doesn’t have to be obtrusive. It shouldn’t be. If the user or developer wants more info, they can click the icon.
Some say that any browser vendor that implements something like that would lose market share. I simply cannot understand why they would, but if someone can prove that is what would happen, please do.
Leave most cowpaths unpaved
There are a number of proposed design principles for the HTML Working Group. Most of them make perfect sense, but I think a potentially dangerous principle is “Pave the cowpaths”, which says:
When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.
Depending on how you interpret that, it can lead to insanity such as the following:
Most authors use nested tables and spacer GIFs to control layout, so let’s make that the preferred layout method.
Using the same id value more than once on the same page is very common, so it should be allowed.
Nesting block level elements like h1 and p inside inline elements such as a and span is popular, so let’s allow that.
Luckily neither of those cowpaths have been paved in the HTML 5 specification, and as far as I understand it they won’t will be. However the explanation of this design principle needs work to avoid misunderstanding.
For the record, I do believe that if upon investigation a widespread practice is found to make more sense than what is currently in the spec, it should probably be adopted.
The HTML 5 Specification
Some of my previous worries and complaints are no doubt caused by me misreading the HTML 5 specification. My only excuse is that I find it very, very difficult to read since information that is only intended for browser developers is mixed with information that is important to authors (designers, developers, writers, CMS developers, etc.).
Having spent hours reading and re-reading the HTML 5 Working Draft, I now see that, except for it being hard to read for a web author, it really is a good start. I don’t necessarily agree with everything. There are some elements and attributes that I don’t quite see the point of, as well as some that I find missing. But overall I think the gist of the spec is fine. Basically, the information in it just needs to be presented in a better way.
Here are some suggestions that I think would make the HTML 5 specification easier to read and more useful to authors:
Do not mix user agent requirements and parsing instructions with author requirements. For authors to find the spec useful the parts that are relevant to them have to be cleanly separated, preferably into a separate document, even if it means more work for the editors. I know there are people who will be happy to help if it really proves to be too much for the two HTML WG editors to handle.
Include use cases and best practice examples for every element and attribute.
For elements and attributes whose misuse is widespread, provide examples and explain why authors must not use them that way.
Link less. Some sections are so cluttered with links that they are almost unreadable.
Provide lists of elements and attributes the way the HTML 4 spec does (elements, attributes).
The attitude problem
Specifications and design principles aside, I think a more disturbing issue is the really poor attitude some members of the HTML Working Group have. I’m not going to quote anyone or name any names, but it is something I felt from the moment I joined the working group mailing list.
Sometimes it is just between the lines, sometimes it is clearly expressed in writing. But the dismissive and condescending attitude towards accessibility and semantics advocates is quite tangible, and is what made me frustrated enough to write Help keep accessibility and semantics in HTML before making sure I had all the facts sorted out.
In my opinion this is the main problem with the HTML WG right now.
My personal reason for writing web related articles and tutorials is that I am really passionate about doing what I can to make the Web a better place that everybody can use. That thinking can be applied to many aspects of web design and development, but since this is about HTML 5 I’ll be focusing on creating markup in this article.
I want to improve the Web
I really want the Web to work better, for more people, than it does today. In order to make the Web a better, more accessible, user-friendly, and interoperable place, I believe that developers, designers, CMS vendors, and authoring tool vendors all need to be educated. We all need to adopt best practices in our work, and encourage others to do so as well. Writing tutorials is one way of doing that, but I don’t think it is enough.
Tutorials, blog posts, and books only reach those who find and read them. Unfortunately that means most people who work with the Web read little, if any, material that helps them improve their knowledge of HTML. I think that is quite obvious when you look at the current state of the Web.
So, while tutorials and guides do help, they only help those who want to be helped and know that they need help. They do not help people who want to do things right but are unaware that they are using HTML incorrectly. If they or their clients knew they were doing things wrong, many of those people would learn how to do things right. At least that’s what I, perhaps naively, want to believe.
Backwards compatibility and error handling
And that leads me to HTML 5, backwards compatibility, and standardised error handling. Backwards compatibility in browsers I don’t really have a problem with. I realise that it is necessary, though I don’t quite understand why browsers can’t treat new content (content that somehow claims to be HTML 5) in a different way than they treat current content. I am told that it is too expensive for browser vendors to do so, which sounds odd to me. But I am not a software engineer, so what do I know. They are probably right about that.
Error handling then. Yes, error handling is definitely necessary. People will always make mistakes, and standardised error handling is great for interoperability. But here is where my opinion differs from that of most browser vendors (and many others). I really am naive enough to think that browsers somehow making the user aware of errors in the markup will eventually lead to an improvement (and no, I do not believe that the W3C can force browser vendors to display error messages). Let me try to explain why.
Users will have one more way of judging the quality of the site they are visiting. They can already judge a site’s apparent quality by graphic design, content, and ease of use. I think they should also be able to easily judge the technical quality of a site. “But users don’t care about the code!”, you say. No, of course they don’t. That isn’t the point. The point is making them aware that they are using a site that is well crafted (or not, in most cases), and to make them start questioning why some sites have errors and others don’t.
All developers, not just the educated ones, will be able to get immediate feedback when they are using non-conforming (HTML 5-speak for invalid) markup. I believe that a decent number of developers will want to fix that, which probably requires them learning what they are doing wrong and how to do it correctly. A counter-argument to this is that developers should install browser extensions that provide this functionality. But most don’t do that, and never will.
I am not saying that browsers should stop rendering when they encounter an error. Nor should they display a modal alert or open a window that displays the erroneous markup. An inconspicuous icon of some kind, perhaps in the browser status bar, would be enough. Two different examples of how that can be done are provided by the HTML Validator extension for Firefox and the iCab browser. My point is that it doesn’t have to be obtrusive. It shouldn’t be. If the user or developer wants more info, they can click the icon.
Some say that any browser vendor that implements something like that would lose market share. I simply cannot understand why they would, but if someone can prove that is what would happen, please do.
Leave most cowpaths unpaved
There are a number of proposed design principles for the HTML Working Group. Most of them make perfect sense, but I think a potentially dangerous principle is “Pave the cowpaths”, which says:
When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.
Depending on how you interpret that, it can lead to insanity such as the following:
Most authors use nested tables and spacer GIFs to control layout, so let’s make that the preferred layout method.
Using the same id value more than once on the same page is very common, so it should be allowed.
Nesting block level elements like h1 and p inside inline elements such as a and span is popular, so let’s allow that.
Luckily neither of those cowpaths have been paved in the HTML 5 specification, and as far as I understand it they won’t will be. However the explanation of this design principle needs work to avoid misunderstanding.
For the record, I do believe that if upon investigation a widespread practice is found to make more sense than what is currently in the spec, it should probably be adopted.
The HTML 5 Specification
Some of my previous worries and complaints are no doubt caused by me misreading the HTML 5 specification. My only excuse is that I find it very, very difficult to read since information that is only intended for browser developers is mixed with information that is important to authors (designers, developers, writers, CMS developers, etc.).
Having spent hours reading and re-reading the HTML 5 Working Draft, I now see that, except for it being hard to read for a web author, it really is a good start. I don’t necessarily agree with everything. There are some elements and attributes that I don’t quite see the point of, as well as some that I find missing. But overall I think the gist of the spec is fine. Basically, the information in it just needs to be presented in a better way.
Here are some suggestions that I think would make the HTML 5 specification easier to read and more useful to authors:
Do not mix user agent requirements and parsing instructions with author requirements. For authors to find the spec useful the parts that are relevant to them have to be cleanly separated, preferably into a separate document, even if it means more work for the editors. I know there are people who will be happy to help if it really proves to be too much for the two HTML WG editors to handle.
Include use cases and best practice examples for every element and attribute.
For elements and attributes whose misuse is widespread, provide examples and explain why authors must not use them that way.
Link less. Some sections are so cluttered with links that they are almost unreadable.
Provide lists of elements and attributes the way the HTML 4 spec does (elements, attributes).
The attitude problem
Specifications and design principles aside, I think a more disturbing issue is the really poor attitude some members of the HTML Working Group have. I’m not going to quote anyone or name any names, but it is something I felt from the moment I joined the working group mailing list.
Sometimes it is just between the lines, sometimes it is clearly expressed in writing. But the dismissive and condescending attitude towards accessibility and semantics advocates is quite tangible, and is what made me frustrated enough to write Help keep accessibility and semantics in HTML before making sure I had all the facts sorted out.
In my opinion this is the main problem with the HTML WG right now.
Comments[ 1 ]
Spent hours reading and re-reading the HTML 6 Working Draft, I now see that, except for it being hard to read for a web author, it really is a good start.
Posted By: James Shirley - Blackpool Web Design
Post a Comment