That would be great, it its not too difficult. Admittedly this is pretty unusual, but in the case of Brouhaha, I think it makes sense. Games will often open with the usual moves and I like the fact that they are still "e4 e5 Nf3" ...
There is a problem, though: I see that you are using 'x' and 'z' for the edge files on your Brouhaha page. But 'x' would not be acceptable, as it would make the SAN notation ambiguous: the is also used as a capture indicator. There must be some restrictions on file labels to make notation work. If it was only a matter of choosing what to display in the margin of the board diagram it would not matter what labels you choose. (As long as they are not so large they would not fit in a cell the size of a square.) But the SAN generator and move parser must also be adapted to use those labels.
Regarding the array FEN, no, I am not asking the interactive diagram to generate it. If I could add custom text under the list or under the board that would do it. My appologies if this is already possible - it may well be.
Well, the Interactive Diagram is just an element in the HTML page you would submit as an article or comment. It would be entirely up to you to design the rest of the page. You just embed the Diagram and its 'satellites' in the page you design by inserting a HTML tag pair with the proper id (or, for the board element, with class="idiagram") in the place where you want those to appear. The board element will contain the Diagram's specification, which will be deleted by the script, and then all the recognized elements (board diagram, piece table, piece list, piece descriptions) will be filled with the proper content according to the specs.
There only would be a problem if you would want to have extra text embedded in the elements that are filled by the script, because anything you write there would be replaced by what the script generates for that element. The reason for having the script generate those elements, rather than have the user write them, is usually that they contain clickable items that must invoke functions of the script. It would not be very hard even for an HTML-ignorant user to supply a list of pieces and their starting squares (by using the WYSIWYG mode of the editor), but clicking the pieces would then not summon the move diagrams.
[Edit] Perhaps we get away with the 'x' in Brouhaha: there are only Brouhaha squares on that file. They can never be destinations, and SAN would never mention a square of origin unless there is a need to disambiguate. And since the piece starting on this square is color-bound, and its Brouhaha squares for the same player are of different color, disambiguation for a Cleric move would never be needed. So the 'x' would never appear as a square coordinate in the move notation, and the fact that the move parser assumes it will never be a square coordinate will not hurt.
There is a problem, though: I see that you are using 'x' and 'z' for the edge files on your Brouhaha page. But 'x' would not be acceptable, as it would make the SAN notation ambiguous: the is also used as a capture indicator. There must be some restrictions on file labels to make notation work. If it was only a matter of choosing what to display in the margin of the board diagram it would not matter what labels you choose. (As long as they are not so large they would not fit in a cell the size of a square.) But the SAN generator and move parser must also be adapted to use those labels.
Well, the Interactive Diagram is just an element in the HTML page you would submit as an article or comment. It would be entirely up to you to design the rest of the page. You just embed the Diagram and its 'satellites' in the page you design by inserting a HTML tag pair with the proper id (or, for the board element, with class="idiagram") in the place where you want those to appear. The board element will contain the Diagram's specification, which will be deleted by the script, and then all the recognized elements (board diagram, piece table, piece list, piece descriptions) will be filled with the proper content according to the specs.
There only would be a problem if you would want to have extra text embedded in the elements that are filled by the script, because anything you write there would be replaced by what the script generates for that element. The reason for having the script generate those elements, rather than have the user write them, is usually that they contain clickable items that must invoke functions of the script. It would not be very hard even for an HTML-ignorant user to supply a list of pieces and their starting squares (by using the WYSIWYG mode of the editor), but clicking the pieces would then not summon the move diagrams.
[Edit] Perhaps we get away with the 'x' in Brouhaha: there are only Brouhaha squares on that file. They can never be destinations, and SAN would never mention a square of origin unless there is a need to disambiguate. And since the piece starting on this square is color-bound, and its Brouhaha squares for the same player are of different color, disambiguation for a Cleric move would never be needed. So the 'x' would never appear as a square coordinate in the move notation, and the fact that the move parser assumes it will never be a square coordinate will not hurt.