Even if this feature request happens (and there are no plans for it at the moment), we will keep rewriting your YAML while managing properties.
We are now taking a more active role in the management of metadata and as long as what we reparse is semantically the same as what you wrote, it’s not a bug.
My main issue with not being able to access the YAML from LP is that I can’t update some of the values using Templater templates like I did before without having to go through the source mode 
… (which I haven’t used since LP was realeased)
This adds an unnecessary step in the management of YAML/Properties.
And I couldn’t find a way to simplify the process … (But I also admit that I just began to search for a potential solution, if one exists 
)
So, generally speaking, in its current state, Properties seems to now kind of defy the purpose of LP, IMHO .
This is something we are gonna work on
Awesome 
!!!
Thank you so very much in advance 
!
That is not just unfortunate but frustrating framing. This isn’t even a feature request IMO. It’s merely asking that something that already exists keep working and something we didn’t want, need, or ask for not be forced. Saying “just use source mode then” is a pretty frustrating response.
To my knowledge, this is the first time Obsidian has treated documents or a part of documents like it “owns” that area and not the user owning that area. I don’t want Obsidian forcing certain things in my front-matter. Users should be able to opt out and not be forced here. Not a good turn. I’m rolling back to 1.3.x and staying there as long as I can.
I agree with this FR. While I love properties, I think Obsidian should stick to its core value of being highly opinionated – giving maximum control to users over how they want to work with their files. I understand that having properties means Obsidian needs to decide how it will format different values (although I would love to see options here), but I don’t think the users who like working on YAML directly or who want their front matter formatted a particular way should have friction added to their systems.
I have to agree with pmbauer and oldjove. Why is Properties the one plugin that I cannot turn off?
I have a working system using YAML in Obsidian using plain text, but even with the Properties plugin turned off, the new visual is the new standard view in Live Preview and forces the text to conform to a specific syntax like new line breaks added by Obsidian even when I view in source view, lists of tags instead as array, and other changes when I toggle between views when I edit them.
At least additional settings should be available to have more granular control over how Obsidian handles this.
Thank you for mentioning this !
I was thinking about making a FR to have “Properties user’s settings”, specifically regarding how MomentJS could be leveraged for dates/times (to avoid having to change my device settings just to display those datas in a certain way) as this is to me, a second big issue of Properties: how it handle dates/times 
.
(But that’s a bit off-topic)
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 
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:
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:
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.
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?
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.
Appreciate the insight and help.
