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
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.
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.
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.
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.