Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: This website is valid JSON

webdatarender.com

Post reply on HN
Print view View original

211–220 of 240 posts

Re: Show HN: This website is valid JSON

#211

Post by chrismorgan »

zeven7 wrote: post #200
cubic wrote: post #188

Earlier quoted context omitted.

The primary reason for calling it an abomination is that if they actually plan on having this used (especially if by other people) it will spectacularly break the moment Chrome decides to make their quirks mode more strict. It's a fun hack, although not exactly very unique. See also the very old by now "Website in a PNG file" concept, which does the exact same thing: https://gist.github.com/gasman/2560551

This will never break. I still think it's a bad idea, but not for that reason. Browser vendors are strongly against ever making backwards incompatible changes - especially a change like this that would likely affect thousands of websites. Chrome is not going to suddenly make their HTML rendering engine more strict.

Yeah, it’s certainly not fragile in that way. The quirks mode thing is actually one of my lesser concerns about it.

Re: Show HN: This website is valid JSON

#212

Post by bzbarsky »

bogidon wrote: post #44

For those like me who needed a little help... I do not fully understand the browser rendering process (someone who does please chime in), but what I gather about how this is works is: - the content-type of the page is "text/html", so the browser is trying to render html - there is no special meaning of the #render key to the browser (again the browser doesn't know this is json) - browsers are very fault tolerant so t…

You first two bullet points are correct.

For the third one, there's no "skipping over" involved. The and opening tags are optional in HTML. The browser sees some non-whitespace text (the opening '{') not in the context of any other tag, auto-opens those tags, and the text starts being parsed as body text.

If the page loaded slowly enough, over multiple packets that arrived separated in time, you would see the JSON text coming in and rendering as text, with all the curlies and all, until the browser gets to the part of the JSON. At that point, some common-error fixup dating back to the Netscape/IE 3 days kicks in: when you see an or tag and one has already been opened (due to some stray content at the beginning of the file, likely), you don't open a new one, but copy the attributes to the existing one. This copies the "hidden" attribute to the , which hides it. After that either the script executes and does its work, per your fourth bullet point, or script is disabled and the style rule inside unhides the element, but at that point you will of course just see the JSON text, parsed as HTML.

> I do however get this warning in FireFox so perhaps this is pretty fragile:

I'm not sure whether the site changed since then, but now it's sending `charset=utf-8` in the content-type header, so there's no meta prescan at all. Which is what allows the emoji after "Need Help?" to be decoded correctly.

Were you seeing the meta prescan warning on your local test file, or on the site itself?

> I'm guessing differently-configured means not in quirks mode?

No, it means things like preferences about how to handle pages without encoding declarations via various heuristics (e.g. scanning byte value frequencies and guessing what character encoding is in use based on that).

Quirks mode is determined solely by the doctype of the page. This page has no doctype (since it starts with a '{'), so it's always in quirks mode. And what quirks mode does is enable a set of behaviors designed to not break content written more or less in the "before HTML 4.0" era. https://quirks.spec.whatwg.org/ should have a more or less exhaustive list of quirks mode behaviors browsers are expected to implement. Some of these are extra-fault-tolerance (e.g. the hashless hex color and unitless length quirks), while some are just replicating pre-CSS browser rendering behavior (like the line height calculation quirk, which a bunch of sliced-image stuff relies/relied on).

Re: Show HN: This website is valid JSON

#213

Post by chrismorgan »

Spivak wrote: post #201
chrismorgan wrote: post #150

Earlier quoted context omitted.

Quirks mode is not the only problem of this approach. It may not significantly affect users of modern browsers in their default configuration with good internet connections, but it does affect plenty of other things. You want to parse things in the document? Now you need a whole different suite of tools from the usual tools you use. Your library that parses all the meta tags, identifies the content, &c. is now useles…

> You want to parse things in the document? Now you need a whole different suite of tools from the usual tools you use. Your library that parses all the meta tags, identifies the content, &c. is now useless. They're no less useless than for SPA's that render their content in JS. That's all this site is. If your web scraping suite can't handle content loaded from JS then you're already locked out of most of the web. S…

For just general web pages (as distinct from apps), it’s not common to actually require JavaScript. I know this because I’ve JavaScript disabled by default for the last two or three years, and it’s really not all that much of a bother.

The key thing here is that SPAs normally get some kind of interactivity benefits from being written in that style (though I confess they break things that the platform provides, by reimplementing them badly, at least as often), such as loading same-site links faster. But this thing doesn’t do that; it’s purely a projection, like XSLT. It should be done as part of a generator or server, rather than on the client side.

Re: Show HN: This website is valid JSON

#214

Post by bzbarsky »

aidos wrote: post #181
lifthrasiir wrote: post #126

Earlier quoted context omitted.

Moreover this is not even a "plain JSON". While I don't think the OP doesn't make this exact claim, an arbitrary JSON with the `#render` bootstrap won't necessarily work because the JSON can contain valid HTML tags... Interesting as it stands, utterly useless in practice.

Can’t you put the render at the top and the script can block before anything else to make sure a) it always executes and b) removes all the json content from the page. Or actually, you can probably just put some closing angles before the start of your render to make sure you don’t get broken from above. Little sketchy though.

If the script were at the top, it would run before any of the rest of the JSON gets inserted into the DOM, so it would (1) not have access to it (unless it sets up an async callback to do it) and (2) not be able to remove it from the DOM (until that callback runs).

The script might be able to set up mutation observers that notice stuff being added to the DOM and immediately remove it into a buffer the script maintains. This might actually be pretty viable.

> Or actually, you can probably just put some closing angles before the start of your render to make sure you don’t get broken from above.

That won't help with the fact that the data will actually be "corrupted" by the HTML parser. This is why all the HTML inside the JSON in the example is HTML-encoded.

One plausible fix for _that_ is to have a tag right after your . So put the #render as the first thing in the JSON, set up mutation observers in the script, to prevent HTML-parsing of the rest of the doc, and this might be pretty robust to random HTML bits in the JSON data.

Re: Show HN: This website is valid JSON

#215

Post by LockAndLol »

sillysaurusx wrote: post #176
chrismorgan wrote: post #121

Earlier 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.

This is such a depressing comment. It's the opposite of the hacker spirit. The web has made it easier than ever to discourage people from trying anything new. New ideas seem like bad ideas, because otherwise people would be doing them. One could imagine your objection applying to React: "What a horrible idea. It's a nice hack, but under no circumstances should you actually build webpages like this. Webpages are built…

I agree with you. People should just explore the possibilities that exist to the fullest, harmless extent. There's no harm in this. Along the way, they might find something entirely new. Blocking off that path with "don't ever do this" is just closed-minded.

It's a good thing people exist that aren't deterred by gatekeeping comments like these and actually try to innovate or simply play around and have fun with programming.

Re: Show HN: This website is valid JSON

#216

Post by botch_san »

greggman3 wrote: post #63
bogidon wrote: post #44

For those like me who needed a little help... I do not fully understand the browser rendering process (someone who does please chime in), but what I gather about how this is works is: - the content-type of the page is "text/html", so the browser is trying to render html - there is no special meaning of the #render key to the browser (again the browser doesn't know this is json) - browsers are very fault tolerant so t…

You are correct. It's a silly hack. Just because it happens to work doesn't make it a good idea. Turn off JavaScript and you just get JSON text.

> Turn off JavaScript and you just get JSON text.

I have JS disabled by default. Until I read your comment I was just confused what was going on.

Re: Show HN: This website is valid JSON

#217

Post by TheKarateKid »

chrismorgan wrote: post #121
greggman3 wrote: post #63

Earlier quoted context omitted.

You are correct. It's a silly hack. Just because it happens to work doesn't make it a good idea. Turn off JavaScript and you just get JSON text.

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 innovation happens.

Re: Show HN: This website is valid JSON

#218

Post by lifthrasiir »

bzbarsky wrote: post #214
aidos wrote: post #181

Earlier quoted context omitted.

Can’t you put the render at the top and the script can block before anything else to make sure a) it always executes and b) removes all the json content from the page. Or actually, you can probably just put some closing angles before the start of your render to make sure you don’t get broken from above. Little sketchy though.

If the script were at the top, it would run before any of the rest of the JSON gets inserted into the DOM, so it would (1) not have access to it (unless it sets up an async callback to do it) and (2) not be able to remove it from the DOM (until that callback runs). The script might be able to set up mutation observers that notice stuff being added to the DOM and immediately remove it into a buffer the script maintain…

> One plausible fix for _that_ is to have a tag right after your .

That seems more plausible since `` can't be closed. In fact mutation observers can be used to get and process the partially downloaded JSON before onload (I'm pretty sure this is possible but haven't tested, YMMV). That would be still horrible as a general solution, but might be actually an interesting solution for more limited situations.

Re: Show HN: This website is valid JSON

#219

Post by TimTheTinker »

toyg wrote: post #189
sillysaurusx wrote: post #176

Earlier quoted context omitted.

This is such a depressing comment. It's the opposite of the hacker spirit. The web has made it easier than ever to discourage people from trying anything new. New ideas seem like bad ideas, because otherwise people would be doing them. One could imagine your objection applying to React: "What a horrible idea. It's a nice hack, but under no circumstances should you actually build webpages like this. Webpages are built…

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…

Hacking is mostly playing around and using things in ways the designer didn't imagine at the time.

This is a good hack. It brings a smile to the face and warms the heart (if a good hack is what you were looking for). And I think that was the point anyway, not to come up with a professional architectural pattern.

Re: Show HN: This website is valid JSON

#220

Post by 93po »

toyg wrote: post #189
sillysaurusx wrote: post #176

Earlier quoted context omitted.

This is such a depressing comment. It's the opposite of the hacker spirit. The web has made it easier than ever to discourage people from trying anything new. New ideas seem like bad ideas, because otherwise people would be doing them. One could imagine your objection applying to React: "What a horrible idea. It's a nice hack, but under no circumstances should you actually build webpages like this. Webpages are built…

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.
Post reply on HN