Prettifying Org Mode with CSS
sandyuraz.com
sandyuraz.com
It is also possible to tweak the Org mode export mechanism to modify its structural markup to fit projects such as Tufte CSS[2][3].
What the article doesn't explicitly mention is that #+HTML_HEAD: is an instance of In-buffer setting[4]. These can be either added to individual files, or more conveniently, to a reusable _Setup file_ many files could point to (specified by the #+SETUPFILE: in-buffer setting).
1. https://lepisma.xyz/2017/10/28/ricing-org-mode/
2. https://github.com/dakrone/ox-tufte
But really I think that if this is all you want to change with org-mode HTML output, it must export pretty decent HTML. (I’m not familiar with it.)
(Analysis of the things I particularly don’t like: 1.6 is too large a line-height; I prefer #000 to #444, though I’d settle for #222; image should use max-width instead of width, and have height: auto added, and what’s with the 700px instead of 900px, especially if you’re not going to block and centre it?; border-radius on images seems a bad idea; I dislike gratuitous fiddling with ::selection colours—only touch it if you have actual brand colours that you’re making it align with, like https://wesbos.com/, and be cautious even in that, as is demonstrated in the .highlight on that page which thwarts selection styling.)
I like that the outline is represented in the dom as nested elements instead of a flat representation. Title, status, tags, properties, description, code and code output are well separated and easy to select through path, I’d and/or class.
Something I enjoy is the "narrow to sub tree" feature that allows to export a nice html rendered export from a part of the document.
Grey on white has less contrast than black on white which reduces readability - I doubt it can ever increase readability. It's basic human physiology - probably basic physics.
So an open question to all those who describe themselves as UI/UX experts - why do you do this?
EDIT: I can't tell actually if there's differences in color between the headings and body text in this case. If not... shrug
[1] : https://uxmovement.com/content/why-you-should-never-use-pure...
And if I use an OLED screen in a completely dark setting, your "not really black" is annoying too: there is more light coming to my eyes, and your website will be harder to read because of the lower contrast. Way more strain on my eyes, clearly. You work against me. Don't choose for me, you don't know my setting and how my eyes work. Fortunately, Dark Reader and Dark Background and Light text both do a good job of setting the right colors to webpages and are customizable.
An extension working the same way to undo these arbitrary choices and to set the desired level of gray for a light background and a dark text would be nice.
Setting the level of gray should not be the designer's choice, because each user is different in this respect. If someone is annoyed by a too big contrast, their screen is probably too bright and they can set it.
If you as a designer try to solve this problem for me as a visitor, you are preventing me from solving this problem in the best possible way, once and for all, for every sites I visit. Please don't mess up with my contrast. I know some people don't know how to configure their display or even that this is a problem and bad display settings are what cause them headaches, but you won't this fix for them, and even may make the problem worse for some of them.
Smaller contrasts are not compliant to the Web accessibility guidelines for a reason.
Good thing that I have screens with sharp contrasts and good eyes though.
Am I missing something?
A darker background, on the other hand, can be helpful in some situations.
I can't know for sure, but it's pretty likely your experience and your observations aren't quite aligned. If the contrast is too low (such that you notice), it can certainly cause more strain. But it's often the case that almost-black registers as black (and almost-white as white) and you don't even realize that's what you're seeing.
In my case, anything above #333 is capable of producing problems, the range #333 to approx. #444 is problematic with thinner font weights and anything above #444 is easily, noticeably terrible with anything except heading weights.
/* Originally from http://bettermotherfuckingwebsite.com */
@import url('https://fonts.googleapis.com/css?family=Inconsolata|Inter&display=swap');
body {
margin: 40px auto;
max-width: 900px;
line-height: 1.6;
font-size: 16px;
color: #444;
padding: 0 10px;
font-family: 'Inter', sans-serif;;
}
h1,
h2,
h3 {
line-height: 1.2;
font-family: 'Inter', sans-serif;;
}
img {
width: 750px;
border-radius: 10px;
}
pre {
font-family: 'Inconsolata', monospace;
}
::selection {
color: white;
background: #ff4081;
}Adding interactivity on the other hand is more involved. I recommend org-info-js which is what I use with my journals. https://orgmode.org/manual/JavaScript-support.html
One could easily copy those styles, extend them or host it themselves. Why the vitriol?
or just use the bare CSS as a starting point to make your own (everyone has their own style)
Really surprised by this. I would have thought there would be at least a small and thriving community of people that want to use org-mode, but with vscode. What gives?
Does org mode generally support the kind of infinite nesting Dynalist does? Mostly seeing documents with it and the vscode plugin not even coloring after level 5 anymore indicates to me "no".
I can't speak for the VS Code plugin, but I'm not aware any limits on depth in Emacs. I can't say I often go more than four deep. If you mean zooming (the killer feature of Dynalist IMO) it's possible in Emacs. You can turn the current subtree into its own org file.
> You can turn the current subtree into its own org file.
As in "you can not just zoom in within a file"? That'd be super annoying when wanting to focus on one thing quickly.
Regarding being burned by free plans: I don't know how it works for them economically, but in general they seem like incredibly generous and wonderful people. Full export in a plain text format and OPML are one click in the app/CURL request with the right cookies to dynalist.io/backup away. They're quite responsive and nice on Twitter. When the service was down for a few hours pretty exactly a year ago (that means no sync, but the desktop app still works with local data) they gave everyone 2 weeks of premium as an apology (the main benefits are inline pictures and a sideways tree view, so it's not that appealing).
Maybe they'll make me pay at some point and I think it's worth about 5€ per month to me, beyond that it'd get me uncomfortable considering how polished, but fundamentally simple the service is. If there was such a plan I'd actually get it just to support them, since the service is quite amazing.
Long-term I'd like to have a FOSS app that can do more complex graphs than just trees, with different views and such (imagine a relational-type list of things that you can categorize by different attributes), but Dynalist is by far the best thing I have seen so far.
I fear Org mode just quite doesn't fit my use case, as I think it also doesn't save whether a node is collapsed or not.
What does Dior mean ?
I usually use bootstrap css when I have to publish: https://github.com/marsmining/ox-twbs
- https://orgmode.org/ - Org mode is for keeping notes, maintaining TODO lists, planning projects, and authoring documents with a fast and effective plain-text system.
- The main style element here is the max-width setting. The original bare HTML of the 1990s was mostly read in 640 by 480 pixel 14 or 15" CRT screens, with the most fortunate using workstations with megapixel 19" screens. Document width at maximum window size was fine then.
¯\_(ツ)_/¯
Do you have a good method for this?
Feel free to dig through the source if you want to see how it works: https://github.com/sulami/sulami.github.io