Craft & Artfulness

This is a small series on HTML forms. The previous post was Forms as state containers Part 2: managing complex data . A form is a schema Since HTML5 there are a lot more attributes avaiblable on form components for expressing constraints. This means forms can nowadays be used as a basic schema for validating data. However, HTML5 form components are a motley crew, so we need some guiding principle to actually make sense of it all. JSON Schema  provides a coherent set of constraints for JSON data. And because JSON is just javascript, JSON Schema should be readily applicable to HTML forms as well. You may not know or like JSON Schema, or you may not want to learn it because it isn't a standard (yet), so in this post I'll try to patch up things by merging JSON Schema into the HTML forms standard. To start it off, some very useful keywords from JSON Schema actually translate directly to HTML5 form constraints. For this purpose I'm considering the version 0.4 draft. ...

This is a short rant that was originally part of my HTML forms write-up , but that I took out, because it became too long. I haven't been writing unobtrusive javascript for at least a decade, and perhaps that was a mistake, but it was also inevitable. In my own defense: it seems HTML is actually quite incoherent... Yup, I just wrote that. I mean, you have tags that denote text levels, similar to those used in text processing software, like paragraph , header , blockquote and (later on) the HTML5 semantic tag set . You also have tags that denote some concrete representational blocks that can be considered part of the document flow, like img  and table , or more generic tags that can be used to manipulate document flow, like div or span . The hyperlink is the VIP of the web, and a different beast altogether. Then there's the  form,  with its controls, which isn't representational at all, but primarily  functional . I think the distinction between representa...

This is a small series on HTML forms. The previous post was Forms as state containers Part 1: forms as a single source of truth JSON? The value of a form can be seen as a key/value map, a plain object in JSON. From this follows that the value of a subform naturally becomes an object in the parent form. In HTML5 subforms can be expressed as a fieldset  element. However, the javascript interface of a fieldset is not a natural fit as a subform, since it only groups elements in the parent form: the elements remain accessible in the parent form. Wrapping the fieldset interface slightly in a thin javascript layer, we can treat fieldsets as a true subform, and we can address its "value" property as an object. In the unlikely event that the form doesn't have access to javascript, we may have have another solution, as we'll see later on. Repeating values obviously fit naturally to javascript arrays. The "value" property of, for example, a multi-select gets (or ...

Please read the introduction  if you haven't already. Everything is a form HTML forms are an age-old standard, and by no means replaceable. I've created a form builder on Dojo Toolkit  some years ago, and for all its javascript fanciness, it was driven by the idea that forms can and should be the only means for users to interact with the web. Want to create a fancy slider, a large editable grid, or a even simple (yet interactive) list? Be sure to wrap it in a form element! Why? Because form components manage their own state internally. As soon as your component exposes anything else then a simple "value" property to allow interaction with javascript, you're going to leak state into parts of the application that don't have anything to do with it, making things literally hell to maintain. Dojo Toolkit was the first large javascript frameworks for building widgets AKA web components (known as Dijits), and had some flaws in the state department, mainly becau...

When wiring up a web application there's a lot of state involved. Only recently I learned about state management libraries in javascript, but I won't be talking about them. I think I don't need to introduce them, because I'm convinced you don't need them. Let's take a step back to see what state actually means in web apps. Traditionally, the web is stateless, and that's a good thing. When you request a page, the server may store information about your request, for instance for analytical purposes, but it doesn't need to do so. As the HTML document is received, nothing special is stored about that document, except maybe some temporary information (like cookies) is written to disk, if you'll allow it. Every time you request the same page, it's rendered the same way and, ignoring the subject of caching, no state is retained. The HTTP protocol is stateless by design. Therefore, traditional HTML forms are stateless too. Whenever user data is submi...

One of the challenges in javascript remains that there's no convenient way to traverse JSON. Subsetting or modifying complex hierarchies usually requires some sort of custom recursive strategy, which always leads to heavy mental exercise and many errors. Since JSON has pushed XML out of the web stack, there's still some XML legacy to be dealt with. So why not scour the pile of remaining junk for some nifty scrap parts to reuse? Let's travel back to Tatooine... XPath seems to have had an important role in traversing the DOM, the abstract Document Object Model resulting from interpreting XML documents. It certainly had some useful features that CSS, for instance, lacks, like traversing back up a tree. Unfortunately, the W3C recommendation of XPath is not suitable for JSON. You might argue that the W3C deemed XPath unfit for JSON, but perhaps it was never given a fair chance. There has been an initiative to create an XPath-like DSL for JSON called JSONPath , but it has pr...

In 2012 Mark Nottingham wrote a blog post entitled " JSON or XML: Just Decide ". It arguments that instead of trying to support both formats, web APIs should simply just use JSON. His advice seems to have been followed widely, as there are very few XML APIs left nowadays. However... XQuery is a language that was originally developed as a DSL to query and transform XML documents. Since JSON has pushed XML aside as a data format on the web, the authors sought to support other data structures as well: JSON-like arrays and maps. This was realized in XQuery version 3.1, and a recommendation candidate was published in 2015. I know what you're thinking: too bad, too late, and against MNot's advice. This would indeed be my TL;DR, but just let me elaborate a bit more... Together with XPath and XSLT, XQuery is a powerful tool to handle semi-structured data-"documents" based on the InfoSet datamodel . However, maps and arrays (JavaScripts' native data structu...