DougWeb – Doug's home on the Web

So far, not a lot – though not for lack of trying.

Companion 0.1 converts skins to XSL, applies the XSL to the XML, chops the result into lots of small pieces, and inserts them back into the skin (all using JavaScript). At the time this seemed like the best way of doing it – rapid prototyping, quick feedback when something was broken (get no output back), let me brush up on my XSL.

This approach also has drawbacks. The first one being the feedback when something doesn’t work as expected – there’s only one sort of error that gets returned which doesn’t help. When ‘new’ skin tags are processed, the XSL can’t handle it and dies. This is one of many situations I’d like to flag, so that an appropriate error message can displayed to the user. It also offers no flexibility in output – e.g. dates are always output in UK format, even for US users. Both of these (and others) could be included in the current setup, but with significant performance penalties, because each JS->XSL->JS roundtrip involves converting a JavaScript ’string’ into an XML ‘document’, and the resulting XML ‘document’ into a JavaScript ’string’. This conversion is the slowest part of the whole process, despite the fact it’s been optimised as far as possible (I process the entire XML file at once. The original design had a seperate pass for each profile, which kept RAM usage down, but took about 20x longer).

So I decided to rip out the XSL and take advantage of Mozilla’s support for E4X (EcmaScript for XML). E4X basically extends the JavaScript language to have native support for handling XML. Being a very new addition to the engine, it’s largely untested and my first line of E4X exposed two bugs in Mozilla’s implementation that have kept me back.

Bug #1 (Mozilla bug #324422): A crash when reading the XML into memory.
Bug #2 (Mozilla bug #324844): A limit of 4Mb on any native JS object.

The Mozilla devs are taking both issues seriously – the 1st one is already has a ‘fix’ and the 2nd is being worked on. Both are likely to be marked as ’stop-ship’ bugs for the next version.

Who said open source isn’t great?

Although fairly obvious, the largest ever study of code used in web pages confirms that fact that web standards are largely ignored.

The study was done by Google, who analysed the HTML in 1 billion pages.

Looks like the Web Standards Project has their work cut out!

Today’s my Dad’s birthday, and ‘the family’ decided to buy a Freeview box as a present. This is a house that’s had 4 computers, 4 digital cameras, 3 printers, a scanner….but no digital TV.

Connecting the thing was a nightmare – the cabinet we use for housing stuff like the DVD Player and VCR was not designed for accepting cables down the back. The fact that the Freeview box only came with 1 SCART socket (Argos catalogue said 2) didn’t help either.

On a related note, Dad got a bunch of presents from his workmates (he turned 65), and one of them was a digital radio…freaky eh?

Since Hugh Laurie just won a Golden Globe for this, I thought I’d watch the season 1 DVDs that were on my shelf.

Amazing show – just the right mix of drama, comedy and suspense. A selection of quotes can be found at the ever-useful IMDb. Highly recommended.

I ’softly’ launched this last night, and made an announcement in the IVS forums this morning. I’ve only had 1 piece of feedback so far on this (from one of my early testers), and he seemed fairly happy…

I’m going to take a few days off now and start watching some DVDs again. Then I’ve got to make a decent user interface. That’ll require some thought.

Also (to add to this post a few days ago), I’ve discovered another ‘feature’ of IVS’s skin tags. The ‘=’ is optional…

Got home from work earlier today to be told by my sister, that we’d had an attempted buglary just 5 minutes beforehand. She heard a loud crash, and came downstairs to investigate to see the 2 fuckers run rapidly out of the big hole where the half of the back door previously went as soon as they saw her.

You can also see the piece of brick wall the cunts tore off to use as a battering ram. I’m more than slightly annoyed.

Q: When will the DVD Profiler Companion get it’s initial public release.
A: When I track down (and fix) the cause of a bug that causes a crashes on a semi-regular basis.

I bought 27 DVDs, which pretty much gets rid of any hope of keeping my unwatched count down for the next few months…

I’ve just planned the order I’m going to add features to the DVD Profiler Companion, and updated the web page to match. Details here.

XML + skin = 780 HTML pages

Perhaps the most fundamental thing to HTML is the fact that an element is created by inserting a tag name, surrounded with < and > e.g. <elementname>. Because of this, any time you want an actual < or > to appear in the text (e.g. 2 < 4), it must be ‘escaped’ as &lt; or &gt;.

Any element content (which may include more HTML) goes after the opening tag, and is then followed by a closing tag </tag> e.g. <b>This text is bold</tag>

A tag may also have parameters passed to it via attributes e.g. <element parameter="value">

Code like that found in a typical DVD Profiler skin
<DP NAME="SOMETHING" ATTRIBUTE="<b>Some HTML embedded within the actual tag as an attribute value....</b>"> breaks all the rules on what constitutes HTML, and is thus a complete nightmare to handle.

How do you tell (algorithmically) where the <DP> element ends in this example? It’s a lot harder than just looking for the first > after <DP…

Even the source colouriser inside DVD Profiler gets confused with stuff like that, and that example came straight out of an IVS-created skin!

<td align="right" WIDTH="0"><DP NAME="LOCK_RELEASEDATE" IFSET="<IMG SRC='$DPIMAGES.Locked.gif'>"></td></TR></TABLE></TD>


I need some New Year’s resolutions…