Support for simplified or alternative theme for inline code than for block (a la Slack's single- vs. triple-backtick)
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 13k
- Forks
- 1.4k
- Avg merge
- 15h 36m
- Merged PRs (30d)
- 3
Description
Motivation
Typically, I find myself making reference to code in two different ways: sometimes inline code references makes sense within the flow of a block of text (like if I make reference to setting display:flex; I don't necessarily want the full-blown background-color/text-shadow/font/font-size change... just the foreground reserved word/syntax coloring portions. I don't want my font/line height/element display renderer changing necessarily.
vs
(except... yanno... with syntax highlighting?) By virtue of the fact that the background color would be shifting from a dark to a light one precludes a simple css override. That white foreground text is gonna be hard to read atop a white page background.
Description
I'd like to be able to specify a reduced ruleset, stylesheet, and/or theme specification for mid-paragraph <code>that appears within an inline</code> tag, vs. a dedicated
<pre><code>block in which I'm expecting to give the whole block-level element to the endeavor</cod></pre>
Alternatives
Well, since I cannot fathom I'm the first person to ask for this in the decade Prism's been in use, I'm kinda hoping I'm just missing something blatant in the API docs and someone will say, "here, moron!"
Notwithstanding that, My next intention will be to define a high-specificity style override comprised of a CSS reset followed with what amounts to a secondary redefinition of the styles I want being left alone (this is the main reason I'm trying to avoid this approach; DRY it s not). But, I mean, let's face it: Prism enforces certain tag structures. This suggests that the selector code is already fairly-well scoped (I confess I've not dug through your codebase yet).
Assuming that's doable without too much overhead, it seems like it should be little enough effort (assume the aforementioned presupposition regarding selector scoping is true) to either add some exclusionary code to the DOMContentReady event such that it applies one of multiple themes its found defined in some global constant or conditional rule being set at the :root scope, or, failing that, to arbitrarily set some selector conditional to the application of the style code it has now (span.inline>pre:first-child:last-child>code or somesuch), to only perform the override when the specified code is the only child inside an inline tag with a class of inline or similar.
Please understand: I'm not rolling up here to just make demands like some entitled dick. I work in the same OS spaces y'all do, and I know exactly how much thankless work goes into maintaining tools like these. If there really is no fix for this or provision in place for the functionality, I'll go beat on it with a hammer myself until I get it rolling, and then open a PR. I'm just hoping this is simply obliviousness on my part. I did observe the long-closed Issues 643 and 807, but neither really seemed to be asking after the same thing, nor did either really receive an official solution, and both were closed while Obama was still president. A lot "could have" changed, lol.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with Prism's API documentation and review the referenced prior issues 643 and 807 to determine whether inline and block code already have separate styling hooks. Define how a reduced inline-code ruleset or theme would be specified while preserving syntax highlighting, then verify that inline code and block code render with distinct, readable styles.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100