Background; I use Tiddlywiki to organize all of my background notes. (I would love to be able to import the document directly, but that is a wish for another time…
I’m trying to create links in Scrivener docs to Tiddlers, so the link is of the form file:///path/to/file.html#wikiArticleName - if I enter this URL in the browser (Chrome) manually, it brings up the document with just wikiArticleName showing. When I click the link from inside Scrivener, the #wikiArticleName anchor is ignored.
I don’t think “file:///something.html#anchor” is actually a valid link. It naturally works when you are the page itself in the browser, because then the browser is handling the page scroll action directly rather than reloading from the disk, but anything coming from outside of the browser is going to be asking the OS to handle the file name you’ve clicked on, and “#” isn’t a valid character in a filename.
The # sign is a legal character in a URL, although as you mention, it is actually up to the browser to handle it correctly; it’s a display-only attribute and a server will normally ignore the # sign and everything after it.
Right, there is no debate there. But a file path URI is not the same thing as a Web URL. I don’t know if an anchor request can be sent to a file via a URI, especially given that not all file types will know what an anchor is. I wouldn’t expect “?parameters=toWork&either=inFiles”.
As you say, the server will ignore it. There is no server in this case.
I hear what you’re saying, but entering the URL from my original post on the URL line of the browser will bring up the correct page. The browser and the Javascript in the web page interpret #xyz to display the correct items.
The bug I am reporting is simply that Scrivener ignores the #xyz when spawning the browser as an external viewer. The #xyz is still contained within Scrivener but not passed to the browser. I would expect the program to store a valid URL and send it off as-is and not interpret whether or not it will be “valid” to a given browser, as long as the string is valid as a URL. AFAIK # anchors are valid whether the access protocol is file:// or anything else. If that’s not true, than I have learned something new for the day.
I haven’t tried the experiment using an http:// URL or any other protocol, or with CGI parameters as in you “?” example. I will do that the next time I have a chance.
Okay, I found a case where it works. If I make a hyperlink in Onenote to an HTML file, using the file:// protocol with a #anchor, it will load in a browser to the correct spot. So I’ll flag this in our system to see if it is something we can do.
