I’ll admit I have not taken a great deal of direct notice in the development of the HTML5 specification by the WHATWG. I have read over the specification from time to time, that’s about it. It’s not that I’m not interested; it’s been a question of resources and time. However with the W3C HTML working group announcing the opening up the process of the draft development process and the merging of their current effort with the HTML5 spec, this has brought the process back onto my radar again. Okay maybe a little belatedly, since this happened in late March (2007).
The HTML5 draft is interesting. I agree with it in parts, other sections I just think are a waste of time, but that’s not the topic here, maybe I’ll discuss this later.
This brings me to an interesting point on the way we develop such specifications. In this case, I’ll use the b and I elements as examples to state my case.
I’ve heard the rational semantic and sanitised arguments for the b and i elements from Lachlan Hunt and the WHATWG. I can understand why, and I too can give good instances where I have used a span instead, mainly to avoid the old b and i elements, which under this proposal would have the meaning I wanted to assign.
However, let’s step back from this and look at the uninformed web designer; the uneducated designer. These people seem to be the bulk of the industry :). Now that’s not us. It’s the other guy. Right?
They are out there, they don’t read blogs, and they rarely attend conferences or events. To them web design is just a job, not a passion. These people may look at a standards reference site once and a while. They see the elements, but don’t really read about them.
They are the practical users of web markup. They use markup for what it produces in terms of visual output; not what was intended. Typically for example they see the blockquote element as a way to indent the text. Likewise can be said for the presentational italics. H1-H6 makes the font bigger; and the list goes on. Basically they have no need for semantic pages. Their clients or employers don’t want or need them to produce anything close to web standards or the semantic web.
There are two main schools of opposing thought here:
- Web designers should learn the new methods and techniques or get out of the industry.
- Web designers should do what they want. The specifications are just guidelines anyway. They can use the markup to get the results they want. What could here is the results, not how they achieve them.
With the reviewing of the next standard of HTML, we have a very real opportunity to take into consideration the outlook of the uninformed web designer and maybe look at all the elements and see if we can move them forward. However we have to do this without inserting meaningless elements just for the sake of it, but also take into account the legacy “street” meaning of the elements.
I’m not singling out the b and i elements. However for a long time they have come to mean, via word processing mainly, bold and italics. If we change the common meaning of these and other elements mid stream and start telling people that they mean something else, this is going to cause confusion. Confusion is bad. What we have here is an established baseline of differing sematic meaning of the functional and practical use of the styling method verses the element use proposed.
Even if HTML editor vendors and browser manufactures where to choose tomorrow to change the common meaning of these and other elements, it’s not going to remove the common public meaning from this type of presentational functionality.
People may not like it but the street will find its use for technology; you have to live with it. What we really need to do is keep it simple and remember people may not look at HTML like we do.
I can hope that this has already been discussed to death several times over, but I would just like some consideration of the “in the wild” (real world) instances on how elements will be used. Not the purely standards based academic discussions that seem to be happening with a consideration given to backward compatibility.
We need to look at what the lowest common denominator of the web design audience is going to do with the next version of HTML. How they are going to approach the output of their favourite HTML generator, text editor or the like for better or worse. What we intend for use is meaningless in some circles.