0045 CSS in Annotations #625
Conversation
Initial commit to version control ⚡️
Initial commit to version control ⚡️
Incidental to current recipe, but it needs fixing
Discussed in cookbook authors call of 29 July 2025
Recipe use case is now along the lines of thinking about multiple annotation authors, and the CSS rules now align with that. Colors made into hex rather than words for precision.
|
@triplingual I've added basic support for this in Theseus: I think it would be worth recommending implementations use CORS for the stylesheet if they want to improve its chances of working in generic viewers (in order to potentially sanitise or extract the styles). |
|
Thank you for the implementation. That's a good idea about CORS. |
1. Changed a lot of text to address editor comment about confusing implementation notes. It was a good comment, and these changes prune significant superfluous text around the other ways of using CSS in a manifest. 2. Moved text pointing to other recipes from Example to Implementation Notes to sub for the previous unnecessary discussion of other CSS use methods. 3. Changed highlighting in targets to only highlight the styleClass, since the recipe is about CSS, not targets. 4. Moved from Implementation Notes to Restrictions the pointer to HTML in Annotations for the discussion of markup limitations. Also added to that pointer text the reason it matters.
| tags: [style] | ||
| summary: "Using an external CSS stylesheet in an annotation body, annotations can be styled in limited ways" | ||
| viewers: | ||
| - Theseus |
There was a problem hiding this comment.
I think this should be:
- id: Theseus
support: partial
As it doesn't support the target styling.
There was a problem hiding this comment.
The target styling is supported now on Theseus, but there is a CORS issue when loading the style.css file at the moment. https://theseusviewer.org/?iiif-content=https%3A%2F%2Fpreview.iiif.io%2Fcookbook%2F0045-css%2Frecipe%2F0045-css%2Fmanifest.json
There was a problem hiding this comment.
The notions of full or partial support are a little weird for this recipe. Since it now includes significant cautions to manifest publishers around uncertainty of CSS in viewers, support would seem to me to be "permitting some degree of styling using an external stylesheet." On the one hand, we can't insist that allowing all CSS is the only definition of full support*, but on the other we don't define what CSS should be supported they way we do with HTML. I'm inclined to invent a definition of full support for this recipe that is less about what you can do with CSS in a particular viewer and more about whether the viewer has help documentation about what CSS is permitted and forbidden in the viewer.
* Not that anyone is insisting that; saying this to draw one boundary.
Setting a bg color for the highlight obscured the image underneath. CSS is clunky because I'm not using multiple classes per note/highlight. It's not clear whether that's even possible, and in any case it would make the manifest less readable to use the cascade and have more compact CSS
glenrobson
added
the
meta: ready-to-merge
Closes #45