Open SonoSooS opened 1 year ago
This was brought up again, and this is my verdict:
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.
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 likeClassicOctalHexShortaluMcycle
(first letters capitalized for readability, all URLs are lowercase currently otherwise).There have been some other suggestions, but they also have their own downsides:
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
orclassicoctal
), but more situation-specific configs (like the beforementionedClassicCotalHexShortaluMcycle
) 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.