Solve a general issue of configurability of the display

[SonoSooS]

There is a problem with being able to add new ways to display the opcode table differently.

It's actually quite easy to add code to change how things display via some config.

The problem is that since all variants have to be pre-rendered to be served from a static webpage, and no query parameters can be used to specify the config, currently the config of the layout is simply just encoded into the URL itself (like dark, classicoctal, etc.).
The problem with this approach is that it can't be scaled: eventually we'd have ridiculous URLs like ClassicOctalHexShortaluMcycle (first letters capitalized for readability, all URLs are lowercase currently otherwise).

There have been some other suggestions, but they also have their own downsides:

• Javascript would be the "obvious" solution, but it has its own problems:
  • compatibility issues between browsers
  • script blockers and browsers without a Javascript engine
  • it has to be maintained alongside with the static page script, which is just disasters to happen
  • additional bloat
  • you must wait for the page to fully load before the feature even starts to function
• CSS
  • no matter how clever we can make it, pretty sure it would break Internet Explorer compatibility somehow, which could only be fixed (if even) with even more CSS, adding more to the size of the page
  • can't be made persistent in any way without requiring user interaction on each page reload

While I sadly don't have any better clue on how to deal with this issue, I have thought of something:
It might be possible to keep the static URLs for "mainline" combinations (like dark or classicoctal), but more situation-specific configs (like the beforementioned ClassicCotalHexShortaluMcycle) could just have an optional prefix with a completely meaningless (sequential?) number attached to it (so something like /optables/layout-203, or simly just /optables/203).
If we end up considering this URL layout, then I also suggest branching off the colorscheme/theme as an URL part if possible (so /optables/classic/203 for example), so we have less pain which would be caused by this numbering scheme. Although an alternative could also be to always include the theme as a prefix, and the rest of the configs would be just an arbitary number (so /optables/classic-203 for example). I think this would be the best option, especially if the /optables/<theme>/<config> format is not possible.

Whatever the case, I don't think it's possible to flag this in any way on Github, but this issue blocks basically all other issues which are requesting an alternative way to display some information.

[SonoSooS]

This was brought up again, and this is my verdict:

• major splits (like colorscheme or T- vs. M-cycle) should go into the URL, so they can be downloaded as a static URL for offline use
• minor differences where it's predicted barely anyone would use it (like the explicit A missing from ALU ops) should go into the CSS+JS method

Here's which features count as what and why:

Feature	Split	Why
Colorscheme	major (URL)	Legacy reasons, and also most people only use a single colorscheme and stick with it.
Hex vs. Octal display	major (URL)	Legacy reasons.
T- vs. M-cycle display	major	Most people only need a single way of displaying, as they are used to either or the other, and it's easy to do the conversion in-head or whip out the calculator where the other is needed for the one-off chance the other is needed.
Explicit ALU A	minor	Most people seem to be fine with the ALU ops being consistent with the rest of the instructions, but we still don't want to discriminate against those who liked the older way of missing destination A register.
Hex Octal	minor	It's rare someone needs this, but emulator devs could appreciate seeing bit assignment more clearly, as being able to decode octal numbers in-head is a rare talent. Also it's a feature which usually needs to be toggled back-and-forth anyway, so it should not be part of the URL.
Other CSS changes	minor	Most people are fine with the current design, however some people still want to change the design. There could be a hidden textarea where Javascript applies the contents as a stylesheet, for those without and adblocker to apply custom design.

Here's how major features would work: just like how it's done now, just add a new permutation into the URL.

Here's how minor features would work: most features would be toggled using pure CSS (should work even back to IE6), but if Javascript is enabled then the settings could be saved into a non-expiring cookie.
If a minor feature becomes popular enough, then if it makes sense then it could be moved to a major feature, otherwise the default value needs to be just changed, and let users deal with it.

Considering the frameworks the opcode table now uses, there would be zero incompatible browsers which would be displaying the table incorrectly, so it would be okay to make this change.

If this proposal gets approved, then I could implement this myself (including the magic CSS and Javascript code necessary), as I still have talent from back in the day of writing CSS and Javascript compatible with much older browsers, including Internet Explorer, without needing any Javascript framework other than VanillaJS.