Using JSON-LD to have page metadata over inline attributes, I'm not so sure.

Kristof Zerbe has an educational post on JSON-LD. It's a compatible specification of page metadata as a JSON object. His example is:

1<article class="article-type-post h-entry" 
2        data-pagefind-body="" data-pagefind-meta="type:Article" itemscope itemprop="blogPost">
3  <h1 class="article-title p-name" 
4      itemprop="name">Title of my latest blog post</h1>
5  <p> ... </p>


 2  "@type": "Article",
 3  "@id": "",
 4  "mainEntityOfPage": {
 5    "@id": ""
 6  },
 7  "headline": "Provide Blog Metadata via JSON-LD",
 8  "datePublished": "2023-02-02T12:00:00+00:00",
 9  "dateModified": "2023-02-02T12:00:00+00:00",
10  "image": {
11    "@id": ""
12  },
13  "author": {
14    "@id": ""
15  },
16  "publisher": {
17    "@id": ""
18  }

Initially I like this more cleaner and direct representation. But I was reminded of something a UI friend1 told me many years ago - invisible metadata rots. Having the content of the article in two places? The author? The title being in yet another place? It's easier for them to be out of sync via a missed update or similar because you don't see that data when you view the page by just viewing the rendered page.

This is why I like the h-attr approach - adding meaningful attributes to the tags in the document to markup content that's already there. I also don't think this makes maintaining the information much harder, when things are automated or not. If the title changes - I just change the title in the <h2>...</h2> tags and refresh the page. If I see the new title, it's worked. And the metadata is updated at the same time, and visible in the same way.

My feel is the extra effort in making a machine-friendly, concise object for processing hides the data, makes things easier to get out of sync, and makes things a smidge bigger.