validation · Grey Nicholson

On-the-fly page validation

2004-06-01T18:15:00+00:00

I wonder if this is possible. I've been dabbling with JavaScript a little recently, in order to produce The Twaddle's Expletatron and this seems like something that should be possible with JS:

I want a script that can load up a given remote page (internally - I don't want to display the page, just to extract info from it), look at an element on that page with a given id, and return its class as a variable.

What's this got to do with validation? Well say the remote page was http://validator.w3.org/check/referer and the given id was result. Then, if the returned variable is valid (i.e. the class of that element is valid) you've got a valid page; if the returned variable isn't valid you haven't.

So, you could, using JavaScript, whack in a “Valid XHTML” logo if, and only if, the page is actually valid. If you like, you could throw in an “Invalid!” image if the page is not valid.

I know it's possible to refer to an element by its id; I know it's possible to get the content of that element. I don't know if it's possible to get an element's class, and I'm guessing it's slightly impossible to do all this for another, remote page.

It'd be nice though.

Adventures in XML

2004-04-27T17:40:00+00:00

I did manage to get the XML+XSL-based jiggery-pokery for The Twaddle working - quite nicely, actually. Getting the entire contents of the content field onto the page took a little bit of effort, as described on the mozillaZine forums.

I won't be implementing this on The Twaddle, though - for a start, Opera and KHTML don't like XSLT. And it's not half as accessible for non-standard browsers (relics, mobile devices, text browsers...) as plain, extraneous-menu-items-and-such-written-into-the-article XHTML is. Nonetheless, a working example is online for the time being.

Update: the real thing's gone live... sort of... so the prototype has been removed. Additional related blurb is contained in a later entry in this weblog.

There's a slight chance that I might implement an XML-driven article system on Mooquackwooftweetmeow, where I'm not too fussed about old and/or buggy browsers. The fact that mobile devices won't render the page is more of a concern.

Perhaps some way of pulling in external XHTML fragments could be handled in CSS3? Then again, why duplicate XSL functionality in CSS - small devices' browsers could just be taught to handle XSL.

One more Twaddle-related thing: thanks to Internet Explorer conditional comments (on which MSDN has an hilarious article), I'm now feeding IE users some nice propaganda in the foot of the front page:

You're using Internet Explorer?! You do realise that it's years out-of-date, and screws up most modern web pages, don't you? In fact it's screwing this one up right now and you don't even know it. Try a proper web browser instead.

Oh, and another tiny little piece of The Twaddle-related trivia: the version number on the front page is now in the title text of the copyright notice - it's tidier and it leaves room for a pointless codename.

Over to the Mooquackwooftweetmeow Weblog now, where, thanks to our old friend XML namespaces, and our newer friend the XSL copy-of element, proper links are now in use. I've gone back through the weblog and updated plain text URLs to be links. The more observant of you will have noticed that there have been a smattering of links throughout this post - that'll be the norm from now on.

The even more observant of you will have noticed line breaks as well. I'd use paragraphs but the XSL stylesheet inserts the content into a paragraph - I don't think the XHTML validator would like paragraphs within paragraphs (not that it'd like this Atom file at all...). And I don't think the site's CSS would like divs to hold the text, in place of paragraphs; it might - I just haven't looked at mqwtm's CSS in ages so I can't remember. Besides, line breaks are lighter on the markup than open-and-close <xhtml:p> tags.

And in a final twist of XMLish loveliness, I've chucked a few XHTML <code> tags in as well.

</epic>

Namespaces are fairly fun

2004-02-19T18:30:00+00:00

The Feed Validator (http://feedvalidator.org) gave me a thumbs-down :( Entries' IDs have to be valid URLs, you see, and I'd been using them as arbitrary labels. I'd also been leeching off these arbitrary labels in order to create anchors in the XHTML representation of the feed; those using a web browser can check they work by clicking this item's title; those using a news aggregator can visit the alternate link; in both cases, the item's title should be at the very top of the browser window.

I managed to circumvent Atom's rigidity using XML's flexibility - I invented a new arbitrary label for each item - label, under my own namespace; I now have everything working as before, plus a valid feed. Glory!

I think I'll go and play a bit of pool now...