Was this on a mobile device? On my PC that Diagram seems to work fine. But on my tablet it didn't.
I had a similar experience with one of the Diagrams in the 'huge variants' subject thread, when I tried to show it to a colleague on my Samsung tablet. Initially everthing worked fine, but then during the demonstration it suddenly stopped being responsive to touches on the board and on the piece names in the table. Opening and closing the piece table still worked under those conditions, though.
Now the touch screens use a different event for manupulating the pieces than on a PC ('ontouch' rather than 'onmousedown'). That they behave differently would suggest the problem is in the touch-event handler. I am not sure they really behave differently, though, because the Wildebeest Diagram now works again on my tablet as well. (While I am certain that earlier this morning it didn't.)
It is very strange that this problem does not manifest itself consistently. One hypothesis would be that there is a name collision between the Diagram script and some of the JavaScript that is loaded on behalf of the advertizements that appear on the same page. So that it depends on which ad gets loaded.
Also, how do you use Betza notation to specify castling for this game?
You have to specify each castling possibility separately: KisO1isO2isO3isO4 . (In the comments there already was a Diagram that uses this.) For the isO1 it will highlight the Rook amongst the King destinations, and take the one-step castling when you click that. (It would also have used that highlighting for isO5, but since that is not allowed here there is no ambiguity.)
In the betzaNew.js version of the script the move entry would work differently: after selecting King the square next to it would be highlighted by a cyan star to indicate there is an as yet ambiguous move to that square. When you then click that star, it would highlight the square next to King with the yellow circle, and the Rook with a castling symbol, and a third click would be needed for resolving the ambiguity by clicking one of those. An initial castling highlight on the Rook would then always mean isO5 castling. (Or, on other boards, castling where the King ends up in the corner.)
Was this on a mobile device? On my PC that Diagram seems to work fine. But on my tablet it didn't.
I had a similar experience with one of the Diagrams in the 'huge variants' subject thread, when I tried to show it to a colleague on my Samsung tablet. Initially everthing worked fine, but then during the demonstration it suddenly stopped being responsive to touches on the board and on the piece names in the table. Opening and closing the piece table still worked under those conditions, though.
Now the touch screens use a different event for manupulating the pieces than on a PC ('ontouch' rather than 'onmousedown'). That they behave differently would suggest the problem is in the touch-event handler. I am not sure they really behave differently, though, because the Wildebeest Diagram now works again on my tablet as well. (While I am certain that earlier this morning it didn't.)
It is very strange that this problem does not manifest itself consistently. One hypothesis would be that there is a name collision between the Diagram script and some of the JavaScript that is loaded on behalf of the advertizements that appear on the same page. So that it depends on which ad gets loaded.
You have to specify each castling possibility separately: KisO1isO2isO3isO4 . (In the comments there already was a Diagram that uses this.) For the isO1 it will highlight the Rook amongst the King destinations, and take the one-step castling when you click that. (It would also have used that highlighting for isO5, but since that is not allowed here there is no ambiguity.)
In the betzaNew.js version of the script the move entry would work differently: after selecting King the square next to it would be highlighted by a cyan star to indicate there is an as yet ambiguous move to that square. When you then click that star, it would highlight the square next to King with the yellow circle, and the Rook with a castling symbol, and a third click would be needed for resolving the ambiguity by clicking one of those. An initial castling highlight on the Rook would then always mean isO5 castling. (Or, on other boards, castling where the King ends up in the corner.)