Sideways catpures

gyazo.com/34222946ef25e710c5715efecafee045.pgn

OP want's a hitbox like (or similar to) this. Where, you can move diagonally despite not being in the right square.

It's not a bad suggestion. Also, guys stop with the insults and negative attitude. That is not welcome.

@WindowMaker and @BerserkAsIfUWereMad, wow, two really helpful replies out of four, for a really abstract, maybe impractical hard programming idea I dreamed for. I felt like Copernicus there for a while, but you two are encouraging, thanks guys. WindowMaker's diagram there is just what I envisioned, and I could study how BerserkAsIfUWereMad's keyboard move software transmits moves to Lichess and adapt it to this subject. Not just a dream anymore, thanks.

I don't get this at all, you click the pawn, then click the square containing the piece you want it to capture.... I've never had a pawn move forwards instead of capturing. The same is true if you choose to drag the piece instead of clicking.

If there was an interface problem causing pawn captures to fail sometimes people would be screaming about it,

@BaronVonChickenpants Careful now. You keep on posting common sense using clear, easy to understand English and he might report you to yourself for hate speech!

You can set "move confirmation" to on by going to your preferences screen and selecting game behavior. You can also tell preferences to highlight legal moves so you can easily click within the legal squares for a move.

You can also set piece movement to a double click mode, or a click and drag mode.

@killF7 "You can set "move confirmation"" <-- I do that for slow games, some players responding to this post only play Correspondence (day per move) chess where moving the piece wrong by mistake is preventable, and seemed confused how trouble could ever occur. In ultra, hyper, and bullet "move confirmation" will be too slowing to win. Some fast players use "two square clicking" such a PeshCh but am not used to that. @BerserkAsIfUWereMad mentioned the hover/keyboard extension which there is a lot of discussions about on this site. Players who play only slow chess will not need any of these aids. The point of them is to reduce common troubles as one throws pieces quickly in high speed chess.

I was wondering whether the op difficulties were recent or not. Browsers have been changing their API layers for handling input-output toward "responsive design" in including touch screen user input device and mouse (hopefully making it mandatory backward compatibility).

Since the interpretation of mouse-up event versus drag is of possibly conflicting nature between those two human input interfaces (how long a touch versus a clic or clic hold), i don't know the details but i have had, then not, and then again have problems with the right click version on lichess right now, for drawing.

so perhaps compare behaviors between chromium based browsers (where i have problems) and FF as, they don't seem to want to be mirror copies on that aspect of web standards or APIs. May not apply here. but just in case changing browser family changes experience, worth mentioning i think. Also, the "recent" is because this was fixed for a few months and started again a few days ago (approx.).

@dboing I do not know if the difficulty is worse this year than they were before, I have just counted the occurrences the last few months, and thought it would improve my ELO if I program in a way to lower the likelihood of such errors . Here is my setup if you need to know: I always use Chrome. This year I am stuck using my mother's MacBook Air, MacOS Mojave 10.14. I can only play chess after attaching a USB mouse, because the built in mouse is far too difficult to drag and drop with. But beyond the computer interface short-comings, the horizontal justified checkerboard layout of chess boards is not as suitable for diagonal moving pieces such as Bishops as for Rooks, because the Bishops have to hop over the square corners but Rooks do not. For pawns moving sideways, it can cause great loss if the pawn is dropped in those gaps. That was the point of my fixing ideas. But as with several of the other repliers to this post, you only play very slow correspondence chess, where none of the costs of mistakes in speed moving pieces occur.

A typical example of this interface problem just occurred in my game: shown on move #30 here: lichess.org/study/wmor48QN

On move 30: sideways capture of a rook failed to work here loosing the game by poor interface construction. Over a real chess set a loss would never occur like this by anyone, it is only caused by the inappropriate difficulty of landing the web chesspiece icon at a sideways angle, and thus having to avoid touching the tiny corners of all the neighboring incorrect squares. The horizontal-vertical oriented chess squares are not drawn optimally for that motion. Losses from this occur approx. every 20 games in speed chess, in my games, wrecking rating accuracy. @WindowMaker 's diagram gyazo.com/34222946ef25e710c5715efecafee045.pgn
shows one way to fix that disaster from ever happening, but his diagonal borders could extend to all the squares on the board. Thus when a bishop is picked up by the mouse, why have horizontal-vertical boundaries and illegal destination squares in the way of its path?; instead have the board redrawn with a diagonally oriented matrix of squares. That way only legal squares will ever be landed on (unless there is extremely bad (dozens of pixels off) mouse aim). In a high speed chess game with the current Lichess board, landing a bishop on a non-diagonal square, because of slightly sloppy mouse aim, causes the move to get undone, and so the time loss from that can loose the game for that non-chess skill reason, and it seems fixable.