As the title suggest - it should be easy enough to implement here and here. I could make a PR if it would be welcome?
Granted it will not work “automatically” across the mobile versions but will have to be implemented “manually” on each platform.
A more involved approach may pay off later would be to add functionality to load additional classes for <body> from the rust backend (i.e. the backend has a get_backend_question_class() and a get_backend_answer_class()) That way the other reviewer implementations would only need to “do it once”. One could later easily add a class for say active cloze ordinal or similar. Or one could allow adding attributes as well.
Given that template authors can already wrap the front/back in a div if they want side-specific styling, I don’t really see the need for this?
An example use would be addons that extends editor/note functionality with non-core-Anki HTML elements/JavaScript that needs to differentiate between front and back but does not create any templates. One practical example, although very specific and quite possibly too niche, would be Inline media which inserts <audio> and <video> elements with configurable settings depending on front or back. Possibly some other addon creators might use such functionality.
I was thinking it should be available across device types, similar to the OS and device classes (win/android/linux/macos and mobile) available on <html>. I understand those are hardware related but was thinking it might not be conceptually wrong to add some note/card info on <html> or <body>.
My earlier point of maybe doing it a little more generic in the form of a function returning a result from the backend (as I understand that both Mobile Anki and AnkiDroid now use the same rust backend as the desktop version) would - if one was so inclined - allow to easily integrate more meta info in the class list or custom properties or whatever the design choice is.
Your examples above were focused on add-ons; my thinking was that if this is mainly for add-ons, it probably belongs in add-ons instead of in cross-platform code.
One of the reasons why I’m reluctant to wrap the existing question/answer in extra divs is that it may affect how certain existing card templates are styled, and since template authors already have a way to do this themselves by editing their templates, I’m not sure it’s worth the risk.
My thought was not to add additional <div>s but rather add classes to <html> or <body> (in the case of providing active cloze ordinal one could envisage --data-cloze on the <html> or <body> that would be empty on non-cloze note types). That shouldn’t mess up any layouts but still be available for both styling and JavaScript.
The problem with doing it that way is that any content included in {{FrontSide}} will take on the appearance of the back side instead of the front side.
The problem with doing it that way is that any content included in {{FrontSide}} will take on the appearance of the back side instead of the front side.
True, that could be resolved by div wrapping in the template though as CSS may go more hand-in-hand with templates than addons do. But admittedly it would be cleaner with something that worked for every use case without disturbing existing templates.