Provide a global way to disable auto highlighting

Similar to #366, this is very cumbersome when working with something like a CMS that aggregates is assets and doesn’t allow extra attributes (like data-manual) to be set on the script tags.

The only recourse I had was to manually “hack” the HTML template: https://github.com/unicorn-fail/drupal-bootstrap.org/blob/831f047cfb7125778364cbccd2db34256b643222/docroot/sites/all/themes/bootstrap_subtheme/templates/system/html.tpl.php#L77

I’m ok with this solution, temporarily, but it doesn’t bode well in the long term for performance reasons. Adding the file in this fashion prevents the file from becoming aggregated and causes an extra HTTP request.

I really don’t care either way if it’s called window.PRISM_JS_MANUAL or something else. The fact is that there needs to be a better way for Prism to detect when it’s not supposed to run automatically than checking for a data attribute.

[LeaVerou]

@markcarver Wow. You do realize that this is an open source project and all of us are working on it on our free time, right? We’re not your employees, so I would advise you to watch your tone. And to think I didn’t even reject your suggestion, lol. I wonder what kind of reaction that would have ensued!

and need this pretty major bug fixed for very involved setups.

I’d be careful labelling this as a “major bug”. Thousands of people and big websites use Prism without having any issues with this. Just because it’s causing trouble in your specific setup does not make it a major bug. It’s not even a bug, you’re requesting a feature.

Except that Prism (itself) isn’t HTML, it’s written and executed in JS. When a website adds prism, it’s executing JS, not HTML. When highlighting code on node.js, it’s executing JS, not HTML.

Yes, Prism is JS, that doesn’t mean everyone who uses it needs to know JS. That’s the whole point of abstractions. You use software coded in C++ or even assembly daily, that doesn’t mean you have to know these languages to use this software. Also, given that I did not disagree with you about it being a good idea to have a JS property, it’s still unclear to me why you’re complaining. Just the existence of the HTML setting bothers you?!

as evidence from the divisiveness of even the collaborators in the project itself above

What divisiveness? @Golmote suggested three solutions, indicated that he prefers the 3rd, and I agreed with his suggestion and proposed a few tweaks. That’s not divisiveness, that’s how projects work.

[markhalliwell]

It’s funny how anything done via JS is considered “the normal way” by some.

I meant that there is no (JS) configurable “options” or “settings” anywhere in Prism’s JS code. Almost ever single JS plugin/app out there has this… that’s what is “normal”. This isn’t a radical idea…

I consider an HTML API just as important (if not more important) than a JS API.

Except that Prism (itself) isn’t HTML, it’s written and executed in JS.

When a website adds prism, it’s executing JS, not HTML.

When highlighting code on node.js, it’s executing JS, not HTML.

If a site needs to load additional plugins/events/whatever BEFORE Prism “autoloading” occurs, it should be able to set some configuration (in JS somewhere) that disables this “autoloading”.

Many people who use Prism cannot write JS.

Seriously?! What kind of BS reason is this? It’s certainly not reason enough to chastise those who do know how to “write JS” and need this pretty major bug fixed for very involved setups.

Allowing configuration via HTML is not a hack.

On normal DOM element, perhaps, however in this case… it most certainly is. There are too many assumptions with this approach, the least of which that there is some “dedicated <script> tag” for including Prism. As mentioned above, in CMS/CMF applications… this is rarely the case when these scripts are aggregated/minified.

Furthermore, and expanding on the “normal” comment above, the fact that this type of configuration has no native JS equivalent is massive anti-pattern in almost ever single piece of JS software out there. So yes, this type of configuration is a “hack”, for the simple fact that it’s using HTML to configure JS.

Try being a little more inclusive in your thinking.

Try not insinuating that I’m “close minded”. It’s clear from my comment above that I was relatively “happy” with the temporarily solution. That solution, however, has since stopped working now that the site has undergone some performance tuning and now aggregates/minifies absolutely everything.

In any case, I wasn’t even arguing that this is sufficient, I said myself that we should add a JS property for this as well, so not sure exactly what your problem is.

My problem is that you essentially pawned this pretty major bug on other (non-project-specific) people:

“It’s probably a good first pull request, if there are any takers! 😃”

1. This issue isn’t something that can be “easily fixed”, if only because:
2. There will need to be a concise plan around how to move forward on this topic (as evidence from the divisiveness of even the collaborators in the project itself above).
3. Continues to ignore the problem by shifting responsibility from the ones actually responsible for the project. Granted, I get how open source works, but considering that it’s already been almost a year and a half and there have been no “takers”… that should have been a sign in and of itself…

My “problem” is that I don’t particularly enjoy comments that just add more fluff to a conversation without actually adding anything to the conversation or even attempt to fix it.

My “problem” is that I need a more stable and standardized solution for this issue and it can only be provided upstream given how this code is constructed.

My “problem” is that it’s been nearly a year and half with practically no progress from the initial report.

---

I’d prefer Prism.manual

I’d prefer that this project stop using anti-patterns (arbitrary naming) and instead use a dedicated configuration object (options/settings/config/whatever…) and property:

Prism.options.autoHighlight

1. It properly identifies what this configuration is/does.
2. It places this configuration is an appropriate namespace.
3. By virtue of the above, also allows for any future configuration growth.

This is what is “normal” looks like in JS…