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

[Request] Persisting class names inside <pre> #3712

Closed
daniyalhamid opened this issue Feb 7, 2023 · 1 comment
Closed

[Request] Persisting class names inside <pre> #3712

daniyalhamid opened this issue Feb 7, 2023 · 1 comment
Labels
cantfix / wontfix Impossible to fix enhancement An enhancement or new feature parser

Comments

@daniyalhamid
Copy link

Is your request related to a specific problem you're having?
A clear and concise description of the problem itself. Ex. I'm always frustrated when [...]

There should be an option perhaps to persist existing class names inside pre / code tags, for example:

<pre>
const foo = <span class="wavy-error">bar</span>;
</pre>

The solution you'd prefer / feature you'd like to see added...
Allowing certain class names to be persisted and not removed when parsing happens would be a great addition.

Any alternative solutions you considered...
I tried creating a custom plugin for this, but can't figure out much with limited documentation on the subject.

Additional context...
The desired result I'm trying to achieve is like the following screenshot:

Screen Shot 2023-02-07 at 3 20 27 AM

If it's already possible somehow to persist a class name, I'd really appreciate some guidance.

@daniyalhamid daniyalhamid added enhancement An enhancement or new feature parser labels Feb 7, 2023
@daniyalhamid daniyalhamid changed the title [Request] Short description of the new feature... [Request] Persisting class names inside <pre> Feb 7, 2023
@joshgoebel
Copy link
Member

joshgoebel commented Feb 7, 2023

This once upon a time was a feature, it's since been removed. This is a feature most users do not need and it only increases the risk that 99% of users shoot themselves in the foot introducing HTML/JS injection security issues - to assist the 1% of users who could benefit from this feature. Simply disallowing this entirely allows us to make it easier to catch these vulnerabilities during development - rather than after a project goes into production.

Ref: #2889

This can be done easily enough using a plugin (capture HTML before highlight, carefully re-insert it after) - someone just needs to step up to write/maintain it. The old code may or may not still work and is not supported.

@joshgoebel joshgoebel added the cantfix / wontfix Impossible to fix label Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cantfix / wontfix Impossible to fix enhancement An enhancement or new feature parser
Projects
None yet
Development

No branches or pull requests

2 participants