As the Prism can be embedded in different environments, there could be already any of the class names that Prism uses, like tag, token, number etc. So it's possible that those styles would override or change Prism's.
The usual way to fix that is to use some prefix for all the classes used in Prism, so we can add the prism- prefix to all those classes: prism-tag, prism-token, prism-number etc.
I can't see any serious drawbacks, the gzip would cover neglect all the added prefixes.
Absolutely not. I鈥檓 very firm on this one. I鈥檓 fed up seeing scripts with awful prefixed class names, making everything uglier just for the off chance there might be a collision.
What we could do, is add .token before each class selector, since every token also has this class as well. So .number would become .token.number.
Well, then I'm for .token for each token selector.
First complaint I get about a real collision, on a real website, I鈥檓 changing the selectors. I don't want to change them for a theoretical fear of a potential collision that might never happen.
Btw, I've added .token in front of the selectors a while ago so closing this.
@LeaVerou First of all, I think this project rocks. Thanks for all the work you've done to make it so simple for people like me to easily add syntax highlighting to our projects.
That being said, I'd like to offer the first "complaint" about a real collision on a real project that I'm working on.
I'm styling a UI component that my team has decided to call a "tag." Tags look like this:

Here's CSS I've written to style these tags:
.tag {
display: inline-block;
max-width: 200px;
margin-bottom: var(--base-spacing-xs);
padding: var(--base-spacing-xs) var(--base-spacing-sm);
border: 2px solid var(--base-accent-color);
border-radius: 100px;
color: var(--base-accent-color);
font-size: var(--font-size-sm);
font-weight: var(--font-weight-bold);
line-height: 1;
text-transform: uppercase;
text-overflow: ellipsis;
overflow: hidden;
white-space: nowrap;
}
The problem here is that <span class="token tag">...</span> is inheriting the styles from our .tag component.

Obviously, when removed, the styles are fixed:

I understand this may seem like an annoying request... If I had the domain knowledge, I'd be happy to submit a pull request on this issue.
Of course, I'm able to fix the issue myself if I were to prefix my own class names, or add the increased specificity by nesting my selectors, e.g...

...but the way the classes are currently named in PrismJS prevents it from being used in combination with literally any other CSS library or custom CSS that include class names such as .token, .tag, .punctuation, .number, etc. at the root level.
The solution @kizu suggested seems pretty standard, and has no obvious drawbacks.
Hi @jonmilner,
When I said "first complaint I get, I change the selectors", it was 2012 and Prism had just been released. Now it's way too late, as it would break tons of sites, plugins, themes etc.
Having human readable names was a design decision that I made pretty early on in this project. I knew there was a chance of collision, but the advantages outweighed the disadvantages and there are plenty of workarounds for collisions.
That said, perhaps this can be solved by just prefixing all Prism selectors with "code " so they don't apply to any random area in the page. Can anyone think of any drawbacks to this?
Hey @LeaVerou, thanks for the quick response.
I think prefixing all Prism selectors with code is an excellent solution that would solve this problem.
For what it's worth, another popular syntax highlighting library, Rainbow, has the same issue.