nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Prevent CSS selectors from changing

Samuel Gfeller

This question is addressed directly to the dev team of Atlassian, but I couldn't contact them.

Work has been stopped on JRACLOUD-63150 (which was about enabling a night mode) and therefore many of us are using the extension Dark Reader in the meantime.

The issue is, Jira cloud has many buttons and other DOM elements that don't look good with Dark Reader (like a button having the same colour as the background without shadow its difficult to differentiate it). As a temporary remedy I added custom rules to Dark Reader which styles those elements, used them for a few weeks and made a pull request that got merged.

Now however I saw that many changes don't work anymore and that's because the class name of the elements I've been struggling to find, changed. The button on an issue had for a long time the class "css-tmtnt9" but now it's "css-s0tfqx". Obviously those names are generated automatically and change with each update?

Anyway in the DOM I found nothing that was consistent, that I could hold on to, to style the elements better.

Now my question: as you don't want to implement a native dark theme now, could you at least bring in some CSS selectors that won't always change?

There are not a lot (maybe a dozen) and I'd gladly tell which ones so that a unique id or class can be made for them. It would be so amazing!

Accepted answers

Jake Miller

Heya Samuel. Unfortunately, the obfuscated css selectors are a deep part of our styling pipelines that are there to avoid unintended styling consequences of similar human curated class names. Classic example of this is a `.container` might be used within another `.container`, but have entirely different contexts/styles. With the obfuscation each is interpreted differently on the frontend, guaranteeing they don't interfere with each other.

Turning the obfuscation off would be a significant effort on our end, and would lead to unintended bugs for our customers. I 100% understand the pain of not being able to have css selectors to bind to (I've tried to do similar things to what you've done in the past and hit the same frustrating wall), but it does guarantee that we don't have unintended css styles being shared between unrelated components.

To the piecemeal IDs and selectors that you mention, we thought of doing something like this in the past before the dark mode efforts originally started. The downside to this is it creates an unofficial API that people bind to and rely on. It ends up creating tech debt for our teams and would be something that would eventually break. In our early reviews we decided against doing something like this due to the extra overhead and lack of future support.

Hopefully in the future once we have tokenized colors, this will all no longer be a problem. When that hits binding style overrides will be tremendously easy to do. Keep an eye on the JAC ticket here for updates on when that work starts up again: https://jira.atlassian.com/browse/JRACLOUD-63150

All comments

Jake Miller

Samuel Gfeller

Alright, thank you for your extensive answer.

> The downside to this is it creates an unofficial API that people bind to and rely on. It ends up creating tech debt for our teams and would be something that would eventually break.

What if we name prepend those IDs with "temp" like so: `#temp-attach-btn` and `#temp-create-subtask-btn`. Or even easier `.temp-class-action-btn` because all action buttons have to have the same color anyway. That makes it very clear that this selector is temporary and not to something they can expect to hold on to create an unofficial API. It's not your responsibility.

Dark mode is something that is almost needed nowadays for some users once you have experienced the benefits of it. Yes it's a bit of an overhead (negligible in my opinion as its at most 15 * 20 chars which is like an unnoticeable drop in the HTML that has probably more than 500k chars (with css + js)) and it will lack future support and "break" once you remove it, but that's kind of what a temporary solution is. And it's not something bad. The future support is a proper Dark Theme, so that's even better.

To me, it seems to be a fair compromise, but probably it's a lot harder than I imagine it and there are very valid reasons why this is not doable.

In any case, thanks again for hearing me and taking the time to answer, I appreciate.

David Wipperfurth

The technique that most people use to deal with class name collisions is class naming conventions, usually with name spacing components. It's both simple, descriptive, and doesn't forsake mountains of web standards and best practices, Pidgeon-hole you, or hamstring others who you want to work with your product.

If the namespacing portion of your naming convention could be programmatically determined, it wouldn't even be that hard to switch back over. You could probably even re-tool your existing compile tool to simply compute the namespace based names instead of computing the random character names.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

atl-dev