Open TinyAtoms opened 2 years ago
Agreed, I find it useful for those information to be displayed in read mode :)
Would be great if you can also support inline mode of dataview:
date:: 144-43-49-00
date-end:: 144-43-49-00
The most likely tie here is reusing metadata from fantasy calendar, as that already has metadata parsing for dates in frontmatter, and can (with some limitations) read timeline dates.
As an option (keeping the spans or divs as you have them), you could consider something like this CSS snippet (I have this bound to a cssclass that I use the AutoClass plugin to enable):
.show-spans .ob-timelines {
display: inline !important;
font-style: italic;
}
.show-spans .ob-timelines::before {
content: "🔖 " attr(data-date) ": " attr(data-title) ". ";
color: var(--text-muted);
font-weight: 500;
}
I would really prefer to use YAML for all of the timeline data. To me, it's clearer and more manageable. A lot of my notes reference specific events or a range. I currently use dataview to access and organize these into an date ordered table, which is fine as it goes, but I would love to have the horizontal timeline.
I imagine that your code currently splits the data within the span and passes it to the timeline drawing function. Would it. be that hard to have it drawn this data from the YAML instead?
If people have a preference for vs. YAML, you could even have that as a setting and grab the data from the appropriate place.
I usually have multiple spans in a document, rather than just one. So while Yaml front-matter could work, it is constrained to one-per-note.
I am increasingly thinking this function should be combined with Fantasy Calendar, which already supports either timeline spans OR frontmatter dates/times..
If it used the Front Matter you could use Database Folder to manage, update and add to your timeline... which would be amazing.
If it used the Front Matter you could use Database Folder to manage, update and add to your timeline... which would be amazing.
you can do this with QuickAdd plugin. The advantage of having this data in html format, as @ebullient mentioned, is that you can add all your timeline entries in 1 file
A Summary
attribute would need to be added for the timeline description. Summary is a generic term that could be used in many applications, so the front matter would not be cluttered with timeline specific attributes. timeline-description
or others would be an ok alternative, but summary could be used in a bunch of other places.
If anybody is interested in this feature I've created a fork and implemented it. Usage docs are in the Readme, and build instructions are in the build.md. If spans or divs are included in the note, they will be used. Otherwise the timeline will default to gathering data from the frontmatter. This allows you to add all your timeline entries in 1 file with multiple spans if you want, or use frontmatter if you prefer.
@Darakah It would be great if we could get this Pull Request merged to the official release.
This is great, but I am not techy enough to know how to use this version instead of the standard one. Can you explain in a bit more detail? And @Darakah, I second implementing this in the main fork.
If anybody is interested in this feature I've created a fork and implemented it. Usage docs are in the Readme, and build instructions are in the build.md. If spans or divs are included in the note, they will be used. Otherwise the timeline will default to gathering data from the frontmatter. This allows you to add all your timeline entries in 1 file with multiple spans if you want, or use frontmatter if you prefer.
@Darakah It would be great if we could get this Pull Request merged to the official release.
@jwolfe99 I have updated the build.md file with more user friendly instructions. Otherwise you can simply download this obsidian-timelines-compiled.zip and copy the main.js
and styles.css
into the .obsidian\plugins\obsidian-timelines
folder in your vault.
@ebullient Totally would love to see this feature, can we get this PR approved?
This would allow you to do something like this:
, and it's up to the user's theme if they want to hide it or not, or prettify it in a certain way. Also, the advantage of not being hidden in editing mode. I don't really have a reason for wanting this, besides an aversion to placing html in markdown. Also, it then plays nicely together with things that work with yaml frontmatter, such as dataview.