The Web Design Toolbox

Motivation

The primary motivation for creating this web design toolbox was to radically simplify web development – without heavyweight IDEs, website design tools, code generators, let alone content management systems (CMS), without toolchains, pre and post-processors, without server-side processing, templates, includes. With the least possible overhead for the developer. Creating a new web site should only require the creation of a project folder in the file system, a table-of-contents file, the instantiation (or copy & paste) of a page template, firing up a text editor and writing content in HTML. And viewing the results in a browser.

It should be possible for any person who knows only a handful of HTML tags, such as H1…H6 (headings), P (paragraphs), OL, UL (ordered and unordered lists), IMG (images), TABLE (tables (sic!)), and A (links), to write web pages and maintain the table of contents (i. e. the site map).

There should be no size limitation. From a single page to enterprise websites, from a one-man-team to large development teams working concurrently, everything should be possible – and manageable.

Processing should be done on the client side, wherever possible. Therefore a simple static web server is absolutely sufficient. No need for PHP, JSP, ASP and what not. This opens up a whole lot of hosting opportunities for the small budget, whithout sacrificing performance and throughput.

Last but not least, the results should be beautiful, and perfectly rendered on any device, TV sets, desktops, laptops, tablets, smartphones, or small devices with a display. Out of the box, with no coding for the screen size or orientation.

It is possible with a set of toolbox components that work silently behind the scenes to make the life of a web developer easier.

Goals

No special IDE or website design tool should be necessary. Any simple text or code editor should be sufficient. This includes the opportunity to work on pages with a text editor on mobile phones.
Effective use of the browser cache: Script files, CSS files, and HTML fragments tend to be small and static, and therefore are perfect candidates for caching in the browser.
No toolchain for preprocessing, text template expansion, minification and packaging should be required. An exception is TypeScript code, which must be compiled into JavaScript before it can be sent to browsers.
Elimination of redundancy: Identical copies of HTML and CSS code on every page (headers, footers, toolbars, navigation, etc.) make changes difficult and increase maintenance effort. Therefore redundant code is moved to re-usable toolbox components and loaded asynchronously.
Client-side processing wherever possible: Leveraging the power of client machines instead of putting the burden on the server greatly improves throughput. In fact, most websites can be served from static webservers.
Page preview from the file system: While authoring a web page, a preview can be rendered in the browser without the need for a web server. The author can focus on content without distraction.
Responsive layout out of the box.
Components adhere to the ES2016 JavaScript Modules standard.
No redefinition of CSS defaults: Stylesheets are designed to leverage the browser defaults wherever possible. CSS rules override defaults only if necessary. This keeps the code simple and easily customizable, without undesired side-effects.
Website partinioning: Partial table-of-contents files separate site navigation content and associated content into

Website Design Tools?

A beginner is faced with the following choice:

Lay down a bundle of bucks and buy a commercial (and usually heavyweight) website design tool, such as Microsoft FrontPage, Dreamweaver or similar,
Use a simple text editor and work directly with the core web technologies (HTML, CSS, JavaScript, SVG et cetera).

Figure 1 illustrates the situation:

Figure 1: Path decision

Considering the wealth of HTML tags and CSS attributes, the second path looks frightening. And JavaScript is a beast of its own. So it is obvious to take the first route and buy the necessary knowlege in a box. Or use a freeware design tool. But there are a number points to consider:

A website design tool presents an abstraction of the underlying core web technologies to the user, and it is not clear which parts of the base technologies are inaccessible through the tool.
A design tool can easily grow much more complex than the underlying base technologies.
A design tool must implement a simplified abstraction of the underlying core technologies, and thereby introduces limitations.
A design tool may implement a layout engine, but it is hard, if not impossible, to surpass the capabilities of modern browsers.
Many design tools decorate the generated HTML code with loads of metadata information which is not necessary for rendering in the browser. This makes the HTML code hard to read and understand.
A design tool never generates optimized code. In fact, the generated code is full of repeated code fragments, attributes, styles, et cetera.
A fool with a tool is still a fool.

The core web technologies imply a certain, well tested design philosophy, which has evolved over decades. Likewise, web browsers have evolved and converged towards a common standard. Knowing what's possible at the basis and what's not is key to successful design, and can be But if you are proficient with the core technologies, then what's the benefit of a design tool?

Learning Curves

Figure 1 illustrates typical learning curves for different development approaches:

Figure 1: Typical learning curves

Curve 1 represents a website design tool user. Early success with simple designs at the beginning is followed by an early knowledge saturation, caused by isolation of users from the core web technologies.

Curve 2 represents a designer on bare metal. There is some early success, but then follows a long path of learning before curve 1 is bypassed. However, knowledge saturation appears at a much higher level.

Curve 3 represents a developer with a web design toolbox. Very little base technology knowledge is required at the beginning. Ready-made toolbox components lift the heavy burden of learning a lot of details. Studying and tweaking existing components or creating entirely new components pave the path to core technology mastery. As a result, knowledge saturation appears much later at a much higher level.

Content Management Systems?

You might think about full-featured CMS. But, what does that mean: Manage? Multiple languages? That's a no brainer with language-specific subfolders. Access permission management, so that users can create and edit content? That's the domain of network administrators. Integrated editors running in the browser? There are plenty of free and commercial programming editors and IDEs that outperform in-browser editors easily. Skins? Well, we know how to switch to a different version of colors.css, or not? Markdown is easier than HTML? Well, that's debatable. But for sure, markdown lets us only access a small subset of HTML. And who likes it to be constrained?

Features

A standard web page may contain a header, a main toolbar, an uplink list bar, a footer, and a site navigation panel which is collapsed by default. The navigation panel contains the complete table-of-contents (aka site-map) in form of a tree structure. The tree nodes are collapsible, so that even a large web site can be efficiently displayed in a small screen area.

The path to the current document is highlighted, so the reader always knows where to find the current document.

Large pages can be structured with collapsible block elements, and they can be nested as required. Toolbar command buttons allow to expand and collapse the entire document, so the reader can quickly drill down from an overview to the desired document portion.

An asynchronously recursive document fragment loader component allows to re-use HTML fragements in many pages. This avoids a lot of maintenance effort, because a fragment exists only once, but shown in many places. HTML fragments can even be nested without limits.

An auto-number component can supply complex numbering schemes, similar to the HTML ordered list (OL) element, but more flexible. Interrupted ordered lists no longer require to adjust starting number updates if the list is modified.

Most components are a combination of a JavaScript module and a related CSS file. The CSS code is kept so simple that "skins" are not needed. Just change what you want, either hardcoded at design-time, or dynamically at runtime.

Web authors are not required to use a certain development tool (IDE). A simple text editor (even on mobile small devices) is sufficient.

A web server is not needed for authoring pages. A browser can be used to render the pages from the file system. However, there are some restrictions: JavaScript modules cannot be loaded over the file:// protocol, so only the pure but correctly formatted page content will show up in the browser. Which is quite nice for a content author, he or she can concentrate on the content. No distractions from toolbars, headers, et cetera.

To view the full functionality, a small web server is required. For example, the Deno file-server, the Node http-server or others are sufficient. No need for full-fledged tanks like IIS or Apache.

And finally, everything is client-side. What previously was done with server-side template engines, can now be done with the client-side fragment loader and standard HTML template elements. The web server can now be reduced to a high-performance static file server like NGINX with greatly improved throughput.

A data adapter is under development. It can be used to connect web pages to server-side data, bi-directional.

Components Overview

The toolbox provides a number of useful components. Some are mandatory, others optional.

Page Component

The page component determines the page layout structure, and provides the frame for content authoring. Additional components such as header, footer, toolbar and navigation panel are loaded automatically at run-time, so that repetitive HTML code is minimized and maintenance effort is reduced to the absolute minimum.

Part of the page component is a set of customizable page templates. A page template defines the visual document structure.

Header

The header component implements the top of the page, usually the website logo and name. A click on the header navigates the browser to the home page or opens the navigation panel.

Footer

The footer component implements the bottom of the page, and presents some document statistics such as author, modification date and document version. A script pulls this information out of the META elements in the HEAD of the document.

A second row provides standard links to the home page, legal information, the current section home, first, previous, next and last page in the section. Another script pulls this information out of the navigation component after site navigation content has been loaded.

Toolbar

The toolbar component provides buttons for site navigation and collapsible content control out of the box. Other buttons can be added site-wide or for individual pages if required.

Site Navigation

The navigation component loads the site map, a kind of table-of-contents for the entire web site. The information is organized in a tree structure with collapsible nodes, so that even very large websites can be presented neatly and organized.

Collapsible Blocks

The collapsible blocks control component automatically identifies block controllers (which exhibit the expand/collapse icons), decorates them and implements the control and transition logic. To make an HTML element a collapsible block controller, simply add a cbc. The component takes care of the rest.

Document Fragment Loader

The recursive document fragment loader, as the name suggests, loads document fragments at run-time. If an HTML document includes elements with a load-src attribute, the referenced resource is loaded and integrated into the fragment container element. The loader implementation works recursively, so a fragment may contain additional fragments. Infinite loop detection prevents loading of a parent container into a nested child container.

The loader provides a simple hook to run scripts to be run when the document and fragments loading is completed.

The loader is extensively used by other components, and can be used easily to load content "on demand".

List Numerator

The list numerator component extends the concept of OL start attributes to automatically enumerate named ordered lists. This component is useful if an ordered list is scattered into multiple partial lists, which would otherwise break the automatic enumeration of ordered lists provided by the browser layout engines.

SVG Element Generator

The SVG generator component creates an inline SVG element and integrates it into the document.

SVG images can be loaded from an external resource into IMG and OBJECT elements, but for privacy reasons, the SVG code cannot reference external resources, such as stylesheets. This prevents individual SVG drawing elements (for example the stroke color of toolbar buttons) to be styled uniformly by a site-wide CSS declaration.

This limitation does not apply to SVG elements that are directly embedded into the document. To simplifiy the task, the SVG element is automatically decorated with attributes. The individual SVG drawing elements (ellipses, lines, paths) are passed in as string and thereby can be loaded dynamically by the loader component, or defined statically as string constants in the JavaScript code.