CSE HTML Validator

Here's one view about what HTML5 might do to the web landscape

http://j.mp/10jGXM

Curt Cagle has another take on X/HTML 5. His perspective is very XML oriented. He has suspicion that the XHTML aspect will be dropped from the final specification. (He bases that in part on the poor documentation for XHTML.) I hope he is wrong.

http://j.mp/2GKBB5

I'm not sure that XHTML5 can really unhappen. Though we may end up with incompatible XHTML 5 implementations, in the absence of an adequate standard, which is effectively just as bad.

I think standards groups need to be small, dynamic and pretty autocratic. (To get anything done.) Above that the participants need to have wide understanding (real grokking) and wisdom. The article suggests lack in the latter area. Again I hope they are wrong. (This is hardly rocket science and it's say 10 years since we were going any place.)

MikeGale wrote:Curt Cagle has another take on X/HTML 5. His perspective is very XML oriented. He has suspicion that the XHTML aspect will be dropped from the final specification. (He bases that in part on the poor documentation for XHTML.) I hope he is wrong.

http://j.mp/2GKBB5

Interesting stuff, especially since I've been working on HTML5 support in CSE HTML Validator lately. I think I have preliminary support down now but would like to find more documents to test it with.

I was surprised at the length and detail of HTML5. When I printed it out (maybe not a good idea), it was almost 900 pages (though I did print two pages per sheet so only about 450 sheets of paper!). I was also surprised at the lack of XHTML information and discussion as I thought it would be moving in that direction as well. Lastly, I was surprised to see that some end tags are still optional.

I also implemented a floating point number parser based on the specs in HTML5, and that was fairly easy as it was detailed very well. There is a lot of good information in the specs that I can use to add checks in CSE HTML Validator.

But I definitely understand the problem with too many people trying to get things done... just look at the US Congress. Hopefully the HTML5 people can "pull it together" and make good progress.

I'm impressed with what you have done. It's sobering to think of 900 pages. It makes me feel more sympathetic to those putting it together.

I was aware that the team seemed to have compromised like in closing tags and XHTML. I'm disappointed. A little more rigor would be better for our future. But it's not done yet so who knows.

There are (in my view) important holes in what is being proposed. Like browser side includes... If this is all we get in say 10 years it looks like an opportunity for something else to eventually come along and clean up.

I see that Microsoft has released an experimental HTML 5 add on for Visual Studio.

This gives intellisense (code completion) support to the current version of the editing tools.

Here's a dump of some of the supported tags, in that tool:

a, abbr, area, address, article, aside, audio, b, bdo, blockquote, bdo, br, button, canvas, cite, code, command, datalist, del, details, dfn, dialog, div, dl, em, embed, fieldset, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, i, iframe, img, input, ins, kbd, keygen, label, link, map, mark, math, menu, meta, meter, nav, noscript, ol, object, output, p, pre, progress, q, ruby, samp, script, section, select, small, span, strong, style, sub, sup, svg, table, textarea, time, ul, var, video

I've picked out a few items in bold.

For more details http://j.mp/KfCif.

This, to me, is more evidence of a growing wave of support.

MikeGale wrote:This, to me, is more evidence of a growing wave of support.

Yes, it seems support is growing fast for HTML5 and CSS3!

how does the tags of HTML 5 differ from the previous ones?
i mean, what are the new tags added on it?
or is there any new tags has been added?

jlazo32 wrote:how does the tags of HTML 5 differ from the previous ones?
i mean, what are the new tags added on it?
or is there any new tags has been added?

Here is some good basic info:
http://en.wikipedia.org/wiki/Html5

And the differences from HTML 4.01:
http://en.wikipedia.org/wiki/Html5#Diff ... FXHTML_1.x

There are new tags like section, article, footer, audio, video, progress, nav, meter, time, aside, canvas. There are also new attributes, new form controls, and more. CSE HTML Validator v10 is planned to support them, as well as CSS3.

Here's something interesting.

It seems that Firefox, Safari and Chrome support the video element.

It also seems that they ignore a part of the markup that can prevent huge video files being downloaded (when the user doesn't want them).

See http://j.mp/8WZA5Z for a write up from the front lines.

As the guy says forget video, implementation is wrong.

Raises an issue. Both the specification and the implementers are hostile to a significant portion of the browsing public. It's not like this is an unknown issue. So why, oh why did they mess up here?

More to the point. Where else have bad mistakes been made in version 5?

It seems there's been some sort of blow up in the HTML 5 effort.

http://j.mp/7gOJur

(I'm not bothering to follow this in detail myself.)

Some calmer heads are saying that it's situation normal, so just live with it and carry on.

http://j.mp/7nBmjq

Looks like the overwhelming survey results in this post (most who responded are paying no attention to HTML 5) is not a bad idea, even though some aspects of HTML 5 are starting to become become widely available.

Pragmatism wins out, do what works.

It might be time to add another string to the bow if you want rich Internet applications. (jQuery gets you some of the way but be careful of the processor cycles that JavaScript steals, I've seen it slow down really powerful machines, like with that horrible and incompetent advertising code that so many newspaper web sites are using!!)

I recently updated CSE HTML Validator's website to HTML5. I think this was a good move as I used "stable" parts of the specification. This mostly resulted in a better design because many deprecated attributes were removed and replaced with CSS.

I was having a look at HTML5 today. For some internal work. Not for the open web.

Interesting.

Without some extra work (a JavaScript Hack, which bothers me) versions of IE prior to 9 don't work. It's an interesting effect. CSS styling applied to the new HTML 5 elements just doesn't work in IE8 and earlier. I don't do this often, each time I see it I feel a jolt! There is a "shim" to fix it so there is an answer of sorts. (1.3 K of minified JavaScript in the version which doesn't give you printed HTML5.)

I was also, today, looking at browser prevalence on a live site. (Just one day of data and it's fairly crude.)

I got:
All percents: IE 45.6, FF 9.7, Chrome 13.0, Safari 31.6, Opera 0.1. (IE versions as part of total (not of IE only) 5=0.1, 6=2.2, 7=5.3, 8=21.9, 9=16.1, 10=0.0)

For that site using HTML 5, new block tags for example, without extra measures (the shim), would lose me about 30% of visitors (or at least make their visit unpleasant).

This is the sort of thing that drives so much of what we do on the general web.

Sometimes a magic wand is what we want!

Hi Mike,

I don't like hacks either (it seems like sometimes you need hacks for the hacks). I use a small number of new HTML5 elements (like "footer") but I try not to depend on them or style them, mostly thanks to IE. In any case, I try to concentrate on content and functionality rather than style rather than fight all the different browsers and versions to try to get them to do what I want.

I think we're not the only ones who distrust hacks. I notice that this one isn't officially supported by a company, though companies have been involved in creating it.

Agreed. The right strategy is to do what makes sense given the browsers that will visit. (I sense that a growing band of developers don't do that. They seem to dash ahead using one technology and ignoring others. They test at the end. It doesn't work well on some browsers, they still release it. A substantial proportion of sites have regressed from this.)

When I took the time yesterday to rough out the impact of this, it made me realise that article, footer etc. can be easily sidestepped. It's easy to avoid their use altogether and work cross browser. Instead of a "footer" tag, use a div with class = "footer" and you're home and dry. Such an approach is also easily converted to the specialised tag should you need. (A Regular Expression replace may be all you need. Come to think of it RegEx would also provide an easy way to undo the markup if you already have it.)

Those bits of HTML5 are decoration and not essential. What concerns me more are the things I find important. The SVG, the programmability enhancements, the data caching systems, web-sockets... Those bits are genuinely powerful and enable things that are often not worth doing with a lesser system.

On that wand! It would be really cool if there was an update to IE8 at least. The update could extend that browser to do the important things. Practically it doesn't need to do all of HTML5. With a ruthless eye to costs it can just do the powerful extensions. That might be a big enough bite out of the problem.

(I know Chrome Frame has a shot at this, but in the process it reduces the capability of the browser (no COM objects for example). A political decision I imagine, maybe cost! If you look at discussions on it, you'll see that practically it doesn't really work, for reasons like that. I'm thinking of something that doesn't cripple the browser, but extends it to be more programmable and powerful! Widely deployed is critical too.)

MikeGale wrote:When I took the time yesterday to rough out the impact of this, it made me realise that article, footer etc. can be easily sidestepped. It's easy to avoid their use altogether and work cross browser. Instead of a "footer" tag, use a div with class = "footer" and you're home and dry. Such an approach is also easily converted to the specialised tag should you need. (A Regular Expression replace may be all you need. Come to think of it RegEx would also provide an easy way to undo the markup if you already have it.)

But I wonder what the losses would be with side-stepping those new elements. They are really there to structure the page better and help with various technologies like assistive software to make pages more accessible, but how are they currently used in real-life vs using the more generalized "div" and "span" elements? I haven't done much research on this but perhaps I should ask google and research it a bit.

MikeGale wrote:On that wand! It would be really cool if there was an update to IE8 at least. The update could extend that browser to do the important things. Practically it doesn't need to do all of HTML5. With a ruthless eye to costs it can just do the powerful extensions. That might be a big enough bite out of the problem.

An interesting thought... I suppose it could be released as a "recommended update" but even then I think many users would not install it... plus I don't think Microsoft likes to make significant changes to older browsers because you never know what it's going to break and some people might even be relying on "broken behavior" so fixing it would cause problems and complaints (some may say that the update broke it when it was really fixed).

I like the "auto upgrade" or "silent upgrade" technique, as long as it works well (it must be well tested!). But if that is not available, like in IE, then I think the best way to get people to upgrade is to "force" them to by not going through the trouble to support older/dying browsers. When enough developers do that, then the old browser users may decide it's finally time for an upgrade. Of course the developers may lose or anger some visitors in the process... so I guess it really just comes down to a your typical cost/benefit analysis of the costs of not supporting older browsers vs. the benefits... and if not enough developers drop old browsers, then those who do will be faced with more of a consequence because less people will upgrade. So maybe the point of all this rambling is that all a web develop can really do is to just let time take its course and hope that older browsers die quicker.