Use case: I would like to use different CSS formatting on each of the following:
Web article clippings in .webarchive format
Books in .epub format
My outliner reading notes in .bike HTML* format
Formatted notes
Currently, all these HTML-based file formats share a single CSS sheet configured in the settings, which does not reflect the different purposes each of these files serve.
Not to mention the annoying bug(?) that every time I open a EPUB or Formatted Note, the aforementioned CSS setting switches to a pre-defined CSS sheet included in the app bundle. After that it does not automatically revert back to the user’s CSS sheet when an Web Archive is opened — I have to manually select my own CSS in the settings pane every single time!
It would be great if we can use webarchive.css when viewing .webarchive files, formatted-notes.css for Formatted Notes, outliner.css for .bike and so on. Ideally, we can have a global theme that applies to all HTML-based formats and multiple “snippets” catering to specific file extensions. (Inspired by Obsidian snippets)
While it’s possible to embed CSS styling in individual files with a style tag, in my opinion it’s inferior to the suggestion above due to a lack of flexibility — who wants to make changes to a thousand files just to use a different CSS sheet? Being able to adjust everything in a unified Settings pane feels much better.
Web archives are meant to capture the state of an HTML document at a certain time. Therefore, they should contain the CSS (and other external stuff needed to display the page as it was). What is the point in defining your own CSS over the one from the original HTML document? And which CSS should have precedence? The main argument for using a web archive is to preserve appearance – having your own CSS would possibly alter that appearance.
According to the Bike site, they use HTML or OPML. XML is neither “HTML-based” nor stylable with CSS (unless it’s a special variant of XML that uses HTML elements).
Why is that desirable? I can imagine that one would want the different files to look similar, but what is the benefit of having different styles for each of them?
When I clip web articles, I download them as Markdown, then convert to Web Archive as the format in which I do my actual reading. The extra step (converting to .webarchive) takes advantage of DEVONthink’s built-in multi-color highlight feature, which is not available for Markdown documents. Web Archive is also a neat way to store locally all the visuals in an article; no separate Group is needed for this purpose.
Just think of my Web Archives as a Markdown alternative, with no intention to preserve the original web page layout.
I use my own CSS for all of my clipped articles. Conflicting CSS is not an issue here because my Web Archives, being converted from Markdown, contains no CSS at all. The reason not to embed my own CSS inside individual articles is flexibility.
Ah, my mistake. Thanks for the correction!
The main reason: I’d like to have visual cues for what I should be doing. Among them:
Serif font for reading and sans-serif font for note-taking;
Colorful headings and bold text in notes, but not in reading;
Different presentation of bullet lists in outliner notes and reading material;
…
Essentially, different files serve me different purposes, so they certainly, in my opinion, should have different styles. Another reason I use Web Archive for reading, instead of Markdown, is to visually distinguish articles from my Markdown notes.
I understand there are different views on customization, but simply having more options — snippets, for example — hardly hurts anyone, right?
A side-note suggestion: If a custom CSS sheet has already been selected in Settings > Web > Style Sheet, web clippings in clutter-free Web Archive format should not contain style tags which, if present, would take precedence over the user’s CSS.
I understand your point (though I don’t share the feeling )
Given the plethora of apps and file extensions out there – yes, having options to provide CSS for each one might hurt some people. Users, because they might be confronted with a visually overwhelming interface or with the fact that the option for their preferred format is missing.
Support people might be hurt because of the added complexity: Which CSS has precedence over which one (default vs. inline vs. global vs. linked stylesheet)? “Why do the list elements in this document look different from the list elements in that document?” This kind of thing.
What I’d suggest instead of adding a bunch of CSS options to the global preferences (and missing out on others):
Create the CSS files for your format, store them in DT or the file system (the latter, if you want to use your HTML files in a browser, too)
Create a smart rule (or several ones, depending on your workflow) that is triggered by “On import” and/or “After conversion”
Create a small script that adds a <link type="stylesheet" src="…"> at the appropriate place in the document (e.g. just before the </head> tag) and add it to the smart rule.
This approach is a lot more flexible than looking at file extensions: html, for example, is pretty generic and doesn’t say anything about the producer. It might come from Bike or from Motorcycle, one wouldn’t know by looking at the extension. OTOH, looking inside the file (which the script could do), might be more enlightening. Also, having the document refer to the CSS directly makes it easier to move to other platforms (kind of, you have to move the stylesheet, too – but at least you do not have to add the reference to the CSS to it).
Other people might disagree if they want their clipping to look like the original.
And what about link elements (it’s not tag, btw, unless it is something in pointy brackets – you don’t want to remove the tags, but the complete element including its content)? What about style attributes? Or styles set with JavaScript? Don’t lift the lid on that Pandora’s box.
DEVONthink actually does have a reasonably good solution at this: hidden preferences.
Which dedicated CSS people would balk at the prospect of demonstrating entry-level JSON ({".extension1": "1.css", ".extension2", "2.css"}) in Terminal?
Each approach has its own limitations. Scripts does not work well on EPUB files. And there are possibly other HTML-based formats that you cannot easily insert tags into. An approach based on file extensions does not cover all scenarios either — none does — but it is relatively easy in terms of implementation.
AFAIK clutter-free Web Archives are created by the Markdownifier service, thus does not care much (if any) about retaining the original layout.
I was indeed talking about removing the entire style element — what’s the point of higher-priority in situ styling when you already have a global styling intended to supersede everything else? Even if this indeed is the case, your aforementioned scripts should come in handy
)