Hacker News Reader

Comment by lenkite | Hacker News Reader

We have semantic HTML, but for some weird reason we need to yet again re-express the semantic meaning of our website in bespoke weird JSON in a script tag that the browser won't process.

View on HN

Microdata is also a thing, and if I'm not mistaken supports the same vocabulary as JSON-LD (schema.org is a good resource).

That said, JSON-LD has the default for a while now, much like how we largely abandoned REST for RPC. I'm not actually sure if microdata is still supported by all the important parsers today, I've defaulted to using LD for any site I've built for clients, especially ecommerce sites where I want Google Search exposure.

Edit: its worth noting the comparison with semantic HTML. Semantic HTML helps define the structure of the markup but not real world context like "this is a product for sale" or "this is a train schedule."

HTML markup designed for presentation doesn't always map well to the relationships JSON-LD is used to describe which I imagine is probably why Microdata didn't work out. I have an idea which might use it, but it is a simple use case that doesn't try do too much. Microdata requires the agent supports a more complex HTML parser, Finding a script tag in the document head is probably simpler.

I wouldn't dismiss REST because of RCP though. HTTP and HTML's success probably relate to how Roy Fielding's REST constraints kept the HTTP protocol lean and extendable. It is more like RCP is being used as a layer over top of REST because of HTTP's and HTML's success as being good technologies for web scale.

Personally I'm of the camp that HTNL schema data should only represent what's visually displayed, much like how accessibility is usually done. In that way I like Microdata because it reinforces that if there isn't a DOM node showing price, for example, I shouldn't be showing that data in a visually hidden way.

For REST, I think the only reason HTML has been useful this long is because of the REST ideas that Fielding gave a name to. Today people just don't use it much, too many sites lean on client side rendering and fetching data from JSON RPC calls that we call REST.

I prefer REST, hell I wish we had proper XSLT 3.0 support for client side rendering logic without JavaScript.

I don't fully understand XSLT, but I've been building something which I believe solves a similar problem (albeit JSON-LD and Javascript). The general XML ecosystem of solutions have always looked really complex to me. You need to understand a lot more types/elements than I think is reasonable for people to author with but they are from before my time. I took a look at XForms 2 and it had its own way of defining functions which on top of the other XML quirks has security concerns.

Oh I can't say I like XML and XSLT for the syntax or (lack of) terseness. I appreciate how it handles templating via selectors, logical operations, and runs as a first party templating engine in the DOM without depending on the JS runtime.

I once built a full RSS reader in XSLT. I had to proxy requests to avoid CORs, but it was all based on an XSLT template for OPMLs that would fetch each feed, parse them, chuck the description into HTML including CData parsing, and combine all feeds to sort by date.

It was far from a perfect setup, partly due to browsers having been decades out of date with XSLT, but it gully leveraged browser caching for feeds. Caching in RSS readers is usually really bad from ignoring caching all together and polling frequently to misusing cache mechanisms and causing weird behavior for feed hosts. Letting a browser handle it to spec was great.

If you feel like it, tell me what you think of this. It is just surface level to what I'm working on. The starter project I'm making with it supports screen readers with rich webapp experiences and nojs w3m. But it is a fully Javascript SSR framework.

https://codeberg.org/occultist/octiron#readme

I have used JSON-LD in my own websites and found that it fills a separate need from semantic HTML. Your semantic HTML will specify things that the browser processes, like the title and headings. The JSON-LD data is metadata, like date created, date updated, tags, authorship. These things can be expressed in the HTML using micro data, but I stopped using micro data because JSON-LD was easier.

The JSON-LD I populate from the same data that I use to generate my site, and I use the JSON-LD metadata to generate things like index pages (list of blog posts from 2024, all posts related to topic X, etc). The main consumers of JSON-LD are search engines.

If you are interested in getting offended, then think about how we are also putting OpenGraph metadata in our web pages. Two different metadata formats for the same page.

Structured data exists yo pass the metadata. Issue with it is that of might impact the way your html needs to be structured, this can be messy.

Semantic HTML doesn't cover what JSON-LD and other microformats cover.

From the article alone: what are the semantic elements for a person? A breadcrumb list? A software application? A blog? A blog posting?

Semantic HTML is there to aid humans using screen readers to navigate through generic elements like "navigation" or "article".

What I see as the ideal would be a world where servers and browsers could do content negotitation, and have browsers attempting first to request only the json-ld from the website and using its own internal renderer format.

I don’t think you have understood the article enough. You can use Schema.org/FOAF/WikiData/etc. ontologies in HTML without JSON-LD and the script tags.

Reply on news.ycombinator.com