DT and DTTG include their own CSS when rendering Markdown or converting it to a formatted note. I would like to suggest some modifications to that, as well as a general change in the way CSS is handled if a user-defined style sheet is set in the preferences.
The DTTG style sheet sets the font-size for the body element to 8pt. This is bad style, as it overrides the font size the user may have set in their browser (or perhaps the DT/DTTG preferences). Leave it to the user to decide their default font size, don’t force them to zoom just to be able to read the text.
Having a:hover in a style sheet is (IMHO) questionable: hover doesn’t work the same way on mobile as on the desktop.
Setting the font-family for the code and pre elements to “courier” is also intrusive: The user might want to use a different monospaced font. The default font-family: monospace should be just fine in the CSS.
Rules for table data, row and header use too high a specificity: table td, table tr and table th are not wrong (by no means), but td, tr, th would suffice. And those selectors would make it a lot easier to override them in a user-defined stylesheet. As it stands, the user has to specify table td etc., too. Given that td, tr and th mustn’t occur outside a table element, it seems natural to only those selectors.
I understand that rendered MD should look nice (in whatever sense). OTOH, it shouldn’t force arbitrary things on the user and override their preferences (as with font-size and font-family).
And there’s a general problem with user-defined style sheets, as DTTG (and perhaps DT?) make it hard for them to override “built-in” (i.e. injected by DTTG/DT) CSS.
One example: The DTTG stylesheet specifies a border-left for blockquote elements. In a well-written user style sheet, one would perform a CSS reset at the top including something like * { border: none }
to remove all borders from all elements.
However, this does not remove the border-left from blockquote elements, since * has a lower specificity than blockquote. The user would have to add blockquote {border:none} to their stylesheet, thus repeating themselves and making the CSS reset partially useless.
Another problem is the definition of different background colors for alternating table rows – looks nice, but is a PITA to override in a user style sheet.
I’d suggest not including any styles in the rendered MD when a user-defined style sheet exists. That makes it easier to provide a complete, well-written CSS without having to deal with side-effects because of specificty, order of inclusion etc.
At the very least, the DTTG/DT stylesheets should always use selectors with the lowest possible specificity so that overriding these rules is easy.
This is a terrific post. It answers some of the questions I have had with setting / resetting CSS in my DT markdown notes.
Here’s hoping this leads to a more robust, and more flexible, implementation of markdown within DT. (I would particularly appreciate the ability to choose a style sheet to use: styles for viewing, printing, writing can be different. DT’s “you get one” seems a little limited when faced with Typora’s “whatever you want.”
I’m not crazy about markdown, but it has two advantages over rich text: smaller file sizes (which become less important as the years go by) but also semantic styles. It pains me, pains me, that the styles in rich text are only named for the convenience of the user and are not embedded in the document itself such that if I change the style it cascades throughout the document.
Sorry for being a bit sloppy there. While my essential point remains that it would be nice to choose different styles, what I could have used as examples is that, in my case, there are styles for presentation (e.g., lecture or talk notes), styles for reading and/or sharing, and sometimes a different style for drafting. (All of these could be either on screen or printing, so media distinctions don’t work here.) Being able to toggle between those, because style sheets, would be really useful. Right now I have this functionality by pairing DT with Typora when I’m on my Mac, which is a mostly workable workaround for me.
I get that. I won’t pretend to understand various implementations, DT’s versus Typora’s for example, and the complexities involved, so I would settle for togglable styles within the Preview mode for now.
But we can preview while editing, and some people might want a different CSS for that preview. For example, I use a fancy CSS for my notes for reading, and might use a simpler one for editing. But this means the interface would need to know the difference between the double pane “Write and Preview” view vs. the single pane and that might not be possible.
Why? Is the CSS so “fancy” that it hinders editing?
Having this kind of switch looks like a sure way to generate questions here in the line of “Why does my document suddenly look different?”
Aside: “Fancy” makes me (!) think of the times when HTML elements could blink. Or of sites using ten different fonts because they can. You may have other, sane things in mind, of course.
I support the initial posting of @chrillek - @cgrunenberg is this anything that would be feasible to change in the future? For telling the truth, I am no markdown expert and the standard stylesheets overriling my own css stylesheets as described in detail by @chrillek was very confusing for me. But I can accept if there are good reasons to keep it as it is now.
I generally use the two-pane view only with markdown, which allows both editing and reading simultaneously. For editing, I turn my eyes to the left pane, which is simple plain text (with WYSIWYG disabled). For reading, there is the right pane with CSS customization.
I save my reading materials (mostly web clippings) in HTML format, so they can, by default, have a different CSS from that for my markdown notes.
Indeed, this makes it a little bit tricky, as the same user-defined customized ccs stylesheet looks different on DTTG due to be “overruled” by the standard css stylesheet of DTTG (for more details see initial posting of @chrillek) Would be great if also on DTTG either the internal or the one defined in DTTG markdown settings is used. Or is there any reason for handling it differently on DTTG?
I am thrilled. It is truly a pleasure to be a DTP and DTTG user. I have never experienced such exceptional support (thanks to @BLUEFROG). Also the direct contact to @cgrunenberg and @eboehnisch here in the forum, in addition to helpful information and assistance of other users as @chrillek, and the regular updates to improve the software step-by-step are truly impressive.
