Do not drop html elements and attributes I like!

[fprog]

Create a "HTML5 Transitional mode"
and in that mode drop the entire section 3.4 and 3.5,
so that it's FULLY HTML4 & XHTML backward compatible.
Otherwise the specifications looks just fine.

The section 3.4 and 3.5 is COMPLETE NON-SENSE to not say the least.
http://www.w3.org/TR/html5-diff/

And that is to not say completly aggrevating, I understand that you wish to promote CSS for styling and this is a nice goal, but lots of people, think otherwise or have to maintain sites which are neither compliant HTML4, neither compliant XHTML1.1, but could be FULLY HTML5 compliant without those section 3.4 and 3.5 out of the box, due to common hacks to work around legacy browsers.

i.e.: They are somehow using features of HTML4 not allowed in XHTML or vice-versa and their web pages while not validating works in major browsers (Opera, Safari, Firefox, Netscape, Chrome, IE6, IE7).
The HTML4 validator complains about the XHTML part, while the XHTML validator complains about the dropped feature of HTML4 (written in XML part).

We want a HTML/XHTML standard that is forward and backward compatible, that can deal with future needs, without breaking old browsers unnecessarly.

Basically, an HTML5 document should be fully handled by a "new browser" while a JavaScript library like jQuery, Mootools or Prototype could "add the missing behavior" to old browser like IE6 gracefully.

That is I can include in my page "legacy HTML4" that WILL WORK and validate out-of-the-box in fully compliant mode with HTML5 content. PERIOD.

Don't use guys just get it, there are tons of developper out there that must maintain legacy sites (95%+) and we need a standard were we can "gradually" upgrade pages to HTML5, while being FULLY compliant and validated.

More over if I have a HTML5 document it should degrade gracefully
to IE5, IE6, IE7, old version of Netscape 4 and 6, Safari, Opera, Firefox.

IE6 is still used by 24-36% of the population that won't or cannot upgrade to Windows XP SP2/Vista or are using 95, 98, ME, NT/2000 or Windows CE.
Are in locked down business environment (can't install or upgrade anything) or are using legacy embedded devices.
[http://www.w3schools.com/browsers/browsers_stats.asp]
[http://www.w3counter.com/globalstats.php]

According to a recent survey by Opera/Mamma.
[http://dev.opera.com/articles/view/mama-w3c-validator-research-2/]
[http://www.webmasterworld.com/html/3767142.htm]
[http://dev.opera.com/articles/view/mama-the-average-web-page/]
[http://dev.opera.com/articles/view/mama-key-findings/]
[http://devfiles.myopera.com/articles/532/elemlist-url.htm]
[http://www.thecounter.com/stats/2008/October/browser.php]

* 62% of websites are HTML4 transitional or lower (HTML3).
* 4.13% of web pages validate
* 85% of pages render in quirks mode
* <table> is used 18% more than <div> probably for layout as it's the default layout export for most HTML editor including Photoshop/Dreamweaver, etc.

* 51.0% of pages have a doctype
* HTML doctypes outnumbered XHTML doctypes by about 2 to 1
* Just under half of all pages displaying validation icons actually validate
* 80.39% of pages use CSS
* 74.58% of pages use scripting
* 3.20% of pages use XMLHttpRequest
* Average page size is ~16,500 characters
* The 3 most popular markup elements are <a> (5th most popular out of all elements), <img> (7th) and <table> (8th)


If you want "accessible table layout" as implicitly suggested in Section 1.4 just write this and be done with it:

<table irrelevant='true' border='0' cellspacing='0' cellpadding='0'>
some layout stuff
</table>

Easy fix, everyone's happy. If the customer later needs a more "flexible layout", they can always hire a CSS guy to do some <div> layout that will iron out all the quirks to make it work with IE6/7.

Unfortunately, on average, if they are not at least 2 full-time Photoshop guy in a company doing web development then you can be sure their layout are most likely table based or they bought an off-the-shelf CSS skin/layout to start with or they used something like RichFaces or similar.

Just the fact, that the BBCode support <b><i><u><s> should give you some clue about removing <u> and <s>. They are the first tags learned by any HTML newbie!!!

Also I never understood why I should put an alt on a GIF "pixel spacer"
to be fully compliant... <img src='s.gif'/>

By default, if there is no ALT, then the image is "irrelevant" period;
especially, if it's a "small" GIF file.

While any new development mainly do not contains <frame> some legacy applications do and must continue to be supported WITH new features.
Personally, I never wrote any code using <frame> for the last 5 years, but do maintain old web sites content that use them. Almost all new developments nowaday use <iframe> or AJAX loaded <div> content.

Why should I choose between <u><font><center> and <input type='date'/> ?

Tell me what's wrong with this old HTML legacy code + HTML5:

<html xml:lang='en' lang='en'>
<head><title>Some title</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" /></head>
<body bgcolor='white'><div align='center'><center><table border='0' cellspacing='0' cellpadding='0'><tbody>
<tr><td><form id='f' name='f' method='get'>
bla<s>bla</s>bla <font face='Arial'>great!</font> <u>duh</u>
<input name='d' type='date' />
<input name='s' type='submit' value='Submit' />
</form>
</td></tr></tbody></table></center></div>
<script type='text/javascript' language='JavaScript' charset='utf-8' src='input_date_fix_lib.js'></script>
</body></html>

Give me one good reason why I could not maintain a page like this by replacing the input text field with type='date' and some glue javascript lib for legacy browsers without having to "rewrite it" completely?

So please stop making our life miserable for once and all.

Stop being purist and be pragmatic for god sake.

If you just don't "get it", I will force you to come and work here for 6 months for some of my clients until you "suffered enough" to understand why backward compatibility is EXTREMELY IMPORTANT and that is if you have any hair left after pulling them all out in tears.

You might want to read this blog:
http://blogs.msdn.com/oldnewthing/archi ... 99999.aspx

http://www.google.com/search?q=site:blo ... patibility

Don't make a strict standard that will only validate 5% of all webpages make one that works for the majority and that can gradually be promoted to pure CSS website, if desired.

Sincerely yours,
Fred.

[fprog]

For those who are still stuck with legacy sites...

I found this nice article on DZone, so if one of those libraries
could emulate some HTML5 for IE5/6/7. then I think we are in business...

http://code.google.com/p/base2/
http://code.google.com/p/ie7-js/
http://dean.edwards.name/IE7/

Fred.

[SneakyWho_am_i]

JAB, in my opinion if you're going to create an element called "noscript" that will only appear if the browser doesn't support scripting then you're assuming that everyone will either be able to execute your script, or display the noscript message.

That sounds reasonable, but there are cases when this just doesn't work out. For me it's usually during a testing phase if I code an error into javascript. It seems better practise to me, to have a regular element such as a div which is visible by default and warns about javascript. Then you can use javascript to hide it - that way you know that that message absolutely will display unless the script executes successfully.


fprog, the html5 standard is pretty backwards compatible. By writing an html4 document and then changing only the doctype I can make it validate in the html5 validator.
The new standard is very compatible with what real authors who don't know or care about validation are doing right now. For example, the html5 validator doesn't care if you mix "self-closing tags" (whatever they're called) with unclosed elements. That seems really, really silly because if I'm going to start closing those empty elements then I want the validator to catch the ones I missed. Then again, I write XML and those numbers you pointed out show that most people don't. Most sites regardless of doctype do mix up the xhtml and html style because the author doesn't know any html and is just copying and pasting markup from other sites. many of the sites which Opera/Mamma passed over will have been seen as invalid because they don't know whether they're xhtml or html4.

They don't need to write a standard which will ensure that a lot of current pages validate. The fact that 95% of pages do not validate just shows that you can still write pages that don't validate and while it does matter, it's not the end of the world.



That code which you're asking about, your example....
First of all I find it very hard to read, largely because there's a big messy table and a lot of other clutter in the middle of it.
The font element could theoretically cause problems across character sets and other junk, but my personal problem with it is mostly that I make sites now with more than one page. You might like the error fonts to be red today but what if people aren't reading the errors? Do you want to go through and rewrite every single one of your pages just because you decided on the wrong error colour scheme? I would probably do it like this:

Code: Select all

<html lang='en'>
<head><title>Some title</title>
<link rel="stylesheet" href="foo.css">
</head>
<body>
  <form id='f' name='f' method='get' action="">
    <fieldset>
        bla<s>bla</s>bla
        <span class="message">great!</span>
        <span class="important">duh</span>
        <input name='d' type='date' />
        <input name='s' type='submit' value='Submit' />
    </fieldset>
  </form>

<script type='text/javascript' src='input_date_fix_lib.js'></script>
</body></html>

It would help if we knew what the form was for but hey ... You used an underline. I like underlining things but what if your customer decides next week that the underline makes those parts confusing or hard to read? I'd rather just change the stylesheet than have to go through and re-do every single page.

What harm does it do? That depends. Google takes no meaning from the "font" element and neither do I. When we start using elements like center and font, our documents get heavier and our meaning gets lighter.



My particular page may not validate. So what?
If you can make the invalid page a good page, it's still a good page. If people are using it and it's only HTML3 or HTML4, maybe there's no reason to switch to HTML5 at all. New projects might use HTML5, but I see no reason to "upgrade" old ones.

I don't think that the standard is about what people MUST do, just about what's best (and not unrealistic) in the long run.