Re: [xsl] all-XSLT implementation of Minesweeper

Subject: Re: [xsl] all-XSLT implementation of Minesweeper
From: "Joe Fawcett" <joefawcett@xxxxxxxxxxx>
Date: Tue, 15 Mar 2005 08:38:07 -0000
----- Original Message ----- From: "Sean Whalen" <seanwhalen@xxxxxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, March 15, 2005 2:27 AM
Subject: [xsl] all-XSLT implementation of Minesweeper

I started this as a personal educational project to see how much of the data management and rules I could encode in XSLT. The main page uses javascript to handle the mouse-events and to generate the random numbers. Everything else is done in 3 different xslt files. The first stylesheet takes a set of random numbers and a pair of min/max values and returns a list of elements representing a full grid. The next style sheet transforms the list of nodes into grid of HTML buttons. The third sheet returns the set of squares that are revealed when the user clicks on a square. This is a recursive algorithm that looks for flags in squares bordering the square that was clicked. That set is then sent to the same algorithm, and the template finds the flags bordering those squares, etc, until no more bordering flags are found.
I'll probably dress up the page a little this week with some explanatory text.

I'd posted here a week or so ago regarding the speed difference between MS-IE and FireFox. I posted a bug report to Mozilla about it which generated a lot of chatter among their developers regarding what performance improvements would be effective.

I had a real problem with MS-IE in how it reacted to"deferred" <SCRIPT> blocks inside the xslt. The problem seemed to do with when it chose to execute the script generated from the stylesheet. Firefox was much more predictable how it handled the <SCRIPT>. For the thing to work in IE, I took all the script out of the stylesheet, which in this case seemed like the better approach anyway.



Very impressive, you may get a quicker rendering of the table if you set its style to table-layout-fixed. As it's a regular table the browser then doesn't "worry" about whether parts towards the bottom will alter the layout of cells rendered near the top.
And one question about some of the code. Why do you alternate between using msxml2.domdocument.3.0 and microsoft.xmldom?


Current Thread