I promised info on the experience of Javascript programming for the Wii, so here you go. Some of it is a tiny bit technical, but I'll try to keep it as understandable as possible.
DOM Compliance
I probably should have mentioned this last night, but Internet Explorer is
still not DOM compliant. Due to Microsoft's inability to implement the DOM 2 Events spec (possibly the simplest friggin' spec in the world), Touch Wii will
NOT operate correctly in Internet Explorer. You have been warned!
Both Opera and Firefox/Mozilla are known to work, however, and Safari/KHTML should work just fine. It's only Microsoft that doesn't seem to know how to read a spec.
Wiimote Buttons
As previously mentioned in another thread, the Wiimote input has been decoded. As it turns out, Opera passes each button press as if it were a keyboard key. Which means that the standard "addEventListener" command can be used to trap button presses as if they were key presses. However, there are a few caveats.
Opera's Use of the Buttons
It would appear that button presses are extremely sluggish to respond. You need to hold the button for as much as half a second for it to register in the Javascript. Even worse, Opera ignores all attempts to stop the default events from happening. Which means that when you press the '1' key, you go to the Favorites screen even if the keypress is registered by your Javascript.
Poking at the Javascript with a stick seems to reveal an interesting design behind the Wii browser. Rather than having a window that contains an HTML rendering component, the Wii seems to take a very Mozilla-like tack by running ALL browser functions through the HTML renderer. Thus the homepage is the Wii Opera interface, and what we think of as the homepage is actually a frame inside the Wii interface.
This is a fairly old design, but it works because several features are disabled in the Wii browser. For example, the Wii browser does not allow new Windows to be opened. Such attempts are ignored, and the page is navigated as if it were a regular click. This doesn't normally work in other browsers as the webpage may accidently break out of its IFrame prison.
To be clear,
this is why the keypresses are accessible through Javascript! The Opera browser needs them in order to run its own Javascript in response to button presses. Since the Opera Javascript runs before the Touch Wii Javascript, it is not possible to disable Opera's control over the Wiimote. (Something that is normally quite possible on a mouse and keyboard system.) At least not with what I know at the moment.
However, this does suggest that special Wii extensions may be available to Javascript programmers. In theory, you could take control of the scrolling interface, activate the Favorites screen, zoom in and out, etc. Of course, that assumes that the parent frame allows you the security permissions to do so. It may not be possible due to such security restrictions.
Button Mappings
Directional Pad - These keys are used to tab between different clickable links on a webpage. If you design your Wii game correctly, you can use these buttons without the user noticing that Opera is interpreting them. That makes these the only useful buttons on the Wiimote.
A Button - While a keycode does come in for this, it's not particularly useful. By the time you get the code, the browser has already dispatched a "Mouse Click" event which will arrive as soon as you're done processing the key. As a result, it's far more useful to use this button for mouse clicks rather than trying to remap it as a keyboard key.
B Button - This button enters scrolling mode. If your application is designed to take less space than a single Wii screenful, then it
might be useful to you. More likely, you'll end up seeing directional arrows when you least expect it.
+/- Buttons - These Zoom In and Zoom Out of the webpage. Since this can't be turned off, these buttons are not useful. See "Screen Size" below for more info relating to these keys.
Home Button - This is the only button that Opera does not fire a code for. The reason is that the Wii operating system handles its press, and overlays the Wii Menu options instead.
1 Button - Pressing this takes you to the Favorites screen. This happens about the same time your code receives the keypress event, so it's not particularly useful.
2 Button - This "changes the display mode", whatever that means. It seems to disable various bits of key formatting (such as text alignment), making it even more than useless for games.
Alert Popups
If you use the "alert()" Javascript function, the alert will actually take over the screen until dismissed. This makes it function a bit more like the Mac OS X alerts than the Windows-style alerts. It could be useful for giving the user particular information, or even just pausing the game. I presume the "confirm()" function can be used the same way, but to ask a question instead.
Flash Support
Contrary to early reports, the Wiimote buttons do not appear to function inside flash programs. You must use Javascript if you want to read the presses. It is yet unclear if Javascript and Flash can communicate using a Livescript-type interface.
Screen Size
The actual screensize of the Wii is 640x480. However, you normally see a virtual 800x600 display scaled down to fit in 640x480 pixels. The + and - buttons are used to switch between true 640x480 mode or virtual 800x600 mode. When you're zoomed out, you're seeing the latter. When you're zoomed in, you're seeing the former. The only difference is that 640x480 mode still renders to an 800x600 screen. i.e. The browser does not reorganize the display like most web browsers do when you resize them. As a result, you must scroll around when you're zoomed in.
Rotating the Controller
There is no built in support for rotating the controller. The DPad directions continue to report the same keycode. If you want to support the use of a sideways controller, you need to handle the same keycodes differently depending on the "mode". The way I handled this in Touch Wii was to allow the user to click on the Wiimote image. When clicked, the Wiimote would turn in the direction of the current control scheme.
What Kind of Games Can be Made?
I hate to dash people's hopes, but arcade style games that use the Wiimote's buttons are probably out for the moment. Opera's mapping of every button on the Wiimote ensures that. The Opera Javascript appears capable enough, but the sluggishness and trapping of the controls makes it impractical.
However, the functionality provided by the use of the DPad could still come in handy for some, slower types of games. Wargames (either Hex or Real Time Strategy) come to mind as an excellent use of the Wiimote. Virtual Board Games could be fun as well. Online Card Games via AJAX are perfectly possible, as is a game like Battleship.
So there are still many possibilities, but the options are a bit more limited than one would have hoped for.
Ongoing Investigations
Obviously, I've only spent a limited amount of time with the Wii browser. There's still a ton more stuff to be discovered. For example, what happens if you use two or more controllers with Opera? Will they work? Will Opera identify them all the same, or use different key codes? That's a question I can't answer yet.
Another thing that needs to be done is to walk the DOM top to bottom to see if any further functionality can be discovered. Similarly, the Javascript objects need to be walked with a "foreach" loop to see if there are any special functions that can be used.
It's also possible that further investigation may invalidate some of my theories surrounding the operation of the Wii Opera browser.
Questions?
I'd be happy to answer any questions you might have, to the best of my ability. Feel free to either post them here or PM me.
Happy coding!
1
(Don't laugh too hard. I'm not one to joke about laziness. 
