Empire theme happens to use a class page-content.
Trying to style it with “Custom CSS” fails:
.page-content {
max-width: none;
}
I can guess where it’s coming from, but obviously a false positive.
@Alan_G or @Liam-Shopify ?
Hey Tim - is this happening with just the Empire theme? If so, the best option would be to flag it to their team here: https://support.pixelunion.net/hc/en-us/requests/new
Of course not, it just happens that they have this class name in their theme.
If I try using this CSS code in Dawn (which does not have this class itself, but, say product description may have it) the error message is the same.
Does any CSS property work?
Yes, other rules work, it’s just “.page-content” selector triggers false alarm in back-end and it reports “not all media query supported”.
Reviving the topic again – is it intentional to not accept any CSS rules which has
content: "...";?
For example,
.price--on-sale:after {
content: "Closure Sale!";
}
results in “Online Store editor session can’t be published” when saving.
Not mentioned in https://help.shopify.com/en/manual/online-store/themes/customizing-themes/edit-code/add-css#css-considerations
A class needs to be available in the section that you’re editing the “Custom CSS” in. Otherwise it will fail.
However, it seems weird that
.a-real-class-in-this-section:after {
content: "any text";
}
won’t work.
I’ve just tested it, and seeing the same. Double checked that the class existed in the section, and was also able to save
.a-real-class-in-this-section:after {
position: absolute;
}
Also not a double-quote " issue, as alternatives threw the same error.
Adding it directly into the .json file gave me this error: Invalid property value: content, which indicates that content is indeed not allowed by purpose?
2 Likes
Thanks @curzey for digging into this and @tim_tairli for flagging. We do have limitations on CSS customization in themes in general (there’s a bit more info on this here), so I think it’s possible this may be an intentional limitation, since technically, the content property in CSS can be used to inject text or other content into the page, which could potentially lead to bypassing theme-specific content/security controls, if that makes sense.
I’ll reach out to see if I can confirm this with our product team and loop back with you folks in the thread once I have more info/next steps to share.
2 Likes
It could indeed make sense, I just think the error message and missing specific documentation is misleading 
Thanks!
1 Like
Well, to add insult – editor does not allow me to add a rule for .page-width class now!
I mean, I am all in to use “Custom CSS” settings rather then editing theme code (as theme code edits do not persist during theme updates), but with these limitations it’s really hard to promote it.
Are you sure .page-width is present in the specific section you’re editing?
Also, I dont (at least personally) think “Custom CSS” is an alternative to theme code. It’s more supplementary for small section-scoped stuff for merchants to quickly add something. It will always - IMO - be advised to correctly structure and add changes to the theme code.
Mate, of course it’s there.
And of course, “Custom CSS” is not an alternative to a quality theme build/rebuild.
No problem if you have/are a dev to support this modified theme.
However, for merchants coming to Shopify community forum and asking how to fix something it’s much better option then code edit.
There is a bunch of cowboys there coming with “insert the code above </body> tag” and then the merchant is left with a theme which no longer updates smoothly and side-effects from the weak element selectors…
Ok, and then the new theme version is published and you need to re-apply all these correctly structured modifications…
It was ok when theme updates were few and far between, but with 15 major versions of Dawn in 4 years and a second major version of Horizon?
I can also replicate the issue:
page as part of a custom CSS selector seems to be forbidden, don’t know why.
Still, @curzey point still stands, custom CSS is the not the place for this kind of customization, here’s one of the best way to go:
{% if section.settings.full_width_section %}
<style>
#shopify-section-{{ section.id }} .page-content {
max-width: none;
}
</style>
{% endif %}
{% schema %}
{
"name": "...",
"settings": [
{
"type": "checkbox",
"id": "full_width_section",
"label": "Full width section"
}
]
}
{% enschema %}
Hmm, I do not see how it’s better the using “Custom CSS”?
I see how it’s worse – every theme update you’d need to transfer this code to the new theme version.
What kind of content is appropriate for “Custom CSS” then in your opinion?
I have not found any good use-case yet 
But to be fair, I’m sure there were more shenanigans with custom CSS in the past.
Right now, I just checked and it seems the custom CSS just appends a <style> tag, doing ultimately the same thing as my code.
So go ahead, and let’s push Shopify to drop the arbitrary limitations on custom CSS selectors ! If you can share the feedback @Alan_G, thanks in advance 
In the meantime, there are no limitations when you edit from the code, so you can just go the relevant template file and edit the custom_css property properly there 
2 Likes
I think you misunderstand a lot of what we are saying, and thats fair enough. I’ll stick to my point and I see @teamdijon could replicate your issue. So let’s keep it at that..
You mention you’re a merchant coming to Shopify community forum - here I’ll refer to the merchant forums at https://community.shopify.com/, instead of the developer forums.
Theres a lot more nuance to where code should be placed, than just bad practice of "insert the code above </body> tag” and theme updates.
I’ve noticed this too on various themes, usually end up just bypassing with custom.css file and drop it in there.
Notice it mostly on Dawn on some sections trying to amend the .page-width class.
This has been an issue for a while. Any class names with “page” in the name do not work - not sure why. Here’s a workaround that I’ve seen out in the wild:
[class*=“page-width”] {
}
Hope that helps in a pinch!
2 Likes
Thanks everyone for the continued discussion. I really appreciate @Anne sharing that workaround with the [class*="page-width"] selector - that’s a clever solution.
I’ve confirmed with our product team that these are indeed current limitations in the Custom CSS feature and there isn’t an “official” workaround we can share at the moment.
While I can’t endorse workarounds since they’re not part of our documented features, I appreciate the community sharing solutions that work for now. Just keep in mind that unofficial workarounds may not always continue to work as we update the platform.
I can’t share any specifics, but I did also want to mention that streamlining this behaviour and removing some blockers is on our developer’s radar, but not currently in the roadmap. It is something that we have eyes on however, so I did want to share this here.
In the meantime, for those who need features like this immediately, you can still add similar workarounds through the theme code editor (or locally if you’re building your theme in your preferred code editor) rather than the Custom CSS field, as @teamdijon mentioned.
Hope this helps!
1 Like