Our parser is very conservative because we are trying to set a minimal standard of compatibility for the ecosystem — that is, it should not be a minefield for someone to write an app that accepts the same notation that cubing.js does. This means cubing.js is strict about things that some people might not expect. We've already added some workarounds for this, like converting smart quotes on paste in Twizzle. However:
<twisty-player> can two kinds of invalid alg (invalid syntax, and invalid for the current puzzle) and is silent about syntactic alg errors because this is the safest way to keep the internal prop graph abstraction. We can probably find a way to surface this in the console (debounce error messages?) or in the element (a warning symbol that opens a modal?).
It wouldn't be too prohibitive to detect things like tabs and smart quotes and tabs and explain why they were rejected. That said:
For the aforementioned compatibility reasons, I want to keep an extremely high bar for what syntax is accepted.
Alg parsing should be consistent across all uses of cubing.js. No "lenient" mode, at least not until we're much closer to 1.0.
Our parser is very conservative because we are trying to set a minimal standard of compatibility for the ecosystem — that is, it should not be a minefield for someone to write an app that accepts the same notation that
cubing.jsdoes. This meanscubing.jsis strict about things that some people might not expect. We've already added some workarounds for this, like converting smart quotes on paste in Twizzle. However:<twisty-player>can two kinds of invalid alg (invalid syntax, and invalid for the current puzzle) and is silent about syntactic alg errors because this is the safest way to keep the internal prop graph abstraction. We can probably find a way to surface this in the console (debounce error messages?) or in the element (a warning symbol that opens a modal?).cubing.js. No "lenient" mode, at least not until we're much closer to 1.0.