Fix: highlight active line in language-specified codeblock

[alythobani]

Description

Fixes #288 as described in the "Additional context / Possible solution" section. I.e., this PR now has the active codeblock line highlighted by updating the --gradient-background-colour variable instead of the background property (which was getting overridden by the update around line 144 in codeblocks.css).

Note also that as mentioned in #288, a fix that would overlay highlights (e.g. active highlight layered on top of hl highlight, so that user can still tell the current line has another highlight on it) could be more ideal than this fix, where the hl highlight is fully replaced by the active-line highlight. But this PR's approach might be ideal as a quick initial fix without needing to adjust the DOM structure (e.g. adding another div to allow for overlapping highlights).

There are also multiple !important flags involved here, adding to the complexity, so a fully ideal fix would maybe involve replacing those with a different approach. But likewise here, this PR's approach could be better as a simpler fix for now.

Motivation and Context

Fixes #288

How has this been tested?

Tested locally by updating styles.css with the described line change, and seeing it work.

This change may or may not affect other areas of code; I haven't spent too long diving into this so far, just came up with this quick potential fix after some reading and experimentation.

Screenshots

Before fix:

After fix:

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• I have checked no similar existing pull requests exist
• I have checked the CONTRIBUTING document
• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly

[alythobani]

Removed this [Unreleased] heading since it looks like all the below changes are already released

[mayurankv]

Hiya sorry, this title is of equal level to the version titles below and is empty as I haven't locally developed any changes that are yet to be released. But if for example, I added a new feature X and pushed to github, I'd note it here and then when the new version of the plugin is released, this would automatically get set as the new version title. i.e. Since your changes aren't released as a new version yet, I would put them under 'Unreleased' and when a new version is pushed they would automatically be listed under the latest version. Does that make sense? (Not sure this is the best method since this is the only repo i have in any level of 'production' status but it's worked for me so far so if that's not traditionally what's done, always happy to update).

[alythobani]

Ohh gotcha that makes sense! I'd missed the section above where it's mentioned that the changelog is based on Keep a Changelog.

I can think of a couple slightly less ambiguous approaches to this (and e.g. Common Changelog avoids the Unreleased section entirely for a couple reasons), but since this is already following Keep a Changelog, it's probably better to keep it as-is than to diverge from that documented format.

Reverted back!

[mayurankv]

Hi! Thanks for the fix! I need to do some quick recap to see whether this fix has no repurcussions and to see if there was a good reason the previous css line was there. If not, I'm happy with the fix. However, could I request that you revert the Unreleased change (or suggest an alternative to the workflow I described in the other comment) before I merge this?

[alythobani]

While we're at it - this was a broken link (missing the repo part of the URL), so I went ahead and fixed it with an absolute link if that sounds good to you

[alythobani]

Btw, I also noticed that manifest.json has a broken Buy Me A Coffee link. If you want I can also go ahead and add that quick fix to this PR (or separate PR if you'd prefer).