Yes yes, sperate content and markup/style. But you can already do this with HTML? The only advantage I see is that you can actually support markdown like you do in your page, since it's less verbose than HTML-tags and doesn't make the text unreadable if you read it as plain text. But with HTML5 you can introduce arbitrary tag names to pretty much get the same with an XML-like structure instead of json. Just use and s…
a huge advantage is that you could begin webdesign anew without all the baggage from old html standards
Show HN: This website is valid JSON
221–230 of 240 posts
Re: Show HN: This website is valid JSON
#222Hello everyone, I created a simple script that allows a website to be a valid JSON and still be able to present the information on the browser. Any feedback is appreciated!
If you were writing a desktop application, you could be saving user data as this JSON-HTML quine (JHQ?), so it's automatically accessible on any device, but also still accessible to e.g. the jq utility.
Since any modification is liable to move the "_" field, you might address that by using an array envelope instead; [{"real": "data"}, ""]
For a production site, I think you ought to, server-side, check the Accept header and pre-render the conversion.
Another note: if I do Save Page As in Firefox, it saves the page as standard HTML, losing the JSON.
Re: Show HN: This website is valid JSON
#223Earlier quoted context omitted.
The page says: > I'm creating a blog platform using this concept. Yeah, please don’t; this is an abomination that’s fun for demonstrating and teaching how these things work, but should absolutely never be used in reality. You could use this as your data model foundation upon which to build a generator , but you should never under any circumstances actually serve this stuff.
> Yeah, please don’t; this is an abomination that’s fun for demonstrating and teaching how these things work, but should absolutely never be used in reality. Would you say the same about taking a browser -- which was designed to be a document viewer for researchers -- and turning it into an entire application execution platform like we have now? Point is: It's silly to say things like this, because this is how innova…
Re: Show HN: This website is valid JSON
#224As a blogging platform, please don't do this. It breaks all SEO, microformats, RSS feed discovery, rel=me ties, and much, much more.
HTML is great. Please use it for your websites.
source: runs a open-web friendly microblogging platform
Re: Show HN: This website is valid JSON
#225Earlier quoted context omitted.
This is just a bad idea. Apart from abusing browser rendering quirks (which is unfortunately a sad tradition of the web, something that has claimed the life of entire technology stacks like xml/xhtml), it removes any hope of producing webpages accessible from screen readers and similar. In comparison, JS-only pages look like model citizens. This is the equivalent of abusing IE hot-comments and other CSS-parsing bugs…
I disagree with this removing any hope of accessibility. If anything it brings hope for websites to be more accessible than ever before. Imagine a screen reader that instantly and flawlessly knows which content to read and how to navigate through it? If a consistent JSON format is adopted and used this would be a reality.
The web is pretty much best-in-class for accessibility matters. (There are a few isolated cases where native desktop or mobile apps can do better, mostly to do with efficiency.) HTML elements have defined semantics, so that things like headings and links are automatically navigable, and sections, headers, footers and navigation lists become waypoints. Then ARIA attributes can be used to provide any further metadata necessary, such as to mark up a tabs widget to show how to interact with it. And that’s still key—accessibility needs to care about interactions (which tab is open? and did the content available change?), so state matters. Thus, accessibility tools will never care about any format that you are projecting from, like this JSON; they must only care about what is materialised, which is the HTML DOM. (Besides all that, the only sort of “consistent JSON format” that you could have would be basically an encoding of the HTML, which would be verbose and subjectively ugly compared to the HTML serialisation, e.g. ["a", {"href": "/"}, ["Home"]] or {"tagName": "a", "href": "/", "children": ["Home"]} instead of Home, and miss the whole point here that the JSON is representing data rather than what the user sees.)
If you’re not familiar with accessibility stuff, I heartily recommend looking into it. If you can, find a blind person and see if you can watch them using a computer or phone. It’s really fascinating (I’ve never seen anyone be bored by it) and super useful if you ever contribute to making just about anything on a computer. Even people making documents in a word processor can learn things like “use actual headings rather than just making the text bigger and bold, because the semantics are useful”.
Re: Show HN: This website is valid JSON
#226Earlier quoted context omitted.
The page says: > I'm creating a blog platform using this concept. Yeah, please don’t; this is an abomination that’s fun for demonstrating and teaching how these things work, but should absolutely never be used in reality. You could use this as your data model foundation upon which to build a generator , but you should never under any circumstances actually serve this stuff.
> Yeah, please don’t; this is an abomination that’s fun for demonstrating and teaching how these things work, but should absolutely never be used in reality. Would you say the same about taking a browser -- which was designed to be a document viewer for researchers -- and turning it into an entire application execution platform like we have now? Point is: It's silly to say things like this, because this is how innova…
The only tenuous claim it can have is that the document is JSON, so if you want to parse the data, maybe you’ll find it easier? But in practice this is not useful: you can already embed or link to a JSON representation in the HTML, and that JSON representation then won’t be constrained by having to embed the renderer, either.
Not all inventions are useful.
Re: Show HN: This website is valid JSON
#227Re: Show HN: This website is valid JSON
#228You know, I once had a resume powered by JSON. It was rendered to a PDF (and HTML) but the syntax was backed by JSON. This was years back and I shudder to even recall the idea. I didn't create the project mind you, it was some NPM package back when I was a fresh 'un who didn't have thoughts on using a billion subdependencies Anyway, I was nearly broke and when I went to apply for the benefit, I was asked for my resum…
Probably https://jsonresume.org I have my resume defined using this schema, which is handy because it's supported enough that every few years when I actually need to update it, I can find a website (such as https://resumake.io ) where I can just copy in the JSON and get a nicely formatted PDF out of it.
Re: Show HN: This website is valid JSON
#229Earlier quoted context omitted.
> Apparently web standards folks in the early 2000s thought the future was XML all the way down. It should have been, but just like the masses rejected LISP for its parens, the masses rejected XML for the closing tag. We could have avoided PHP and the zoo of MVC frameworks.
If only XML wasn't so damn complicated , it might have had a chance. People love to point at close tags, but there's a long list of more serious problems. External entities, namespaces within namespaces, CDATA, namespaces that confusingly look exactly like URLs, but aren't, parser vulnerabilities.
Yes XML is more expensive to parse, but so is all the extra stuff you have to do to get around the various limitations of JSON, which could have been done cheaply by an optimized XML parser.
Re: Show HN: This website is valid JSON
#230You know, I once had a resume powered by JSON. It was rendered to a PDF (and HTML) but the syntax was backed by JSON. This was years back and I shudder to even recall the idea. I didn't create the project mind you, it was some NPM package back when I was a fresh 'un who didn't have thoughts on using a billion subdependencies Anyway, I was nearly broke and when I went to apply for the benefit, I was asked for my resum…
This seems more about putting barriers up to make it difficult for people to collect benefits. If you had this experience again, there would likely be some other barrier.