We're using ReactJS with Chakra UI which has Emotion as a dependency. However, we'd still be able to add our own CSS classes to things that we want to have them, to accommodate custom CSS. Whether that custom CSS is done through our website is another discussion, though. We think it's something that is better done through the browser, though there are pros and cons to both approaches. It's a discussion we'll have in time.

So... I can't say anything concrete or make promises right now - it will be a while before we can look into this further - but tl;dr we can still do what we can to support custom CSS (putting class names on things you can request, etc); what will likely have to change is how custom CSS is approached fundamentally. Traditionally, we've made it something you store in our database and that gets queried and loaded on every page. Efficiency issues aside, that is a little weird since what custom CSS controls is the way your browser renders pages, so conceptually it makes more sense for custom CSS to be stored in your browser. So that's the main difference, we'd like to move to having people apply custom CSS through a browser extension or browser settings instead. I do recognize there are pros and cons; one of the cons is that you won't have it if you're using someone else's computer to play Subeta, for example, since it won't be your own browser. These are all things we can talk about more in time.

There are some nice things we get in V2 by default:

• Night mode and day mode support
• Fully accessible components (meets official WCAG accessibility guidelines)
• Mobile responsiveness

What would be super ideal is if I can figure out a way for you guys to save custom themes that you can edit without any CSS knowledge.

Thank you by the way, this thread is an excellent idea. I think it's great to look at what the most popular custom CSS is used for today, and see if we can just make it an actual option of the site itself.

As mentioned in the staff post above yours, v2 is mobile responsive by default! We're building it with attention to mobile because we 100% agree with you.

I hear you and I like your idea.

Yes, exactly! And re: caching, sorry my last message was written hastily and was misleading about this. We cache it on the current site but it is still a bit of a bottleneck. One huge strength of v2 is that pages will only reload the parts that change as you click around, so efficiency would no longer be a concern on there. That's one way it actually makes things like custom CSS and the sidebar more feasible than the current site does.

But that is not to dismiss your ideas and input, which I appreciate so much. For real, thank you! One reason this conversation is a little premature is that I don't know how feasible supporting server-loaded custom CSS is until I sit down and actually try to do it, see what problems come up. Once I get there, our discussion here will be a lot more fruitful I'm sure.

(I can list some immediate concerns I have about it - but I am not sure which will be real concerns in practice yet)

Please review the stickied post with info and rules for this forum, specifically rule 3. No one is threatening anything (except you; it is not necessary to threaten to quit the site.) If you read the discussion you'll see that staff is trying to listen to everyone and find a way to make this work. If you want to give input, we appreciate that and want to chat with you! but we ask that you read the discussion first of all so you're informed about what's going on, read and follow the rules of this forum, and participate in good faith. This is not an "us versus them", "staff versus users" kind of deal and never has been.

Yes, sure! I don't have a ton of time, and haven't sat down for a proper think on it, but my immediate concerns / "things to research" are:

1. Security (since we would be evaluating custom code in javascript)
2. Whether it's possible at all with React (...to eval a block of CSS and cause it to be applied to the page)
3. Improper CSS breaking functionality with no good way to fix it

But you know, thinking about it more now, I don't think either of the first two will be a huge issue, and the third can be addressed with good validation. The fourth and biggest concern we have to work around is that - as you had pointed out - the bulk of our CSS selectors are dynamically generated and thus cannot be relied upon when writing custom CSS. This fact is unchangeable; it is also not immediately obvious to anyone unfamiliar with how ReactJS works, so we'll have to put some effort into making this clear.

And this requires a fundamental change to how all of us think about custom CSS. The kind of freedom we have now with custom CSS + userscripts will no longer be possible due to the way the new frontend is structured. If there is something you'd like to do, you will have to communicate it to staff so that we can add the necessary classes/IDs to the elements you'd like to work with.

This is why we were reluctant to support it as an official site feature in v2: because v2 is fundamentally not compatible with custom CSS, so I believe our original reasoning was that it doesn't make sense anymore to have it. But the feedback we've gotten has made me feel it's important to find a compromise here. It is true that no matter what we do, we'll never be able to cover ALL the bases for everyone, because accessibility is highly personal. Even meeting WCAG guidelines (as we intend to) may not be sufficient for everyone, and we don't want v2 to feel like a downgrade. The compromise I'm currently working towards (and we'll see how possible this is when I actually begin researching implementation) is something like:

0. Add custom selectors to things as staff for you to style. Users should be able to request these. I'd do something like prefix all the classes/IDs with "sb-custom-" so it is very clear which selectors can be reliably used in custom CSS and which cannot when you are inspecting the page. Since this will be a manual and explicit process, perhaps there could even be a reference list of these somewhere (possibly would need to be user-maintained though due to limited staff resources)
1. Allow character-limited custom CSS stored and loaded server side (thanks ); this will likely come with limitations we enforce via validation. For instance, to reduce confusion and bug reports, we may validate it so that you are only styling the classes we provide, maybe have it display a warning if it thinks you are trying to style one of the Emotion-generated classes.
2. Encourage more tech-saavy users to implement more complex stuff through the browser if desired, which gives you total freedom - and we'd assume you know what you're doing if you choose to do this. Having both this AND the validated server-side is great because we can validate the server side CSS to make sure it is safe and won't break anything, since improper CSS could break the site in a way that you can't easily reset it. Whereas if your browser extension's custom CSS breaks Subeta, you can easily fix or reset that yourself through the extension. This works well with the fact that one will persist through login locations and the other is tied to the browser.
3. Find out what people use custom CSS for the most and implement official options that do not require coding. You said "custom CSS has been a haphazardly genius way for users to forge their own accessibility/usability fixes without waiting for staff"; this is a great insight and also an area where we can step it up more. V2 gives us a foundation that makes it easier for us to support such things. V2 gives us a really great foundation for this, with its out-of-the-box support for accessibility, custom themes, day mode/night mode, and mobile responsiveness.

(This is all in the ideas and brainstorming stage though - often we realize something is unfeasible only when we implement it, though on the flip side, sometimes when implementing things we realize new possibilities we didn't see before!)

Thanks. I recommend reading through the reply to in my last staff post on this thread, as it explains the best working compromise I've come up with so far, as well as some of the new constraints we have to work within for v2. I'd love to hear your ideas and feedback on that. :)

Regarding the "cheatie" game modifications: if you're aware that something could be seen as cheating by staff, either don't do it, or file a ticket for a rule clarification to find out if you can safely do it or not. I'll need to clarify with the UA department where the line is for that, but it goes without saying that we won't go out of our way to accommodate rule-breaking CSS.

Hey, I finally actually inspected the HTML a bit, and I noticed something about our UI components (provided by Chakra UI) that is really good news for us. Chakra components have deterministic classes specifically to allow for this kind of customization! For instance, buttons have [tt].chakra-button[/tt] class name, and the entire webpage has [tt].chakra-ui-light[/tt] or [tt].chakra-ui-dark[/tt] so you can even have separate styles for day/night mode with ease.

I asked them and confirmed that these class names can be relied upon even in future versions of Chakra. (They also confirmed there is no official documentation listing these for now, but they would consider adding some in the future.) This is great news because it gives you access to customize a lot of our UI building blocks without us having to manually label those.

Indeed! Part of our decision to use Chakra for UI components is that all of their components meet WCAG by default. We are trying to pay attention to this in our own design decisions as well moving forward. For instance, the colors chosen for night mode and day mode should meet WCAG color contrast guidelines (though it's possible I missed a few places - I intend to go back and polish everything ofc!)

It's a really awesome thing we get with v2, that is so important. It's impossible to make our current website accessible at this point - 16 years with thousands of files. I've always felt a little bad about that, but now we've got an opportunity to make this right.