Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Prevent CSS selectors from changing Edited

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!


1 answer

1 accepted

2 votes
Answer accepted
Jake Miller Atlassian Team Feb 24, 2021

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:

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. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira Software

Presenting the "Best of 2020" Jira Software roundup!

Catch up with Atlassian Product Managers in our 2020 Demo Den round-up! From Advanced Roadmaps to Code in Jira to Next-Gen Workflows, check out the videos below to help up-level your work in the new ...

7,142 views 8 28
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you