I did some research before jumping in but apparently not enough.
I am a consultant on a grant project and we settled for an omeka.net account to keep the technical requirements low.
The themes offer little to no customization and I was going to rely heavily on the custom css plugin only to find out to my horror that it is severely limited, it does not allow font imports from external sources, and worse still it checks your css agains a spec validation document that is more than a decade old.
Iâm having to rely on flashbacks of early 2000 css tricks to get stuff working that would require one line in modern CSS.
on a minor but equally annoying note the middleware changes all rgb color coded to hex color codes making it really horrible to keep track of what color is what.
why is this not a priority?
I hope this can be of help to anyone that is doing that preliminary research in the future.
I suggest, when youâll be less âhorrifiedâ, to visit the page GitHub ¡ Where software is built of the CSSEditor plugin and to report there the issues youâve found.
In CSS Editor, you should have a spot at the bottom to add External stylesheets for font imports. While it doesnât update the CK Editor built-in styles, it will make it able to assign that font to whatever headings, etc, that you want.
As for the colors, one thing that I do on all of my sites is have a commented section at the top of the CSS Editor with all of my colors listed and named. It is usually just the hex code, but if it turns out that I need the rgb, I will add that too.
Iâm not sure what you mean about modern CSS not working when the âold-schoolâ early-2000s tricks do, but you may want to make sure that you are targetting the right thing and that it doesnât have limitations because of how a parent is styled. You probably know this, but it helps a lot to do all the styling in the browser developer panel and jot it all down as you go.
As far as customizable themes go, I think Lively may be the most customizable so far (with color options anyway), from the âfront endâ at least. If you know how to dig into the Theme files on the backend, though, you can customize to your heartâs desire. I am currently attempting to make a super-customizeable version of Freedom, but since I am an artist and relatively new to the art of digging into code, I have no idea when Iâll be done or if Iâll be able to get it to do what I want; but if I do, Iâll let you know.
@megtrip3 The poster here is using Omeka Classic, not S. Though itâs a good point that the Omeka S CSS editor doesnât have the same limitations as the Classic one.
We have some constraints that affect what we can enable in the Classic CSS editor, but we have made improvements over time and are open to hearing about particular pain points.
Oops I didnât see that. In that case, though, I can definitely relate. I had a breif sojourn into Classic a year or so ago and was highly frustrated after getting used to Sâs CSS Editor.
Hi Everyone sorry I couldnât circle back to this sooner.
Thanks everyone for the participating in the discussion.
I will clarify a few points to help move the discussion to a productive place:
Yes I am using omeka classic (this is the omeka classic subforum is it not?) in the omeka_dot_net managed environment.
Yes I understand that in a managed environment checking against malicious code injection is super important.
With that being said the version of the tidyCSS library included in the CSS editor plugin reports a copyright notice from 2007 which would line up with the fact that it eliminates everything past the CSS2.something spec.
Things like tag:after {content:âpseudoelemâ} get cut out. @import statements get cut out. making it impossible to use google fonts for example
and even comments get cut out. that one just feels mean.
a:hover {transition: all 0.5s ease;} just gets cut outCSS3 Transitions | Can I use... Support tables for HTML5, CSS3, etc
also omeka_dot_net does not allow for the upload of resources to be used on the site as woff woff2 files are not allowed to be uploaded and direct linking on omeka_dot_net is non trivial to figure out.
All I really need is to be able to add custom fonts and style my page using modern CSS.
I would love an update of the tidyCSS library but I would take a hacky suggestion on how to get it done in the short term.
thank you again!
Editorâs note: I had to replace all the . with dot in omeka_dot_net to avoid the forum to recognize that as a link as I am limited to two links for post.
Also the issues Iâm having are very much not targeting related, I can guarantee that as, modesty aside, Iâm very competent in web design.
we are talking about serious limitations to the platform being stuck to CSS2 only styling.
and a subset of it at that.
thatâs very strict in 2025 even for the classic platform.
Yes, you are posting your topic in the Omeka Classic category. I apologize that I was not paying attention when I first replied to your post. In hindsight, it explains why some of what you were saying didnât sound right to me. So I apologize for giving you a wrong answer to your question.
That being said, it really does sound like youâd like Omeka S much better than Omeka Classic. The CSS Editor for âSâ rarely, if ever, changes what you write in it; if itâs not correct CSS, then it simply doesnât work. Everything you add in the editor gets made into a custom CSS stylesheet that it adds over everything, so it will overwrite any other styling, although occassionally you may need an !important added on if the original stylesheet is trying to muscle its way back to the forefront.
This is just my 2 cents since Iâm guessing even the most competent web designers prefer doing things the âeasy wayâ over the âhard wayâ when given the choice, and Omeka S really is much more user friendly than Omeka Classic. If it is possible for you to switch, I highly recommend it.
The issue is that another team member suggested classic over S and we are committed to it now. ( i think they liked the idea of a managed environment at the time )
we have data in the system, workflows in place it would be too much of a change and we are ready to live with it if we must rather than changing major parts of the project.
stupidly when i tested the custom css plugin I just did a quick basic test nothing fancy and did not catch the trimming of content ( I would advice at a minimum to make users aware of this limitation with a disclaimer in the plugin page, we would have moved to S immediately months ago)
but more importantly is classic still being maintained? is there hope that perhaps you could stop enforcing a css standard from 20 years ago on your users?
it would be a fairly minimal change with a huge impact.
If that is not the case i think we might indeed cancel our omeka.net subscription but it is a pity because a relatively small change would extend this platformâs life by at least another decade.
I donât know the answers to your questions because Iâm not part of the Omeka TeamâIâve just been using Omeka S for a few years and sometimes feel like I can chime in on a discussion.
Before you give up on Omeka, know that there is a module for Omeka S (aka plugin) that makes it easy to switch from Classic to S. It is well-documented in the User Manual. So if Classic isnât cutting it, you may be able to preserve at least some of your workflow and keep all of your data instead of having to start from scratch somewhere else.
Now I will bow out of this discussion since I feel like Iâm only ramping up your frustration instead of helping like I had originally intended.
The trick here is that itâs not really a matter of just updating a library. The library that we ultimately use for filtering is HTMLPurifier, which is still updated and we update which version we use, but it doesnât include a lot of more modern/recent CSS. There are some one-offs, like a recent version of the library added support for aspect-ratio, but there isnât really a switch we can flip in the sense of updating that will radically alter whatâs supported.
Weâve started to move away from exactly what the upstream library provides, which improved the support in terms of which elements and pseudoelements are supported, but changes to the rules are a little more involved.
In terms of the specific things you mention and the way the plugin works now,
for content the main issue is that the CSS support in HTML Purifier doesnât support strings, so itâs possible to change styles on existing pseudoelements but not to create new ones
comments I believe are always stripped, itâs not a setting we can turn off
@import probably wonât be allowed. What we could do is something like what you see in those S screenshots, a separate input for loading external sheets, and weâd probably look to limit it to loading things like Google Fonts or Typekit stylesheets at least out of the box. That would bring in webfont support, and there arenât any significant barriers to us doing this one.
specific rules/styles, like transition, the library just doesnât have defined, weâd have to basically fork it to add definitions for those so they could be allowed.
Probably the more realistic route toward better CSS3+ coverage would be completely changing the library thatâs used to something else. Thatâs a possibility⌠Iâm looking into some alternatives and at least some look promising.
