css system adds .charsheet even on selectors that include a .sheet-rolltemplate selector which ought to have a .textchatcontainer instead.

if you have a css file that contains a selector  " .sheet-rolltemplate-myselector {"       it works fine.  But if you have  a.sheet-rolltemplate-myselector { it does not work. If you inspect the item, you find that the roll20 system has automatically inserted a .charsheet into the selector, so that effectively it is  .charsheet a.sheet-rolltemplate-myselector This is of course ridiculous, since .charsheet is for character sheets only, and .sheet-rolltemplate is for chat windows only.  If there is a .sheet-rolltemplate selector, the roll20 system should instead of automatically inserting a .charsheet, it should automatically insert a .textchatcontainer selectory instead. As the system exists, the only way to style things in the chat window is to ether use inline styling, or to only use selectors that start with .sheet-rolltemplate. Using anything else, such as a a, span, or div selector causes it to add the .charsheet selector, even though the selector is obviously meant for the chat window since it uses .sheet-rolltemplate selectors.  In the following... note that all the selectors that include an "a" or an "a[href^="!"]" all have a .charsheet in front of them and are greyed out, because they are not activating because the .charsheet is only in the sheet, and the .sheet-rolltemplate tags are only in the chat window.  The problem is that I am trying to override the color of buttons in the chat window, and the following has a very high specificity. The system automatically and incorrectly adding .charsheet in front of .sheet-rolltemplate entries instead of the sheet automatically adding .textchatcontainer tags means that any specificity must be achieved using ether inline styling or using only .sheet-rolltemplate tags.  In the past I used inline styling, but I am trying to make a darkmode version of the sheet, and inline styling is not appropriate for that.  For right now I have got a workaround by adding bogus classes.  .sheet-rolltempate-myselect.sheet-rolltempalate.ireallymeanit.sheet-rolltemplate.ireallyreallymeanit allows me to get higher specificity than the default purple, but what would be even better is if the roll20 system did not erroneously insert spurious .charsheet specifiers into selectors with .sheet-rolltemplate specifiers, and instead inserted the correct .textchatcontainer specifiers that .sheet-rolltemplate classes are meant to interact with. Thank you.

Hi Chris, wouldn't any links included within a roll template macro originate within the roll template class? example; .sheet-rolltemplate-myselector a[href^="!"] {...} and for darkmode; .sheet-rolltemplate-darkmode. sheet-rolltemplate-myselector a[href^="!"] {...} This is the pattern I've always used to style links for roll templates and it's worked fine. Apologies if I'm missing the point.

In this usage, I am not actually using rollformat as a roll. I am just sending html to the chat window. In this case I am sending some buttons to the chatwindow under API control. I am using the .sheet-rolltemplate classes to style these buttons because those are the only ones that roll20 does not put a .charsheet in front of.  All of this works just fine, except for the systems tendency to put .charsheet in front of anything with a selector element that is not a .sheet-rolltemplate, even if a .sheet-rolltemplate is part of that selector. I mean if there is a better way to style things sent to the chatwindow other than using inline style tags I am perfectly open to it. 

I see.  I incorrectly assumed these were links(or whatever for that matter) inside a roll template. Seems like roll20 needs to make the logical fix/change to accommodate.  Have you sent a bug report to help get the Devs attention? 

No, I thought I would try here first. Sending a bug report now.

OK this will sound like a crazy workaround, but I found cases were the .charsheet was not added in my CSS, and couldn't understand why. Try and error showed me that it actually depended of where the block selector {} was in my CSS, so I ended narrowing it down that it was coming after another declaration, and finally after narrowing it down this declaration I finally got the following: This snippet will not work.  .sheet-darkmode .sheet-rolltemplate-chatbox2 { /*Snippet 1, won't work because it adds .charsheet*/   background:         var(--outline-color); } /*Don't ask why, but overrides a roll20 bug that breaks the CSS anytime you are styling stuff in the textchatcontainer*/ .sheet-darkmode { ::placeholder {}} .sheet-darkmode .sheet-rolltemplate-chatbox2 { /*Snippet 2 works as "intended", i.e. sheet-darkmode .sheet-rolltemplate-chatbox2 stays without the .charsheet*/   background:         var(--outline-color); }

To be clear It is all in one line to be compact , but it is not part of the same declaration . . . .sheet -darkmode { : :placeholder { } } /* This is its own declaration for the .sheet -darkmode : :placeholder selector , declared as a nested declaration . . . This does nothing but for a mysterious reason , changes the next declaration* / .sheet -darkmode .sheet -rolltemplate -chatbox2 { /* This is the actual declaration . . . Without the previous declaration the roll20 interpreter for CSS would actually send it as .sheet -darkmode .charsheet .sheet -rolltemplate -chatbox2 , but for a strange reason , having the previous declaration avoids this* / . . . } Once you have this .sheet -darkmode { : :placeholder { } } declaration , you could have a separate selector declaration just after that doesn 't get introduced the charsheet . Seems to work even if it is a comma separated of various selector for example : .sheet -darkmode .sheet -rolltemplate -chatbox2 , .sheet -darkmode .sheet -rolltemplate -chatbox3 { } But if you remove the .sheet -darkmode { : :placeholder { } } , or move .sheet -darkmode .sheet -rolltemplate -chatbox2 somewhere else in the CSS that is not immediately after the .sheet -darkmode .sheet -rolltemplate -chatbox2 , the fix stops working . . This all seems very strange, and a crazy workaround to the bug reported by Chris, but it actually solved my dark mode development issue

I just wanted to bump this post, because while we do have an explanation for why it is doing this, and a workaround that can sometimes be made to work, we still have issues, and the workaround seems to rely on a bug.&nbsp; Just to recap all the issues from both this post and from&nbsp; <a href="https://app.roll20.net/forum/post/11970737/sheet-rolltemplate-darkmode-not-applying#post-11973850" rel="nofollow">https://app.roll20.net/forum/post/11970737/sheet-rolltemplate-darkmode-not-applying#post-11973850</a> The issue is trying to style html sent directly to the roll20 chat window.&nbsp; We have found that we can style stuff that has a sheet-rolltemplate tag, and so we are applying sheet-rolltemplate classes to text that are not strictly speaking rolltemplates.&nbsp; In the post linked above, we find that these get the sheet-rolltemplate-darkmode class added and removed when entering or exiting darkmode, and also when using actual rolltemplates, but not when the api sends stuff directly to the chat window without a real honest rolltemplate being used.&nbsp; In this post we discuss problems with applying any other css selectors. In these two threads we dive quite deeply into the problem and a suggestion of how to fix it. If I might suggest, it seems like a large part of the problem is that we are trying to use sheet-rolltemplate for something other than rolltemplates.&nbsp; Might you consider just adding classes that specifically allow us to apply css formating to text sent directly to chatwindows that are not sheet-rolltemplates? I understand that you don't want to allow sheet authors to override the formatting of stuff that roll20 sends to the chatwindow, but how about adding a set of classes specially for formatting API messages? Specifically, you have .charsheet, which is the VTT main window only, and that css can modify. and you have actual sheet-rolltemplates that are for rolltemplates only, and sheet authors can modify. And you have some sort of class to identify everything else that roll20 sends to the chat window, that you don't want the sheet authors to modify. Can we add a 4th class of things, maybe sheet-scriptmsg that is specifically for API scripts sending html to the chat window, and that the sheet authors very specifically can modify. And that when there is a sheet-scriptmsg class, roll20 does not automaticall add a .charsheet selector in front of it, because it knows it is not a .charsheet selector because it contains a sheet-scriptmsg class.&nbsp; This I think would solve everything. All of these would be under and accessible to .sheet-darkmode. Developers would not have to try to style non-rolltempalte messages using rolltemplate classes, so they would stop doing that if there was a class that was actually meant for that.&nbsp; Thank you.