doc.mashweb.club – DOM

Zen-White-Paper: Zen vs. website builders

Thu, 05 Jan 2017 00:00:00 +0000

It is important to characterize and visualize how Zen will be different from “website builders” and WCMSs like Wix.com and Weebly.com. In contrast to such WCMSs, which prescribe construction methods at the level of business type, templates, plugins, modules, fonts, etc., Zen will give the user ultimate control of detail at the element/node/NodeList level of web pages. Zen will allow a DOM node to be grabbed and “dragged” to different positions in its containing NodeList because this is the simplest metaphor for that operation. Drag-and-drop is a classic feature of direct-manipulation interfaces (DMIs) and this metaphor of “moving” an HTML element or node is so compelling that we have to look at the code to see that the element has not moved in terms of x and y coordianates, but rather in terms of its cardinal position in a NodeList. Zen will allow a DOM node to be “cut and pasted” to any valid position in the DOM—an interaction between multiple NodeLists. An HTML element’s style has four possible, well-supported values for its display property: block, inline, inline-block, and none. Live demo code to implement GUIs to rearrange element positions in the NodeLists of the first three of these display styles is located on the author’s GitHub Pages here, here, and here. (Right-click on the links to open the pages in new tabs or windows.) The method of sliding elements in these prototype GUIs was partly inspired by the 15 Puzzle and JavaScript-based implementations of the 15 Puzzle. There are notes about some of these implementations on this website. Below is a screen recording of Jamie Wong’s AI-based automated 15-Puzzle solver, which is written solely in JavaScript, HTML, and CSS (Figure 13).

Figure 13. Jamie Wong's 15-Puzzle solver.

Presently, the customization of templates, plugins, and modules for website builders and web CMSs and the creation of novel comment systems, forums, wikis, and presently unimagined communication systems are far outside the bounds of casual web authorship.

Zen-White-Paper: Concessions to usability

Thu, 05 Jan 2017 00:00:00 +0000

Some concessions to manipulability are necessary so that Zen can successfully edit all webpages. When HTML elements are grabbed Zen should temporarily apply suitable styles to HTML elements like high-contrast borders to make them visible during element selection. When the display-style property of an HTML element is none, Zen should make it possible for users to temporarily set it to another value so the element can be seen. Likewise, wherever desired, Zen should employ similar tactics to make all elements visible and manipulable, whether they are too small; too big; too transparent; or animated. Zen should employ intuitive, adaptive, custom cursors with contrast and distinctive patterns that show up with whatever colors are behind them. The animations in Figures 14 and 15 are actual screen recordings of rough-prototype GUIs for rearranging NodeLists that contain just blocks or just inlines, respectively.

Figure 14. Block-manipulator prototype. Click to open the live demo in a new window.

Figure 15. Inline-manipulator prototype. Click to open the live demo in a new window.

Zen-White-Paper: Principles

Wed, 04 Jan 2017 00:00:00 +0000

As pointed out by David Ungar (who pioneered the type of prototypal object system that JavaScript uses), from values derive principles and from principles derive practices.³⁵ ^,³⁶ We have just explored the values behind the Zen system. Now let’s examine the principles of the Zen system. Zen will complement the approach of Lively Kernel,³⁷ ^,³⁸ which shares Zen’s principles 1–3 as listed below. How much, if any, of Lively Kernel’s code it will borrow is yet to be determined. Note, in particular, the following principle 11 of Zen that is different than the principles of Lively Kernel:

It will run in any browser without a download or installation. (Sometime in the future, an attempt might be made to make it work in mobile browsers.)
It will be a composition environment, a GUI builder.
It will store its apps as web pages.
It will compose web pages using the DOM’s interfaces and APIs³⁹ ^,⁴⁰ but not SVG or Canvas drawing operations.
Zen will allow its composition objects and simple programs to be inspected and edited via a Squeak-like object inspector.⁴¹ Zen will, by default, hide its visual programming environment. When visual programming is enabled, Zen will use HTML elements like DIV to model nodes in the program’s abstract syntax tree (AST).⁴² Zen will enable these program nodes or blocks to be copied, pasted, and rearranged, just like the ordinarily visible parts of a Zen web page.
It will enable its users to easily compose sequential programs, that is, programs that can wait for external, asynchronous events such as user input or I/O. Zen will synchronize its user’s sequential programs through Scheme continuations in an interpreter running on top of JavaScript in the web browser. (See below.)
Zen will be loadable into any web page as a library, although caution will be required to ensure compatibility.
It will complement, augment, and interact with existing web page editors and website builders, not replace them.
It will allow the Zen-editing of a web page to be locked, leaving intact the form and behavior it built inside the web page.
Zen will not add more than 1–3 seconds to a web page’s TTI (time to interact).
Zen will not follow Lively Kernel’s principle of implementing a scene graph.³⁷ Instead, it will leverage the CSS2 visual formatting model⁴³ and CSS3 features implemented by A-grade web browsers⁴⁴ to model a document in a web browser.