Comments on: HTML5

By: Kae Verens

Kae Verens — Sun, 19 Aug 2007 07:14:12 +0000

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.

By: zcorpan

zcorpan — Sat, 18 Aug 2007 18:52:45 +0000

“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?

By: Bradey

Bradey — Sat, 04 Aug 2007 00:25:57 +0000

Actually, you can do xml/xhtml-style self-closing tags (like [br /] ), but as I understand it this is optional in html5.

By: Kae Verens

Kae Verens — Wed, 01 Aug 2007 15:50:46 +0000

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…

By: James Booker

James Booker — Wed, 01 Aug 2007 14:58:14 +0000

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.

By: Bradey

Bradey — Wed, 01 Aug 2007 09:01:13 +0000

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.

By: Aaron Mc Adam

Aaron Mc Adam — Tue, 31 Jul 2007 10:19:45 +0000

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!

By: zcorpan

zcorpan — Fri, 27 Jul 2007 15:22:02 +0000

“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/

By: Kae Verens

Kae Verens — Thu, 26 Jul 2007 13:43:54 +0000

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.

By: zcorpan

zcorpan — Thu, 26 Jul 2007 13:17:10 +0000

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