Sounds interesting problem. You want to use different date settings among different apps?
Nope, it’s kind of the other way around 
…
I use something close to ISO date/time format in my YAML but Obsidian, without any intervention from me, was parsing those in Properties in another format (either EU (DD/MM/YYYY ) or US (MM/DD/YYYY), I don’t remember exactly)… anything but YYYY-MM-DD when I actually tried to change the type from text (as this is how I wrote them in the YAML before Properties came to life) into a date or time …
All I could do to display my ISO formatted dates/times from the YAML into ISO dates/times in Properties was to change the Language & Region settings on my device, as a whole (which was a “solution”/workaround I found on Discord) so Properties would actually pick up that format… and I never had to go that road before …
But this makes no sense to me knowing MomentJS is already implemented in Obsidian.
My device is not set in English (for personal reasons) and I am not in the US but I use Obsidian in English (in Obsidian’s settings) and I honestly think that I shouldn’t need to modify device settings just to display a date/time value in a specific way 
4 Likes
I thought your problem was much more important 
Ahahah 
!
Fortunately no, it isn’t ! Knowing Obsidian would work on YAML at some point, I tried my best to anticipate what could be coming (so far, nothing really broke in my vaults… except how I need to modify some YAML by going into Source mode) 
.
But the changes made with Properties come with some UX frictions (which is perfectly normal) which can be refined
True, but they could also go the other way around. Create a good visual html, callout and table-editor for live-preview with which it wouldn’t be necessary to handle the text directly anymore.
The fourth editing mode: Full WYSIWYG mode - Feature archive - Obsidian Forum
You can take a look at this discarded post where I explained the difference between the two.
And I also discovered something interesting:
1 Like
Thanks a lot for this one! 
Of course I like the markdown-way of the live preview, but having ckeditor as a „fourth“ way or third editor for obsidian would be especially nice to have for beginners and those who simply don’t want to wrestle with markdown sometimes but having the possibility to switch is the benefit in comparison to MS Word.
So where is the ckeditor-plugin? 
And of course the question remains unanswered: why did they go the „GUI-way“ in live-preview for properties? This is not consistent and should be changed in the next release.
It’s not that I completely dislike the way I can edit yaml, there should just be a overly-button that switches the current yaml-GUI-only-editor to its usual markdown-text-editor like it is for everything else in live-preview.
I haven’t had a chance to try 1.4 yet, but it seems there are two features being requested:
- Live Preview support for Properties, probably something like Callouts, they have a dedicated “Edit” button that basically switches callout block to source view. And there’s an option of navigating inside a callout via arrow keys which achieves the same thing.
- Option to always show plain YAML in Live Preview, which sounds reasonable since that’s how things work in 1.3, always switching to Source View is hardly ideal for people who prefer always dealing with plain YAML but would still like to use Live Preview.
In that post, I was specifically talking about markdown. Markdown can be written by the average users without UI assistance. That is not true for YAML. It’s easy to mess up the syntax (which is strict), especially when many different properties are involved.
Initially, the frontmatter was indented to be used and managed by plugins only. What happened in reality what that users started using the frontmatter section, often in a non yaml compliant matter. So here we are today, we have decided to provide assistance to those users.
I moved that thread to feature requests, because maybe we will have a full blown WYSWYG markdown-hiding editor in the future. Who knows!
This is not the road that we decided to take. We went with an interactive UI (not like callouts where you just have button to switch between rendered/editing view)
In one of the future releases, disabling the properties plugin will also remove the property UI from the editor (and show the regular YAML) See this post.
5 Likes
Good to have options. Will Obsidian still rewrite the YAML if it thinks it needs to, or will disabling the properties plugin mean that a user’s YAML will no longer be revised by Obsidian?
3 Likes
The rewriting of the YAML section isn’t a new thing. It has been happening since we introduced the API (used by plugins) to read and write YAML.
You are just noticing it now because you indirectly interact with that API (and the underling parsing library) every time you use the properties UI.
“Rewrites” can happen any time that API is involved (of which I can’t foresee all future and third party use cases) and again we are fine as long as what is written is semantically the same to what you manually input.
4 Likes
Appreciate the insight and help.
This sounds ok. Most of the users of Obsidian probably wish to maintain the original appearance of their notes and are not very willing to have them modified by others. I hope Obsidian can continue to uphold its initial slogan, “For you forever.”
4 Likes
Might there be a way to use a CSS snippet to override the UI mode in Live Preview and force the editor to show the raw YAML as it appears pre-1.4?
Additionally, would a CSS snippet be able to increase the line density of the UI mode?
As WhiteNoise stated: “Initially, the frontmatter was indented to be used and managed by plugins only. What happened in reality what that users started using the frontmatter section, often in a non yaml compliant matter. So here we are today, we have decided to provide assistance to those users.”.
Obsidian upholds the stance It's your data and does not modify anything, except for complying with formatting rules – be it Markdown, YAML etc. – not to break the application’s functionality. I applaud that.
If you decide to install plugins that use and maybe even change the YAML data to give you the experience you want to have, it is your decision.
1 Like
Arrays are also a valid format for frontmatter, just like this: tags: [foo,bar,baz]. It’s not necessary to strictly adhere to the list format, and using a list format might affect your ability to perform global changes in VSCode.
3 Likes
I am confident that they will enhance the experience regarding the possible formatting within the rules at a later stage.
I’m glad to note that the “properties” is provided in the form of a plugin, and the property UI can be disabled without being imposed on all users. In fact, UI operations are so inefficient that they might attract some users, but those who were initially drawn to Obsidian might not appreciate this redundant mode of operation.
3 Likes
The Properties enhancement is, in my personal opinion, a big step away from the plain-text ethos that drove Obsidian initially, and I would welcome the option to just turn it off and use the pre-1.4.x YAML method.
7 Likes
Yes, please, for this feature request.
I prefer editing my notes, including YAML, using Live Preview. The property editor isn’t doing it for me, and slows down my workflow. Same goes for switching back and forward between Live Preview and Source modes just to edit the metadata as plain text for my notes.
Please bring back the option to edit YAML directly (as plain text) in Live Preview without using the property editor UI.
3 Likes