HTML5
I am not impressed.
While there are some handy new elements such as nav (for navigation menus), video and canvas, it also includes some elements which have no contextual meaning at all, and have been deprecated since HTML 4.
Remember how much effort standards evangelists put into the removal of <b> and <i>? Well… they’re back. i, b.
What’s doubly confusing about this is that there is no clear contextual difference between the new definitions of <i> and <b>, and the new element m.
<m> is defined as a span which is “highlighted”. That is not a job for HTML. It is a CSS issue! This can already be handled through <span class="highlight">code such as this</span>.
And where are the handy new form elements? I had been looking forward to at least a <date> input type, so I would not need to always provide a JavaScript calendar or a set of three select-boxes to handle day/month/year. No – nowhere to be seen.
Not impressed.
B and I were never deprecated. They are very much allowed in HTML4 Strict.
One use-case for M is that users can jump to highlighted text spans. In speech media you can’t glance at a page and find visually highlighted text. Also remember that CSS is (supposed to be) optional.
The handy new form elements, including a date type for INPUT, is to be seen in WF2: http://www.whatwg.org/wf2
You’re right, zcorpan. I’m still not sure that there is a marked difference between ‘b’, ‘i’ and ‘m’, but you’re right that they are not deprecated. I guess I’ve been treating the separation of structure and style as Law.
I’m looking forward to seeing how the WhatWG recommendations come out (I see you are in their list of acknowledged contributors).
As a JavaScript developer, I’m also looking forward to trying my hand at making the new Form elements work even in current browsers.
“As a JavaScript developer, I’m also looking forward to trying my hand at making the new Form elements work even in current browsers.”
Great! 🙂 This may be of interest: https://sourceforge.net/projects/wf2/
It’s interesting to see that the presentational elements are being kept on but I would agree with you Kae in that they are practically deprecated now even if they are valid html..
All’s going well here in England just tryin to find work!
Kae, I’m right there with you on separations. But I think that to understand the need for ‘b’ and ‘i’, we must turn the css off in our heads. Multiple times recently, I have found items where ’em’ does not fit, yet wrapping in a ‘span’ seems too generic. In fact, ‘i’ has turned out to be the proper solution in each case (remember to keep css off in your head).
If you read the descriptions of these two elements in the draft, it may make more sense. The document accurately clarifies where ‘strong’ is proper and ‘b’ is not, and likewise for ’em’ and ‘i’. I believe that the default browser/css styling of bold for strong and b, and italicized for i and em, might be adding confusion to the issue. There are good, semantic, non-stylistic reasons to use b + i in place of css, and strong + em.
Complex: you bet. Unfortunate, I agree.
I’m with you on the ‘m’ element being too niche for inclusion, but what upsets me the most is that it sounds exactly like ’em’. That’s going to be no fun, and it is a serious oversight. Using ‘marked’ or an abbreviation consisting of more than one letter would solve this issue.
Finally, on the ‘date’ idea: I really hope that this is added to the spec. I’m writing a parser/regex right now to accept a common-language string as input for date and/or time. The current form is a javascript date picker attached to a date field, alongside a manual-entry time field and and am/pm drop-down field. It seems so unnecessary.
I’d also like to see rich text editing on textarea (only for minimal structure/styling and adding hyperlinks–no full-blown word processors here), although it seems that this will continue to be a browser initiative.
Kae, I must say I’m with you, but then I was horrified on the decision to bother with HTML 5 at all – the two seperate and contradicting standards are just making the web a horrible place to live (HTML and XHTML) – to now run HTML5 alongside is just worse.
I really was (as a programmer) looking forward to a world where all (X)HTML documents were valid XML schemas. Now look what they went and did.
James, I think HTML5 was the only sensible solution to the problem that is XHTML2.
In the “relationship” section, it’s stated that HTML5 is considered to be the successor of both HTML4 and XHTML1. Hopefully, it is more XHTML1 than HTML4.
I can’t find any reference in the spec as to whether the bad parts of HTML (specifically, optional closing tags) will be kept, but hopefully, they are no longer optional. Also, /please/ let everything be lowercase…
Actually, you can do xml/xhtml-style self-closing tags (like [br /] ), but as I understand it this is optional in html5.
“I can’t find any reference in the spec as to whether the bad parts of HTML (specifically, optional closing tags) will be kept, but hopefully, they are no longer optional. Also, /please/ let everything be lowercase…”
Some tags are optional, just like they always have been in HTML. Why would this be a bad thing?
HTML has always been case insensitive. Why should we suddenly force authors to write their tags in lowercase?
if closing tags are optional, then the browser must be more complex (in order to figure out if a tag has been closed or not), which can encourage bloat and browser bugs.
as for the uppercase/lowercase thing – again, it would make browser-development easier, but it would also make it easier to work with the HTML source without feeling like you’re being shouted at all day.
XHTML1.1 appeared to me to be on the right track – stricter, and more sensible.