CSE HTML Validator

According to http://wiki.whatwg.org/wiki/FAQ#When_wi ... inished.3F

It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn't mean you can't start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.

Wow! 2012! That's about 4 years away.

So, I'm curious, it also says some parts are relatively stable and can be used today. Is anyone using any HTML 5 specifications yet, for "real-world" pages? If so, which parts of HTML 5?

CSE HTML Validator does not yet include any HTML 5 specific syntax checking, but this should be added as HTML 5 becomes more used.

Not using it yet.

It looks likely that IE 8 will support parts of it, but I have no idea what. Also no idea about other browsers.

It will come down to the normal issues, like prevalence of User Agents that handle it, graceful degradation...

At some point I expect to give it a try, if it has compelling features, that will be sooner.

The explicit policy to prevent easy use of custom markup disappoints me, though I have an idea of what they're worried about. Currently markup is crippled for some very attractive potential uses, which causes extra work.

(I'd also like to see ways of getting compiled code (about 1000 times faster than JavaScript) and some controls that are missing. That might be in there but I didn't see it.)

If CSE handles it when I run my tests that would be very welcome.

There are two features in X/HTML 5 that already interest me.

One is Server Sent Events. Apparently already available on Opera. This appears to open a communication channel from server to browser that closes when the page closes. That seems to overturn part of a design which has really hampered web development. (Sessionless communications.)

That warrants investigation at some time. I will be looking at it.

If others are in the same boat, there is a way to add new tag categories and tags to CSE so the product already has a way to handle the two new standards (or the bits of them that are interesting).

MikeGale wrote:If others are in the same boat, there is a way to add new tag categories and tags to CSE so the product already has a way to handle the two new standards (or the bits of them that are interesting).

Hi Mike,

It would be helpful if you could let me know what bits of HTML 5 you decide to use (when you start to use them) and what you'd like to see supported in CSE HTML Validator (like what tags to support). Thanks!

Here's a quick take on use of XHTML 5. It's not a proper plan.

I'll be using XHTML 5 and may not use HTML 5 ever.

There are two things that do a job I'm already tackling, but do it much better, these are:
meter
time
These I may deploy very soon, the browsers will just ignore them so I can get the benefits now.

In the past I have written a processor that turns svg into a png, so I'll probably have a look at
svg
even though I don't expect immediate deployment.

There is a group of very interesting things. They are worth playing with but can't be deployed until there is a project targeted at people who actually have a capable browser. (While it's technically possible that happens soon, I expect a long wait.) These are:
input extensions (range = slider....)
menu and command
details
datagrid
progress
canvas

mark is a great idea, but they may still be haggling about whether it called mark or m. If the latter I would hope that it dies, stupid name. That would also be used if a target community can see it.

When it becomes widespread and most people have it, it will be a pleasure to introduce
header
footer
aside
nav
article
section
and maybe
video
audio
figure
I'm not sure whether I'll ever use
dialog it may have an unsatisfactory design at present, so who knows

I haven't mentioned the cross-document listeners, server sent events and long polling. At introduction those will (I'm pretty sure) all be used from code. (Some tags that use this stuff hard wired in some way are entirely likely but may take a while.) Abuse by marketers and criminals might sink these ideas.

I was just reading up on this tonight. I agree, 2012 is a lifetime away. http://wiki.whatwg.org/wiki/FAQ#When_wi ... inished.3F

I guess I'd have to see the browser support and what breaks using it. I'm using xhtml strict right now. My code validates now, but we have reports by a 3rd party that I have less control over. I guess I'd start by just changing the doctype and add new features as time permits.

Browser support for html5.

So far I stupidly try to make my code work with IE5. Found out a month ago that a code change I made caused JS errors for one user and they couldn't use one computer with IE5, but was able to use IE5.5. Officially we don't support it and they do get a header that says to upgrade but apparently that isn't drastic enough. Just read today that IE6 is too old (~8 years) and they're trying to get people to upgrade. Holy crap, IE5 is 10 years old. Guess it's time to break is so they can't log in any more.

Interesting: Writing HTML documents on W3.org (Albert, note 8.1.2.4, certain tags can be omitted. Good luck validating that.)

Here's a test page: http://www.brucelawson.co.uk/tests/html5-elements.html but it uses JS to help support older IE browsers.

Normally I formally define the target audience for a site.

The definition includes browsers in use.

It's useful if something like IE5 comes up. You can say, discontinued at whatever-the-date-was and currently 0.0001% (or whatever) of Internet users -> Forget it. (Without something like that web site design is limited.)

I suspected that XHTML 5 was dead for me. W3C says 2012 but the guy who is doing the work (Ian Hickson) says 2022. To me that means 2022 is the date for completion.

If you look deeper into waht he means, he says HTML 4 is not finished, so it's a strict test for completion.

From some quick tests yesterday (I couldn't find test pages for what interested me, so I had to write my own) I'd say that:

1) IE8 and the current other browsers probably recognise X/HTML 5 documents. (Not formally checked but all act on some bits of ...5).

2) For the programmatic bits IE8 implements dom storage and xdm (or rephrased, give a better way than cookies and allow controlled cross page programming). FF seems to implement the xdm stuff. See http://samples.msdn.microsoft.com/ietes ... /html5.htm for the test suite.

3) For things like time, meter and progress, there may not yet be implementation, but some forms of implementation I wouldn't see so thats unclear.

4) For the obvious (and presumably easy) things like nav, header, footer, menu, aside... There is a lot of implementation on the browsers I tested (IE8, FF, Opera, Chrome, Safari) but there are bits missing. (2009/03/01 On review of the test page that I found for menu etc. I'm not convinced there's much implementation of anything except menu, yet. It is already possible however for designers to write pages that emulate these things on non-IE browsers.)

This is a provisional analysis. Maybe an hour. I was expecting to see it all done by somebody else so was pretty surprised that I had to answer these basic questions for myself. The conclusion is that X/HTML5 will be usable, in some sense, when IE8 comes out and a year or 18 months after that can be used by those who keep right away from the bleeding edge.

I see that Firefox 3.5 is reported to implement some of HTML5.

I haven't looked at this hands on but it might be the audio and video elements (with Ogg Theora and Vorbis natively implemented, which I heartily applaud). If it's only that there's a long way to go until we get the bits I think more important. Whatever the case it is a step forward and might have got to the point where it impinges on CSE.

(I hit that awful save button again,forunately I didn't lose the post this time!!)

I had a quick look at the implementation page at

http://a.deveria.com/caniuse/#agents=All&eras=now&cats=HTML5&statuses=rec,cr,wd,ietf

It suggests that contenteditable and XDM (Cross Domain Messaging) are ready to go. Both Audio and Video are FF 3.5 and Safari 4 only so not ready for prime time yet, but I daresay some will use them already.

Yes, I definitely will be looking into this soon. Currently I'm working on some Common Look and Feel for the Internet 2.0 checking:
http://www.tbs-sct.gc.ca/clf2-nsi2/index-eng.asp

That will be nice for some current Canadian customers and some potential new Canadian customers.

Then I will take a deeper look into HTML 5 and see what checking CSE HTML Validator v10 can do for it.

I had a quick look at that site.

It responded as expected to font size changes (thru the browser interface). Pleasing to see.

It didn't do so well when I wanted to show it in a smaller browser window. I think that might be mandated in the specification where it seems to require fixed column widths, which prevent content flow.

I didn't read too much but they may have been talking about separate printable pages. Printing can often be handled with a style sheet, no need for a separate page (and the maintenance issues it brings).

Good luck with whatever you're doing there. If these guys are serious about getting decent X/HTML that's a big win.

With IE being more picky about markup and the implementation (slow though it is) of X/HTML 5 maybe things are pointed in a better direction!

I'm currently investigating adding some HTML5 support to CSE HTML Validator. Is anyone here using any new parts of HTML5 that CSE HTML Validator doesn't yet support?

I have to decide which parts of HTML5 to support first. These should be the parts of HTML5 that people are actually using and that have support in major browsers.

I've also added a poll to this thread. Please vote!

Thanks.

My evaluation of X/HTML 5 remains close to that described above.

I notice that with Firefox 3.5 (which they may finally have gotten right) both the DOM storage (local and session) are now working. The storage didn't work in 3.0 so that's an advance. This gives developers an opportunity to do better than cookies for a lot of users (give it a month or two though!!).

The other non IE browsers may be behind the curve on that, so a cookie fallback needed unless you can afford to ignore them.

The above is code so the markup is something like, meter, time, svg?, menu and maybe the other bits (header, footer, aside, article, video?, audio?)...

At present this is in standby. In other words I have test pages using some of it and working pages using things which I don't need to render in on the browser.

Given that some of the harder work has been done, I hope that we'll see real progress before too long.

(In the early days I remember a breakneck pace of change compared to the walking in treacle we see today.)

I see that we now have an unusual twist on this.

Google has launched "chromeframe" which essentially hijacks a copy of IE and turns it into a copy of Chrome. (With an ActiveX control I think.)

It is activated by a meta tag on a web page or by specifying a special URI in the address bar (cf:http...).

The program is not yet ready for prime time (I've read that it currently has no printing, and downloads have zero UI). Time will tell how much market penetration it gets. I presume it is more aimed at IE6 than IE in general.

It is reported to do HTML 5.

An interesting factor in the HTML5 discussion that I hadn't expected.

MikeGale wrote:I see that we now have an unusual twist on this.

Interesting. Here's an article:
http://www.tomshardware.com/news/Google ... ,8716.html

Which also contains this video:
http://www.youtube.com/watch?v=sjW0Bchd ... r_embedded