A while back, I attempted to write a chess site that let you paste in chess games in PGN text format, and then step through them. What I found was pretty shocking: the PGN format looks simple, but is remarkably difficult for a computer to parse.
The reason is that the PGN format only specifies the piece type and destination square of each move. Ne4: a knight moves to e4, and it's up to the parser to figure out which knight. So to parse PGN, you have to teach your parser how the pieces move.
That by itself is not too bad, but it gets worse. What if both knights can move to e4? Then the format disambiguates. Nge4: the knight on the g file moves to square e4. But "can move" is a tricky notion in chess. This knight cannot move because it is pinned to the king. That pawn can capture en passant this turn, but not next turn. So to write a PGN parser, you must build a chess engine capable of analyzing a board sufficiently to determine legal moves.
One might hope that reasonable PGN text would be nice and disambiguate whenever two pieces attack the same square, and not require legal move analysis. Alas, it is not so. The "two knights attack a square but one is pinned" case is specifically called out as NOT requiring disambiguation in the spec at http://www.saremba.de/chessgml/standards/pgn/pgn-complete.ht... .
A further consequence is that it is not possible to make a "generic PGN" parser that can handle chess variants, like suicide chess. The rules of chess are baked into the format itself, and the parser must have knowledge of the rules used to play the game that it is presenting.
This is a great write-up and is exactly the reason that ChessBoard is "just a board".
Proper PGN parsing and legal move validation is a complex and independent problem that nicely fits into it's own library and should be separate from any display logic.
PGN isn't a format designed for parsing convenience. PGN is the exact notation any chess player uses for writing down games. I would never write down 1.e2-e4 for instance when simply 1.e4 is totally apparent. I find it very confusing when too much information is presented in this case. In the same vein, whenever you are presenting chess notation to a human it is preferable to not show the long notation. So any time you would want to display the notation of a chess game(which is pretty much everytime) you would need to parse the game with a program that understands the rules to produce the shorter notation.
I've found that the rules can be expressed quite elegantly and compactly in a language that supports pattern matching. I have a Haskell implementation [1] which is just under 300 lines of code including the parsing of SAN moves (standard algebraic notation) which is used in PGN files.
True, it would be tricky to get all the rules of chess into a JS file (sounds like a worthwhile open source challenge to me!), but it wouldn't be so hard to expose the features of a chess program like Crafty through an API and do the check via AJAX.
"it would be tricky to get all the rules of chess into a JS file"
Check out chess.js, https://github.com/jhlywa/chess.js, it does a pretty excellent job. The combination of chessboard.js and chess.js would result in a pretty sweet browser-based chess game.
The reason is that the PGN format only specifies the piece type and destination square of each move. Ne4: a knight moves to e4, and it's up to the parser to figure out which knight. So to parse PGN, you have to teach your parser how the pieces move.
That by itself is not too bad, but it gets worse. What if both knights can move to e4? Then the format disambiguates. Nge4: the knight on the g file moves to square e4. But "can move" is a tricky notion in chess. This knight cannot move because it is pinned to the king. That pawn can capture en passant this turn, but not next turn. So to write a PGN parser, you must build a chess engine capable of analyzing a board sufficiently to determine legal moves.
One might hope that reasonable PGN text would be nice and disambiguate whenever two pieces attack the same square, and not require legal move analysis. Alas, it is not so. The "two knights attack a square but one is pinned" case is specifically called out as NOT requiring disambiguation in the spec at http://www.saremba.de/chessgml/standards/pgn/pgn-complete.ht... .
A further consequence is that it is not possible to make a "generic PGN" parser that can handle chess variants, like suicide chess. The rules of chess are baked into the format itself, and the parser must have knowledge of the rules used to play the game that it is presenting.