Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Namespace/prefix all the classes? #6

Closed
kizu opened this issue Jul 11, 2012 · 7 comments
Closed

Namespace/prefix all the classes? #6

kizu opened this issue Jul 11, 2012 · 7 comments
Labels

Comments

@kizu
Copy link
Contributor

kizu commented Jul 11, 2012

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.

@LeaVerou
Copy link
Member

Absolutely not. I’m very firm on this one. I’m 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.

@kizu
Copy link
Contributor Author

kizu commented Jul 12, 2012

Well, then I'm for .token for each token selector.

@LeaVerou
Copy link
Member

First complaint I get about a real collision, on a real website, I’m changing the selectors. I don't want to change them for a theoretical fear of a potential collision that might never happen.

@LeaVerou
Copy link
Member

Btw, I've added .token in front of the selectors a while ago so closing this.

@jonmilner
Copy link

@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:

screen shot 2016-03-29 at 4 19 24 pm

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.

screen shot 2016-03-29 at 4 29 39 pm

Obviously, when removed, the styles are fixed:

screen shot 2016-03-29 at 4 30 13 pm

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...

screen shot 2016-03-29 at 5 00 34 pm

...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.

@LeaVerou
Copy link
Member

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?

@jonmilner
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants