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

difficult to override styles #42

Open
rlskoeser opened this issue Aug 21, 2023 · 5 comments
Open

difficult to override styles #42

rlskoeser opened this issue Aug 21, 2023 · 5 comments

Comments

@rlskoeser
Copy link

Thanks for this useful library!

I'm having trouble overriding styles - I think because your block includes the prism css with the content, so it takes precedence over my site-wide styles that are included in the page header.

Wondering if instead the prism styles could be loaded in the header if the page includes a code block, so that local styles could be given precedence. Could maybe be done as a new template tag, or a revised version of the existing load_prism_css tag.

@rlskoeser rlskoeser changed the title difficult override styles difficult to override styles Aug 21, 2023
@FlipperPA
Copy link
Owner

Unfortunately, this gets really tricky. With the way Wagtail blocks work, I can only inject code into the rendered block section. That's why the CSS is injected here:

Can you override with !important? I know that's a cheese, but hopefully, it works.

@rlskoeser
Copy link
Author

Thanks for responding so quickly!

Here's what I've implemented locally:

in my template header, before I include project-specific styles, I added this:

{% for block in page.body %}
    {% if block.block_type == "code" %}
        {% load_prism_css %}
        {% endif %}
    {% endfor %}

And then I overrode the code_block.html template and commented out the load_prism_css call.

This might be loading prism multiple times for multiple code blocks on the same page, I haven't checked...

I do still actually have to use !important for some of the styles (I think because the prism styles are more specific, but haven't investigated deeply); but now my local styles are being applied. When the stylesheets were loaded in the other order, the override styles (like font size) weren't working at all.

So it's feasible, but would require an additional setup step for people using your library. Wondering if this could be optional (non-default) behavior configured by a django setting? I'm willing to submit a PR for that if you're interested.

If you think there's a simpler solution for this, please suggest!

@FlipperPA
Copy link
Owner

I think what we might be able to do is modify the settings. Right now, we set the default theme to coy if the setting isn't provided: https://github.com/FlipperPA/wagtailcodeblock/blob/main/wagtailcodeblock/settings.py#L26-L31

We may be able to make it so that if you set WAGTAIL_CODE_BLOCK_THEME = None in your Django settings, we don't include the CSS at all and leave it up to the developer. Would this work? I'll have to noodle on it for a day or two.

@rlskoeser
Copy link
Author

@FlipperPA that's a nice thought - then you can just set this config and load the theme yourself if you want it handled elsewhere. Seems like an elegant solution to me.

@FlipperPA
Copy link
Owner

I'll think on it for a day or two (I'm going to be traveling) but will try to get this in the next release. Cheers!

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

No branches or pull requests

2 participants