71–80 of 240 posts
I wonder is it possible to do this without running any javascript, only HTML5/CSS?
Earlier quoted context omitted.
Definitely your tooling is better incarnation of the idea, XSLT is kind of an abomination
I love XSLT in theory. It had the daring to say that the most frequently programmed thing that we do is just translate data structures of one shape into data structures of a slightly different shape, and it said “That is what I shall focus on, doing just that.” And the way that it produced that, by “just start writing your output document and insert XSLT when you finally need to loop or query the input” seemed quite…
Even Go, which is really not amenable to any sort of in-language DSL or syntactic sugar, is nicer to use than XSLT itself.
XSLT locks you in a trunk without enough tools to do what you need. I remember using a variant of XSLT Microsoft put out back in the day that let you embed Javascript into it... but then I noticed, why not just do it in Javascript? So I did. And it was soooo much better.
There are good ideas in XSLT, but they are so buried in a cascade of bad decisions and limitations and restictions and missing functionality and bizarre ways of doing things (and I mean, I speak Haskell, pure FP doesn't scare me, and they're still bizarre) that the best remedy is just to start over.
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…
I don't see this error on FF. Are you seeing this on the console? I put the meta tag to render some special characters without relying on the server, but HTTP header would be a better option (Content-Type: text/html; charset=utf-8). And you nailed the process.
The json.org description of an "object" is: > An object is an unordered set of name/value pairs. But this site seems to be assuming that the key/value pairs are parsed in their original ordering for everything to display properly. Is it safe to assume JavaScript will always parse the keys in order?
Technically, no. Functionally, probably yes.
Any browser vendor that decides to muck with the current status quo would likely break enough code to be a non-starter.
I'm confused about: > The JSON must contain only pure information without any concern about design or markup. All the design and markup required to render the page must be inside the rendering script. The source code has markup in the form of Markdown, e.g. ## or * text
Yes, this is a good catch. The reason for this is the basic render that I created is generic, and it is not what you should do to render your JSON. The render should fit perfectly with the JSON. The basic render is just for a quick start. For example, the basic render "# Title" creates an h1 header, but if you created the render, you know the internal schema of the JSON, so you can use the correct HTML element for th…
Since there is no standard for representing rich text in JSON, if you want rich text, this is simply an unavoidable problem. At least Markdown is semi-standard and people can get libraries for it. Embedded HTML would also work. Defining an ad-hoc rich text embedded would be worse.
Earlier quoted context omitted.
I created this tool with a very odd necessity: I hate animations and overlay ;). I would like to have access to the website data directly and build my own interface, but for this, I would have to have access to the information only. I know that the website could expose an API, but WDR feels much more natural and easy (try to do a `fetch` on the page and get the JSON instantly). Now that I have built and have played a…
This makes a lot of sense and I agree with this need! I want to throw in a healthy dose of skepticism about whether your solution can address that need -- only because I hope that hearing it early can increase your chances of success! I think a hard problem ahead would be how to convince other people to also adopt this framework, and how to make sure that people are using the same JSON keys to mean the same thing. I'…
At first, I was thinking to use some kind of general schema, but those things never work. So I decided something much simpler: the render determines the schema. This is an important aspect that I am working on. If you choose some specific render, your JSON will have a specific shape. For example, if the render is for a landing page, the JSON could be something like "about", "products", "team", etc. (never , , etc...). But it is too soon to tell I'm still thinking about it.
(but an interesting corollary is that the render could be also a program with the "config" part. It would be an alternative to website builders. Every render would be a different WB tailored for the website)
> I'm curious how you plan to prevent your JSON format from being (ab)used for presentation purposes, where people add extra content to make the page display a certain way. And if you have a plan, is this plan feasible using HTML as well?
I don't have a plan for that yet, and it will be difficult because we are accustomed to mixing data+markup. But I think the mindset is to stop thinking the website for just the browser. The website could be information first, presentation later.
It's a neat trick using the Browser's Quirks Mode to load JSON that can bootstrap a framework, I'm not sure I really understand the benefit though. In order to actually get to the point of bootstrapping, the server has already transferred all of the content, plus the bootstrapping Javascript in a single payload. It seems like this implementation has the weaknesses of using a Javascript framework, without the benefits…
The idea is to separate the data in JSON completely to be consumed outside the browser if needed, but still render correctly in the browser. The traditional javascript framework only solves the latter. I tried to solve the quirks mode, but it is kind of hilarious that the browser needs the odd to flip to standard mode. There are ways to inform the doctype on the headers or XHTML, but this would complicate a simple so…
I'll accept that answer. As controversial as this comment may be, XML/XSLT is a very good fit for this purpose. It might not be particularly modern, however it's almost universally supported.
I love this! You could use this to syndicate blog posts, sort of like RSS, except each entry is JSON and could be viewed as it's own page rendered by it's own renderer (carried by a CDN and cached by the browser), or by the renderer of the users choice.
Submit
There might be a clever way to get it to submit dynamic JSON that changes based on user input without JavaScript, but I haven't thought enough about it.
This technique is sometimes useful for CSRF attacks.
Earlier quoted context omitted.
I don't see this error on FF. Are you seeing this on the console? I put the meta tag to render some special characters without relying on the server, but HTTP header would be a better option (Content-Type: text/html; charset=utf-8). And you nailed the process.
Hey! Yes, however now I notice that this is only when running locally. I took your page, replaced script and css with absolute links, and loaded locally as file://
Also, if you are interested, the project is on GitHub: https://github.com/webdatarender