aboutsummaryrefslogtreecommitdiff
path: root/html/jspage.pl (follow)
Commit message (Collapse)AuthorAge
* Add a draggable resize handle to the JS puzzles.Simon Tatham2013-04-07
| | | | | | | | | | | | | | | | | | | | | | | Rather than design an ersatz 'window frame' surrounding the puzzle canvas, I've simply overlaid the resize handle on the corner of the puzzle itself (canvas or status bar, depending on whether the latter exists), trusting that all games in my collection provide a reasonable border within their drawing area. (OS X already does this with its resize handle, so it's not as if there's no precedent.) Unlike the desktop versions, I control the resize behaviour completely in this environment, so I can constrain the canvas to only ever be sensible sizes with no dead space round the edges (and, in particular, preserve the aspect ratio). Right-clicking the resize handle will restore the puzzle's default tile size. I had intended to implement a maximise-to-browser-window button too, but was annoyingly foiled by scrollbars - if you maximise to the current window width, and as a result the text below the puzzle scrolls off the bottom, then a vertical scrollbar appears and eats into the width you just maximised to. Gah. [originally from svn r9822]
* Fix the 'puzzle doesn't work' apology, which I'd accidentally movedSimon Tatham2013-04-06
| | | | | | | | | | | | | | inside the top-level display:none puzzle container as a side effect of r9809. Also, while I'm at it, reword the apology to mention typed arrays as the most likely cause of failure (AFAIK that's the most modern feature required by the JS front end), and fix indecision between singular and plural ('this puzzle' doesn't work, perhaps a feature 'they depend on' is missing). [originally from svn r9818] [r9809 == 5dc559c8be1b8f6ed15f560433f25c952c874f93]
* Mention Safari in the list of tested browsers.Simon Tatham2013-04-05
| | | | [originally from svn r9816]
* Update the list of tested browsers.Simon Tatham2013-04-05
| | | | [originally from svn r9812]
* Assorted HTML/CSS fiddlings to make things work better in IE. I'veSimon Tatham2013-04-05
| | | | | | | | | | | | added a trivial doctype (IE complained without it), but that caused a gap to appear between the puzzle and the status bar, so I tinkered a bit more and ended up removing the <table> completely (no great loss) as well as adding display:block to the canvas and explicitly setting the width of not only the status bar div but also its parent div. Meanwhile, I'm putting the "px" on the end of a lot of properties I set from JS, because IE complains about that too if I don't. [originally from svn r9809]
* Try to give a more friendly message if anything goes wrong duringSimon Tatham2013-04-03
| | | | | | | | | | puzzle startup. The puzzle web pages now enclose the whole puzzle (buttons, canvas, permalinks) in a div set to display:none, and instead display an apologetic message saying 'sorry, it didn't work'; then, if we get through the whole init function without crashing, we show the puzzle and hide the apology. [originally from svn r9802]
* Forgot to make the web-page-building scripts executable.Simon Tatham2013-03-31
| | | | [originally from svn r9786]
* New front end! To complement the webification of my puzzles via JavaSimon Tatham2013-03-30
applets, here's an alternative webification in Javascript, using Emscripten in asm.js mode (so that as browsers incorporate asm.js optimisation, the game generation should run really fast). [originally from svn r9781]