HTML 5. New Elements, Attributes, Problems

Posted: January 27th, 2008 | Author: Ben | Filed under: Web Development |

I’ve been reviewing the document at the w3c about the new elements in HTML 5. I won’t repeat what the document covers, so read it for yourself at http://www.w3.org/TR/html5-diff/. This article is aimed at discussing the new elements and attributes used in the new version. Looking at the additions from the perspective of a marketer rather than an academic I can see several issues I would have.

Just as a side note, I am aware that browsers released in the future will continue to support HTML 4 and other previous versions, so I’m not trying to encourage any kind of panic. I’m simply imagining using HTML 5 (based on the linked article, above) for the things my team and I do every day.

Tracking
There’s a new attribute for the a and area elements called ‘ping’. This is used for tracking, so when a link is clicked the URI is pinged at the same time. This is designed as a simpler alternative than the current method that involves sending the user to a page that tracks the click and redirects to the content page. This also gives the user the ability to switch tracking off. I know that absolutely none of my clients would appreciate this as a feature (why would they opt for profiling a fraction of their audience opposed to all of it?). Another aspect of this would mean that users would be made more aware of website user tracking. This is not necessarily a bad thing, but I could imagine plenty of confusion for a lot of users in determining the difference between regular audience trackers and snooping on an individual. How would you explain tracking to your aunt without her feeling as if her privacy was being invaded?

Forms
HTML forms are getting some fresh air. New input types support inserting time-related data, URLs and email addresses. Added to that is the attribute ‘required’ that’s been thrown into the mix. This is a step in the right direction given the number of bad JavaScript form validators in circulation, but the helpfulness of such an addition is limited to how browsers implement the changes.

If I were to create a simple form asking a user for a name, email and serial number I may run into some problems. For the ‘name’ field I would just add the required attribute on a normal text field as a name is going to be text: there’s nothing else to validate. The email field would use the new input type of ‘email’, and also the required attribute to ensure the data was indeed an email address. But what of the ’serialNumber’ field? There is no input type for my serial number, so in order to properly validate the data as being a valid serial number I’d have to use a regular expression within a JavaScript function to check that the field value follows the format I expect. I’d be mixing native browser data validation with supporting JavaScript functionality, which I think is potentially very messy!

I think the addition of the time and date input types are really useful. It means users can select dates from a familiar interface. I think the email and URL field types are an attempt to bring data validation to the browser, and given the complexity and the range of data that often goes into forms I think that this could prove difficult.

The good bits
There are some really nice additions to this version of HTML. Making the embed tag a w3c recommendation will mean easier Flash implementation in the future.

Header and footer as elements will possibly confuse new web developers with both ‘head’ and ‘header’ being used in the same document but for different uses. They will probably be more useful for SEO reasons, as I don’t see why developers would stop using div tags with a ‘header’ or ‘footer’ id attribute.

The nav tag will be great for improving a web page’s accessibility offering, since it enables the developer to indicate where the site navigation sits.

I’m interested in the canvas element, and what that will mean. It is meant to provide a space for rendering media on the fly and spawning on-page games and graphs.

There aren’t many new features that I saw that are geared-up towards AJAX fans, however the ‘event-source’ and ‘output’ elements might prove to be useful.

Back with forms, there is now a ‘form’ attribute to be used within fields that means a single form field can belong to more than one form.

No more frames!
Framesets and frame elements have been shown the door in this version of HTML. The Iframe element still exists, but the w3c found that the standard frame elements were decremental to accessibility so therefore scrapped them. I haven’t seen frames used in quite a while, but I do remember them being an important part of my first few websites in the 90s. I’ve also seen framesets used by SEO companies (the SEO content would go within the ‘noframes’ tag). I think scrapping frames is a good move, but it could really help accessibility.

Problems with HTML emails and CMS content
One thing my agency do quite a lot is build HTML emails for subscribers to our clients’ brands. With the end of the width and height, background, and most importantly the style attributes it’s going to be hard to build HTML emails for applications that have poor HTML parsers. This includes Hotmail, Gmail and Yahoo! online email readers that all parse HTML email content on the server before it’s displayed in the browser to prevent the content impacting the application interface. I agree that in principle, all style information should be kept out of the HTML template - this is the job of CSS. Although building emails is a big part of my team’s responsibilities and the abandonment of the inline style information is going to either force the email applications to be more compliant or is going to make life a living hell for the guy in my office who builds these emails!

Also I’m writing this in Wordpress: one of many CMS’s available for free or commercial license and one of millions when counting the bespoke CMS solutions created all the time. To allow authors using these CMS’s to control how their information is displayed (such as alignment, colour etc.) the style attribute would have to be used. I cannot see how a CMS could be efficient in managing style information as a separate entity to the content being written given that the style attribute is to be pulled as an HTML standard.

My thoughts
I think the w3c have been careful in analysing popular use of HTML and how they can improve it. Although I think the developments of HTML in this version may be trying to become too involved directly with the user that might create a lot of poorly implemented web pages. I also think that dynamic content created with CMS applications and such have not been considered properly.

I definitely agree with attempts to improve accessibility, and the inclusion of better data descriptors will no doubt help that effort. However, I doubt that the ping attribute will prove popular with developers unless users come to expect to be able to choose whether they’re tracked or not; I question the need for browser-based form data validation; I’m also unsure about the decision to rely more heavily on CSS over inline style information.

---