CSE HTML Validator

I see chatter about Hash-Bang sites.

That's sites with a URI like http://www.somesite.com/section45/#!blabla. Where the idea is that the server only sees up to the hash and Javascript takes over building the page (browser side) based on what's after the #. See http://bit.ly/iv54kc for a description. Twitter recently started using this form (I have no idea why they decided to do that!).

I wondered if anybody here has gone this route. If you did can you share details of how you go about validating content?

(NOTE: I see no need to go down this route in my own work. When the big majority of browsers support a way to do this I might revisit it. I'd need to be convinced that it is a sane thing to do though. I guess that a page you decide to mark as no-archive etc. might qualify quite easily. There are facilities in some browsers already to do something called pushState, replaceState and onpopstate to handle this sort of situation. That collection effectively replaces what #! is intended to do and will no doubt present a big headache to those who have gone down the #! path. (Their URL's will be obsolete and they'll need to keep supporting them!))

Here's one analysis of the situation http://bit.ly/kYJTPV.

MikeGale wrote:Here's one analysis of the situation http://bit.ly/kYJTPV.

Thanks Mike. I thought that was pretty interesting. I am unfamiliar with that method of "serving" pages.

As for validating, one of the things I have considered looking into is the option to validate the HTML behind the DOM using the integrated web browser in CSE HTML Validator. This would be manual, but it may also be possible to do in the Batch Wizard if it made use of a web browser engine to pull up the page and then checked the HTML behind the "JavaScript adjusted" document. There would have to be enough demand to want this feature in order to justify it though, and I don't foresee that right now.

Hi,

I really like that idea of expressing the live dom as html and validating it.

That would be useful outside Hash-Bang sites. It would give a way to check dynamic sites, like those sites which are in part "drawn" by jQuery.

I suspect that's a large audience.

(I also imagine that such content is a somewhat distinct validation exercise, as it doesn't come from raw HTML but has been through the "engine" of a browser so is transformed to some degree.)

MikeGale wrote:Hi,

I really like that idea of expressing the live dom as html and validating it.

That would be useful outside Hash-Bang sites. It would give a way to check dynamic sites, like those sites which are in part "drawn" by jQuery.

I suspect that's a large audience.

Yes, it is something I should look more into (and plan to) for the next major release. I also see it useful for many things (other than "hash-bang" sites) these days.

I'm not sure what the IE engine offers yet in doing something like that, but hopefully it wouldn't be too involved.

Some potential sources of ideas for interacting with browsers are:

1) The toolbars (F12) in the browsers.

2) The Selenium page testing tools. (I think they set up a proxy server, inject Javascript and have a back end java server to talk with the page. Not sure how much that design will help.)

3) The Watir, WatiN, Vapir... family of web page testing tools. (They seem to grab the browser directly, so might be fairly useful. Most of what they do is definitely off target though!)

4) There's also material out there about writing BHO's, FF extensions, etc. etc. A good overview (for IE) can be had from an ebook called "Pro Internet Explorer 8 & 9 Development". There is surprisingly little overview coverage of IE so it's especially valuable.

Thanks Mike! Your suggestions seem like a great starting point for looking into this for CSE HTML Validator.