There's been a lot of discussion around HTML 5, what it should be, and what it shouldn't be. Crockford's post outlines his perspective on things in typical Crockford-fashion. I also have my own ideas about what I'd like to see in HTML 5. I shared this internally at Yahoo!, but thought I'd put it out there for others to see as well.
My disclaimer to this list is that I do not have the solutions to the problems. Perhaps with time, I could come up with some proposals and such. However, my point is not to push forth my own ideas as solutions, but rather to point out the problems I run into frequently. In my mind, it's solving these problems that should lead to HTML 5.
text-align: -10000px to hide things visually but allow screen readers to read them. This goes double for dynamic portions of the page.<script/> element just isn't cutting it anymore.<module/> tag solves. I'm not saying it's the right solution, just saying it is an identification of the problem.These are the issues that tend to bite me on a regular basis, and I think they're annoying to a great deal of web developers. I think the next version of HTML should first aim to ease some of the pains we currently have rather than being an end-all be-all wishlist. Let's get the simple stuff figured out first before moving on to more complex things.
You're seeing only extreme end of accessibility. It's not just blind people!
What about people with just poor vision? They can't read small/low-contrast image labels, but they don't use screen readers.
And motor impaired? They may have difficulty clicking fancy buttons and menus, they might use keyboard and get confused by invisible content stuffed for screen readers...
Anyway, the accessibility problem is mainly caused by lack of/lousy implementations in system APIs and screen readers. They should be reading media=aural or media=speech and respect speak:none, but because they take screen reading too literally, they step onto screen styles and page display.
...and it's CSS, not HTML issue anyway.
2. Already in HTML5.
5. There's scoped style element. Scripts aren't solved yet (it's tricky, unless you use frames).
6. Again, you demand HTML to do CSS's job.
I'm actually talking about accessibility in general. Markup can help with all of the problems you mentioned. Those with poor vision use screen magnifiers, which need more information to help the user. The motor impaired would benefit from a better way to describe and reveal keyboard shortcuts.
I don't believe that accessibility is mainly a CSS issue. Expecting screen readers to interpret all the different and cascading styles on an element is ludicrous. Having simple markup indicating how an element of the page relates to the everything else is the easiest way to do this.
For sprites, it is currently accomplished using CSS because that's the only way to do it. There's no reason the <img> tag shouldn't be able to do that natively.
And I realize some of these are already being addressed in HTML 5. I'm just saying, separate from what's already there, this is where I'd like to see it go.
Your second point is addressed, at least in part, by XForms. I'm sure you know that they are a planned part of the XHTML2 spec. What do you think of them as a solution to these common problems?
Also, form control I want to see natively in HTML the most is probably the slider. Seems to be a basic feature of desktop applications that aids in usability and intuitive interfaces, but was just left out of HTML.
I'm a big fan of XForms except for the fact that it's never been implemented and probably never will be.
Better Accessibility: Your specific issue is related to CSS, not HTML, and is somewhat solved by the 'content' property which can be used to visually replace the content of an element, so you don't have to use the off-left trick, or any other trick, to hide it.
Better Form Controls: The Web Forms 2 specification, which will be incorporated into the HTML5 spec later, provides many new form controls. Opera 9 has already implemented them, so you can try them out today.
More UI Elements: HTML5 addresses much of these needs by providing drop down and context menus by extending the menu element. There's also datagrid, meter, progress and many others.
Different Behaviour Attachment: This will be handled using XBL.
Style and Script Containment: The style element as been extended with a scope attribute. In new UAs that support it, the styles will be scoped to the containing element. XBL will also address the scriping issues.
Built-in Sprites: This is a CSS issue, not an HTML issue.
I forgot to say thanks for your feedback and that you're welcome to send more by joining the HTMLWG or WHATWG mailing lists.
http://www.w3.org/html/wg/
http://www.whatwg.org/mailing-list
Perhaps the text-indent issue is CSS-specific, but what about better support for keyboard shortcuts? There's no way to use CSS for that and writing JavaScript to handle all possibilities becomes really annoying.
I'd also argue that sprites are not a CSS issue and are, in fact, an HTML issue. To me, this is the same as the start attribute on the proposed <video> tag. With that attribute, you're specifying an offset inside of the media that should be displayed. To me, this sounds exactly like how sprites could work on the <img> tag.
I don't believe XBL is really handling my ultimate issue: different ways of downloading JavaScript. As long as the <script> tag remains a blocking operation, we're going to have to jump through hoops to get UIs that are responsive as soon as possible.
The <script> element has a new async attribute to allow asynchronous execution and downloading of the script.
<quote>I'm a big fan of XForms except for the fact that it's never been implemented and probably never will be.</quote>
Have a look at http://www.w3.org/MarkUp/Forms/wiki/XForms_Implementations
You'll note the lack of web browsers on that list. Unless it exists in a web browser, I have no use for it.
Nicholas, I really like this post. I think that HTML5/XHTML2 are really going too far in some directions, when there are actually a very small number of specific needs that web developers have...for example, a straight-forward way to semantically code image replacement for headers. Maybe what I envision is more HTML 4.5.
I don't want to split forms into a separate spec, so I really have no interest in learning about XForms. I want a few basic changes to the forms we have now - multiple files, CSS styling.
I want a CSS (and thus not non-semantic) solution to having separate images for the corners and borders of block elements, so that block elements can be liquid in size and still look sexy.
My total wish list is about five items long. Yes, I know that I don't have to use new features that I don't want, but it's those unwanted new theoretically-good features that are preventing the quick implementation of things I actually would use on a daily basis.
There are a couple of web-implementations of Xforms. They are more like band-aids at this point, but they are also the type of things that, if used enough, would prompt browser vendors to incorporate them natively.
Firefox: http://www.mozilla.org/projects/xforms/
Crossbrowser JS implementation: http://www.formfaces.com/
I'm not convinced XForms is going anywhere. After all this time, there's still not any interest in it except in a purely academic or non-web environment. To convince people to use it, at least IE and Firefox would have to implement XForms. In the meantime, there's a lot of legacy forms that won't get upgraded. Seems like a lose-lose to bet on XForms at this point.
Conceptually, it would be easy to add the necessary tags to create a menu bar! "menubar" and "ml" (for "menubar list") would work nicely. "li" is already available for "ul" and "ol" lists, minimizing standardization effort. Note that I'm not showing details like CHECKED or DISABLED for menu items -- these could be added as part of the tag definition or they could be implemented in CSS.
A tag (such as: <tag>) is shown between double-dashes (like this: --tag--) since HTML is stripped from these postings:
--menubar--
--ml label="Edit"--
--li--New Window--/li--
--/ml--
--ml label="Topics"--
--li--Planes--/li--
--li--Trains--/li--
--li--Automobiles--/li--
--/ml--
--/menubar--
As with other list items you could surround each entry with an anchor providing a hyperlink to the identified destination. I'd like to see something like that.
Expanding on my thoughts (above), the HTML 5 proposal for menus is very involved and appears to strain the principle of HTML as a simple & easy markup language. Offering a simple equivalent menuing structure in addition to the proposed complicated version would assist in adoption, training, and implementation of menus. Combining existing linking mechanisms (anchors, forms, etc.) into the proposed "menubar & ml" format would be beneficial.
Post Comment
Your e-mail address will never be shown, only your URL. Please, no HTML in your comments, as it will be automatically stripped out for security purposes.