More about IT >

Blocki Roadmap

Updated 29 May 2021

What is a blocki? See About this Blocki.


What software does a blocki need, and not need, to make it easy to set up and use? This one is built on nothing more than a web server, text editor, HTML and CSS, and consequently is clunky and limited for both author and reader. How to do better? Some incomplete thoughts follow.

There are three main classes of user: admin, creator and reader:

Approaches to solutions

Most of the basics are covered by standards-compliant web servers and browsers. HTTPS has become the standard access protocol for almost all remote content. HTML and CSS provide the remaining text functionality after a fashion (and SVG + MathML the diagramming and equations), but with some key shortfalls.

Javascript, cookies and so forth can be used to fill in the missing functionality but are inherently insecure and cautious users disable them. And of course those missing functions and features have to be coded in some way.

Most web site and content creation tools can be used for this, but getting rid of proprietary hooks, spyware, javascript and other anti-privacy features can be a nightmare. Then, building the features from scratch, even to the basic level of this demonstration blocki, is too difficult and time-consuming for most users.

One way forward is to improve the tools I already use, i.e. HTML and CSS, along the lines set out in my HTML 5 Sucks study. Even a local search facility could be implemented in my "Cascasding Simple Smarts" realignment of CSS, without the need to access anything outside the immediate sandbox of the blocki pages; think of it as an additional widget for web forms. A selection of navigation templates and CSS stylesheets would then be all that was needed for many a site creator.

Another way would be to create a blocki using a conventional web design and maintenance tool, and accept the insecurity and risk to privacy introduced by javascript. The tool could then be evolved to move more smarts back server-side, until javascript can be dropped entirely.

Of course, all this is bound to remain clunky for some users. The ideal would be to develop an easy markup language encompassing both HTML, CSS and the necessary smart functions, such as panscript, and code up a dedicated client-side blocki site designer and maintainer. Panscript will have a Turing-complete programming subset, so the client tool should be compiled from panscript source. Any active code present in the content it processes will be treated as passive content for display.

Any viable blocki standard must engage in three distinct work strands:

Data handling

Cookies can be useful in giving the user a consistent experience. But client-side cookies are in general no longer trustworthy and tend to get turned off. Cloud-held data swaps one set of risks for another. User preferences are best held server-side, where they can be managed securely alongside their login credentials. Client- and cloud-held repositories can then be offered as options via linking from the server-side preferences, for those users who prefer it that way.

This and other server-side smarts such as search indexing would end up associated with small databases. To what extent should these be maintained off-blocki by a suitable service, or brought into the blocki site space via flat-file csv and similar formats? In-blocki is attractive for its low service overheads and ease of assistive text-based editing.

Can a web server be relied on to block crawlers, bots and other spyware from areas containing sensitive private information in blocki space, or to implement them with an encrypted filesystem? The blocki owner probably has no control over all that, so the generic answer has to be "no". So all that would ideally be managed by dedicated blocki software. The alternative is to leave it up to the provider and caveat emptor - let the prospective user read the small print if they care.

Additional features

These are things that might be added server- or client-side. Ideally, server-side stuff would be backported to the web server, e.g. as an Apache module, rather than as a bespoke service such as Wordpress. Similarly, client-side features might be backported to the browser.

Indexing and searching. The server maintains searchable/clickable indexes of page content, images and media. When a page is uploaded, the server updates the indexes. The visitor can search or browse the indexes and click through. Would the search algorithm run server- or client-side? Might both be useful, depending on whether the user has opened the index for browsing or not? Client-side can use the browser's search, server-side would only be needed if the index is not opened first and so is not essential.

Site content lists and keywords. The server maintains a clickable list of all articles, sorted alphanumerically. Keywords added to the page by the author may be used to auto-build hierarchical listings by subject, perhaps also a tag cloud, etc.


This is just a notional roadmap towards a viable blocki solution. Almost certainly no more than one grumpy old git's fantasy.

v0.1 This is the baseline, basically just what I have here. Platform is any old web server, site written in HTML and CSS, accessible via HTTPS. Javascript and other active languages are not permitted. Cookies and other non-volatile (lasting beyond the current session) user information may not be recorded without the user's active, explicit and securely recorded consent (for example any default to assumed consent is strictly forbidden). To qualify as a blocki, navigation from any content page to any other must be provided (though not necessarily one-click) and all content pages should be datestamped for when they were last updated. Page indexes, Contents lists, etc. count as content for these purposes. Simple navigation boxes and page banners are not content; the use of iframes for such entities is strongly recommended. As CSS has developed, some improvements have pulled through to this blocki, so in this sense v0.1 is an evolving baseline.

v0.2 This adds a client-side blocki creation and maintenance tool. Its initial purpose is to remove HTML/CSS coding skills from the site desiger and content creator, and is therefore a basic but user-friendly web page editor with a targeted set of features. Later iterations would introduce a simple tag search, list/link html file builder and viewer/page selector display, allowing the creator to tag content and thus supplement or even generate the structured navigation. A tag list template allows the creation and editing of tag/link lists using other tools, including hand coding.

v0.3 Functionally unchanged from v0.2, but implemented in compiled panscript. This implies the development of a suitable compiler which is, in all but name, where the dream parts with sanity.

v1.0 Content creators may write in panscript, with much enhanced transclusion and navigation features. The creation tool automatically transcludes subsidiary content and converts the page to HTML+CSS, when uploading to the live site. Hand-coding of v0.1 pages is unaffected.

v2.0.x... Server-side desirable features standardised via RfC or similar and fed upstream to OSS web servers such as Apache, well-behaved menu features and selected ideas from HTML5 Sucks incorporated into CSS.