DT maims file URL for CSS in global Markdown preferences

DT should (I think) accept a correct file URL in its global preferences for a style sheet. However, if I enter
“file://…/…/css/a/styles.css” (without the quotes, of course)
in the text field and close/reopen preferences again, the field contains
“/../css/a/styles.css”
which of course does not give the desired results. file://../../ is a valid file URL relative to the base URL of the HTML file. OTOH, /.. is an absolute file reference (not even an URL anymore, BTW).
Converting an MD file to HTML than gives me this:
<link type="text/css" rel="stylesheet" href="file:///../css/a/styles.css"/>
which again is an absolute URL and not what I want nor what I said. Moreover, there’s (in my opinion) no reason to first remove the file protocol from the URL in the preferences to only then add it again in the link element.

Suggestion: Leave the URL as it is and simply use it as the href value in the link element.

Rationale: Using a file URL makes it possible to convert the MD file to HTML in DT and then preview the HTML in a browser with the same CSS as in DT. That’s not possible with an x-devonthink-item URL.

Where is the CSS file actually located?

In the same database as the MD. The approach works if I add a link element with the same URL as I entered in the preferences.

Maybe the coffee hasn’t kicked in yet, but why would you be adding a file:// URL as a default stylesheet in the Markdown preferences?

In tried to explain that in the Rationale of the post before. Item URLs for CSS don’t work with the browser.

Gotcha.

Only absolute URLs (including item links) and absolute paths are supported. Especially as the paths used by DEVONthink can easily change.

Does that mean that if I save a CSS file somewhere in a DT database, DT might move it to another location in the file system (ie another path) later on?

Personally, I wouldn’t care about that – a lot less than I care about a program changing my URL without any apparent reason. file: is a valid protocol, and a relative path is also valid. Modifying that behind the user’s back does not help – they don’t achieve what otherwise would work, and they don’t even get notified about the modification.

Also, if I pass in a http/https: URL, DT is (hopefully) not altering. Although remote URLs are also subject to change.

I’d suppose that people using URLs (local or remote ones) are sufficiently knowledgeable to fix problems resulting from a change on the other end of the URL.

Not without performing any actions currently (like renaming, editing etc.).

Then I don’t see the point of not passing the relative file: URL unmodified to the HTML file. This would, as I tried to explain before, make it possible to display converted MD files in a local browser with a user-defined stylesheet.

One alternative, using an item link, does not work with the browser. The other, using a non-file URL, requires a web server running. OTOH, a relative file URL requires nothing at all.

And why isn’t an absolute URL or path an option?

Technically, it works. But with a relative path, one could use per database styles, which would be more flexible than a single, absolute path.

Bug: An absolute path (without file: protocol) in the global settings works ok. A relative path (../../css...) without file: protocol is copied into the HTML without the first parent directory, so incorrectly (and then the stylesheet is not loaded). Also, the path is not there anymore when one opens the preference dialog again.

See above, only absolute ones are currently supported. A future release might change this depending on interest.

:pray: