With the 0.16 feature, I am up for an existential discussion about this…
(1)
Why shouldn’t the H1 title get actually written to the file?
The way the 0.16 feature appears to work, the filename is used only to display a H1 title by proxy, it is not written to the file. In other words, this is an Obsidian-specific feature.
But Obsidian promises “Notes for your grandchildren”. In the future, when my grandchildren pick up a bunch of Markdown files, or when I view them using an other application, why wouldn’t they or I want to see a H1 title at the top of the page? It’s like reading a news site article that doesn’t have a true headline - valuable context is lost.
Yes, I notice that the Filename Heading Sync plugin actually writes the title to the top of the file. And, yes, I guess people have the choice. I can just see people getting wrapped up without judicious use.
(2)
Semantics, accessibility and the risk of multiplication
There’s another thing I wanted to mention relating to this…
With this feature turned on, a H1 will appear at the top of a document, while the user may already have - or may choose to have - another H1 beneath.
This is semantically incorrect, at least in the web world, where each page should have only one H1, the title of the page. More specifically, each major element like <article> should have only one - an <article> would be analogous to a note, ie. the note file encapsulates a single entity. Therefore, the same rule should apply.
As this Markdown guide says: " f you target HTML output, write your documents so that it will have one and only one h1 element as the first thing in it that serves as the title of the document."
Obsidian/Kepano’s screenshot preview of the new default theme shows exactly this challenge, however - two apparent H1s… one real one, present in the file, and one fake H1, the title of the document.
As GitLab’s Markdown style guide says:
"We don’t use
h1headings, as they already are displayed on every page as its title, and we should not apply more than oneh1per page.… If you then use a second
<h1>on the same page, you’re creating some potential confusion…Always start with
h2…
Whether or not is is semantically appropriate or not (to a machine) to have two H1s, having two equivalent headers with equal weighting nevertheless has a visual consequence - this may confuse the user; it feels wrong.
(3)
Obsidian should be correct
This is of note because Obsidian’s own docs pages, for example, don’t use H1 headers at all. Instead, they style headers using CSS rules but then dive into H2s. Again, this isn’t quite correct. The end result, with a stepping-down in font weight, looks right, but it actually breaks web accessibility guidelines.
It also jumps from the non-H1 straight to H3 on occasion.
(4)
Impact
Appropriate use of these feature or plugins may matter to some users because appropriate balance of the feature use and in-note headers may render the Markdown semantically incorrect. This has particular consequences in publishing documents, but also has internal, private relevance.
For example - if a user declines to write in a H1 header, because the 0.16 feature makes one display in the window, they should then logically begin in-page sub-headers at H2. But, since the title isn’t getting written to the file, the first header in the page would then begin at H2.
As @GLight’s PDF export shows, it is entirely appropriate in that case to show the title of the document.
Is the product approach that it is up to the users?
(5)
Alternative naming conventions
I have been looking at Dendron’s hierarchical naming convention, wherein all nodes of the note’s hierarchy including itself are contained in the filename, leaving the human-readable title to be expressed in the file.
To prosecute that, I presume the best approach is to leave the feature off and just use names and H1s as I please.