WIP
s-ol
3 years ago
| 210 | 210 | key |
| 211 | 211 | |
| 212 | 212 | @inspect_err = ReactiveVar! |
| 213 | @editor = ReactiveVar! | |
| 213 | 214 | |
| 214 | 215 | with div class: 'view inspector' |
| 215 | 216 | -- nav |
| 216 | 217 | \append nav { |
| 217 | 218 | span 'inspector' |
| 219 | ||
| 220 | button 'close', onclick: (_, e) -> @inspect\set false | |
| 221 | } | |
| 222 | ||
| 223 | \append div { | |
| 224 | class: 'subnav' | |
| 225 | ||
| 226 | ondrop: -> | |
| 227 | print "dropped" | |
| 228 | ||
| 229 | onpaste: -> | |
| 230 | print "pasted" | |
| 218 | 231 | |
| 219 | 232 | @inspect_prop\map (current) -> |
| 220 | 233 | current = current and current\tostring! |
| 245 | 258 | @inspect_prop\set Key facet |
| 246 | 259 | @refresh! |
| 247 | 260 | |
| 248 | button 'close', onclick: (_, e) -> @inspect\set false | |
| 261 | div style: flex: '1' | |
| 262 | ||
| 263 | @editor\map (e) -> e and e.saveBtn | |
| 249 | 264 | } |
| 250 | 265 | |
| 251 | 266 | -- error / content |
| 254 | 269 | \append @inspect_err |
| 255 | 270 | \append with pre class: 'content' |
| 256 | 271 | \append keep @inspect_prop\map (prop, old) -> |
| 257 | @get_content prop, @inspect_err, (prop) => | |
| 258 | value, key = @get prop | |
| 272 | @get_content prop, @inspect_err, (fileder, prop) -> | |
| 273 | value, key = fileder\get prop | |
| 259 | 274 | assert key, "couldn't @get #{prop}" |
| 260 | 275 | |
| 261 | 276 | conversions = get_conversions 'mmm/dom', key.type, get_casts! |
| 262 | 277 | assert conversions, "cannot cast '#{key.type}'" |
| 263 | apply_conversions conversions, value, @, prop | |
| 278 | with res = apply_conversions conversions, value, fileder, prop | |
| 279 | @editor\set if res.EDITOR then res | |
| 264 | 280 | |
| 265 | 281 | -- children |
| 266 | 282 | \append nav { |
| 125 | 125 | -- * value - value |
| 126 | 126 | -- * ... - other transform parameters (fileder, key) |
| 127 | 127 | -- returns converted value |
| 128 | err_and_trace = (msg) -> debug.traceback msg, 2 | |
| 128 | err_and_trace = (msg) -> debug.traceback msg, 1 | |
| 129 | 129 | apply_conversions = (conversions, value, ...) -> |
| 130 | 130 | for i=#conversions,1,-1 |
| 131 | 131 | step = conversions[i] |
| 8 | 8 | for k,v in pairs(tbl) |
| 9 | 9 | obj[k] = v |
| 10 | 10 | |
| 11 | EDITOR: true | |
| 12 | ||
| 11 | 13 | new: (value, mode, @fileder, @key) => |
| 12 | @node = div { | |
| 13 | class: 'editor' | |
| 14 | style: | |
| 15 | display: 'flex' | |
| 16 | 'flex-direction': 'column' | |
| 17 | 'justify-content': 'space-around' | |
| 14 | @node = div class: 'editor' | |
| 18 | 15 | |
| 19 | div { | |
| 20 | style: | |
| 21 | display: 'flex' | |
| 22 | flex: '0' | |
| 23 | 'justify-content': 'flex-end' | |
| 24 | 'border-bottom': '2px solid var(--gray-dark)' | |
| 25 | 'padding-bottom': '0.5em' | |
| 26 | 'margin': '-0.5em 0 0.5em' | |
| 16 | @saveBtn = with button 'save' | |
| 17 | .disabled = true | |
| 18 | .onclick = (_, e) -> @save e | |
| 27 | 19 | |
| 28 | with @saveBtn = button 'save changes' | |
| 29 | .disabled = true | |
| 30 | .onclick = (_, e) -> @save e | |
| 31 | } | |
| 32 | } | |
| 33 | 20 | @cm = window\CodeMirror @node, o { |
| 34 | 21 | :value |
| 35 | 22 | :mode |
| 115 | 115 | desc = js_fix element.innerText |
| 116 | 116 | desc = nil if desc == '' |
| 117 | 117 | |
| 118 | embedded = embed path or '', facet or '', fileder, { :nolink, :inline, :desc } | |
| 118 | 119 | element\replaceWith embed path or '', facet or '', fileder, { :nolink, :inline, :desc } |
| 119 | 120 | |
| 120 | 121 | embeds = \getElementsByTagName 'mmm-link' |
| 180 | 181 | -- out: 'mmm/dom', |
| 181 | 182 | -- transform: single code |
| 182 | 183 | -- } |
| 184 | { | |
| 185 | inp: 'URL -> (.+)', | |
| 186 | out: '%1', | |
| 187 | cost: 4, | |
| 188 | transform: do | |
| 189 | if MODE == 'CLIENT' | |
| 190 | (uri) => | |
| 191 | request = js.new js.global.XMLHttpRequest | |
| 192 | request\open 'GET', uri, false | |
| 193 | request\send js.null | |
| 194 | ||
| 195 | assert request.status == 200, "unexpected status code: #{request.status}" | |
| 196 | request.responseText | |
| 197 | else | |
| 198 | (uri) => | |
| 199 | print "URI", uri | |
| 200 | request = require 'http.request' | |
| 201 | req = request.new_from_uri uri | |
| 202 | headers, stream = req\go 8 | |
| 203 | assert stream\get_body_as_string! | |
| 204 | } | |
| 183 | 205 | { |
| 184 | 206 | inp: '(.+)', |
| 185 | 207 | out: 'URL -> %1', |
| 52 | 52 | ok, node = pcall fileder.gett, fileder, name, 'mmm/dom' |
| 53 | 53 | |
| 54 | 54 | if not ok |
| 55 | warn "couldn't embed #{fileder} #{name}: #{node}" | |
| 55 | 56 | return span "couldn't embed #{fileder} #{name}", |
| 56 | 57 | (pre node), |
| 57 | 58 | class: 'embed' |
| 0 | # examples | |
| 1 | To illustrate the capabilities of the proposed system, and to compare the results with the framework introduced above, | |
| 2 | a number of example use cases have been chosen and implemented from the perspective of a user. | |
| 3 | In the following section I will introduce these use cases and briefly summarize the implementation | |
| 4 | approach in terms of the capabilities of the proposed system. | |
| 5 | ||
| 6 | ## Publishing and Blogging | |
| 7 | Blogging is pretty straightforward, since it generally just involves publishing lightly-formatted text, | |
| 8 | interspersed with media such as images and videos or perhaps social media posts. | |
| 9 | Markdown is a great tool for this job, and has been integrated in the system to much success: | |
| 10 | There are two different types registered with *converts*: `text/markdown` and `text/markdown+span`. | |
| 11 | They both render to HTML (and DOM nodes), so they are immediately viewable as part of the system. | |
| 12 | The only difference for `text/markdown+span` is that it is limited to a single line, | |
| 13 | and doesn't render as a paragraph but rather just a line of text. | |
| 14 | This makes it suitable for denoting formatted-text titles and other small strings of text. | |
| 15 | ||
| 16 | The problem of embedding other content together with text comfortably is also solved easily, | |
| 17 | becase Markdown allows embedding arbitrary HTML in the document. | |
| 18 | This made it possible to define a set of pseudo-HTML elements in the Markdown-convert, | |
| 19 | `<mmm-embed>` and `<mmm-link>`, which respectively embed and link to other content native to mmm. | |
| 20 | ||
| 21 | ## Pinwall | |
| 22 | In many situations, in particular for creative work, it is often useful to compile resources of | |
| 23 | different types for reference or inspiration, and arrange them spacially so that they can be viewed | |
| 24 | at a glance or organized into different contexts etc. | |
| 25 | Such a pinwall could serve for example to organise references to articles, | |
| 26 | to collect visual inspiration for a moodboard etc. | |
| 27 | ||
| 28 | As a collection, the Pinwall is primarily mapped to a Fileder in the system. | |
| 29 | Any content that is placed within can then be rendered by the Pinwall, | |
| 30 | which can constrain every piece of content to a rectangular piece on its canvas. | |
| 31 | This is possible through a simple script, e.g. of the type `text/moonscript -> fn -> mmm/dom`, | |
| 32 | which enumerates the list of children, wraps each in such a rectangular container, | |
| 33 | and outputs the list of containers as DOM elements. | |
| 34 | ||
| 35 | The position and size of each panel are stored in an ad-hoc facet, encoded in the JSON data format: | |
| 36 | `pinwall_info: text/json`. This facet can then set on each child and accessed whenever the script is called | |
| 37 | to render the children, plugging the values within the facet into the visual styling of the document. | |
| 38 | ||
| 39 | The script can also set event handlers that react to user input while the document is loaded, | |
| 40 | and allow the user to reposition and resize the individual pinwall items by clicking and dragging | |
| 41 | on the upper border or lower right-hand corner respectively. | |
| 42 | Whenever a change is made the event handler can then update the value in the `pinwall_info` facet, | |
| 43 | so that the script places the content at the updated position and size next time it is invoked. | |
| 44 | ||
| 45 | ## Slideshow | |
| 46 | Another common use of digital documents is as aids in a verbal presentation. | |
| 47 | These often take the form of slideshows, for the creation of which a number of established applications exist. | |
| 48 | In simple terms, a slideshow is simply a linear series of screen-sized documents, that can be | |
| 49 | advanced (and rewound) one by one using keypresses. | |
| 50 | ||
| 51 | The implementation of this is rather straightforward as well. | |
| 52 | The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle, | |
| 53 | as well as a control interface with keys for advancing the active slide. | |
| 54 | It also allows putting the browser into fullscreen mode to maximise screenspace and remove visual elements | |
| 55 | of the website that may distract from the presentation, and register an event handler for keyboard accelerators | |
| 56 | for moving through the presentation. | |
| 57 | ||
| 58 | Finally the script simply embeds the first of its child-fileders into the viewport rect. | |
| 59 | One the current slide is changed, the next embedded child is simply chosen. | |
| 60 | ||
| 61 | ## Code Documentation | |
| 62 | /meta/mmm.dom/:%20text/html+interactive |
| 0 | {"x": 35.0, "y": 209.0, "w": 205.0, "h": 155.0}⏎ | |
| 0 | {"x": 94.0, "y": 265.0, "w": 205.0, "h": 155.0}⏎ |
| 0 | {"x": 263.0, "y": 210.0, "w": 353.0, "h": 295.0}⏎ | |
| 0 | {"x": 534.0, "y": 136.0, "w": 387.0, "h": 218.0}⏎ |
| 27 | 27 | }, |
| 28 | 28 | } |
| 29 | 29 | |
| 30 | div for child in *@children | |
| 30 | content = for child in *@children | |
| 31 | 31 | preview child |
| 32 | ||
| 33 | table.insert content, 1, (@gett 'intro: mmm/dom') | |
| 34 | ||
| 35 | div content |
| 0 | Two of the earliest wholistic computing systems, the Xerox Alto and Xerox Star, both developed at Xerox PARC and introduced in the 70s and early 80s, pioneered not only graphical user-interfaces, but also the "Desktop Metaphor". | |
| 1 | The desktop metaphor presents information as stored in "Documents" that can be organized in folders and on the "Desktop". It invokes a strong analogy to physical tools. | |
| 2 | One of the differences between the Xerox Star system and other systems at the time, as well as the systems we use currently, is that the type of data a file represents is directly known to the system. | |
| 3 | ||
| 4 | > In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs. | |
| 5 | > They do not "invoke a text editor", they "open a document". | |
| 6 | > The system knows the type of each file and notifies the relevant application program when one is opened. | |
| 7 | ||
| 8 | > The disadvantage of assigning data files to applications is that users sometimes want to operate on a file with a program other than | |
| 9 | its "assigned" application. \[...\] | |
| 10 | > Star's designers feel that, for its audience, the advantages of allowing users to forget | |
| 11 | about programs outweighs this disadvantage. | |
| 12 | ||
| 13 | (https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.911.6741) | |
| 14 | ||
| 15 | Other systems at the time lacked any knowledge of the type of files, | |
| 16 | and while mainstream operating systems of today have retro-fit the ability to associate and memorize the preferred applications to use for a given file based on it's name suffix, the intention of making applications a secondary, technical detail of working with the computer has surely been lost. | |
| 17 | ||
| 18 | Another design detail of the Star system is the concept of "properties" that are stored for "objects" throughout the system (the objects being anything from files to characters or paragraphs). | |
| 19 | These typed pieces of information are labelled with a name and persistently stored, providing a mechanism to store metadata such as user preference for ordering or defaut view of a folder for example. | |
| 20 | ||
| 21 | *** | |
| 22 | ||
| 23 | Fig. 8 - Star Retrospective | |
| 24 | ||
| 25 | The earliest indirect influence for the Xerox Alto and many other systems of its time, | |
| 26 | was the *Memex*. The *Memex* is a hypothetical device and system for knowledge management. | |
| 27 | Proposed by Vannevar Bush in 1945, the concept predates much of the technology that later was used to implement many parts of the vision. In essence, the concept of hypertext was invented. | |
| 28 | ||
| 29 | *** | |
| 30 | ||
| 31 | One of the systems that could be said to have come closest to a practical implementation of the Memex might be Apple's *Hypercard*. | |
| 32 | ||
| 33 | https://archive.org/details/CC501_hypercard | |
| 34 | ||
| 35 | "So I can have the information in these stacks tied together in a way that makes sense" | |
| 36 | ||
| 37 | In a demonstration video, the creators of the software showcase a system of stacks of cards that together implement, amongst others, a calendar (with yearly and weekly views), a list of digital business cards for storing phone numbers and addresses, and a todo list. | |
| 38 | However these stacks of cards are not just usable by themselves, it is also demonstrated how stacks can link to each other in meaningful ways, such as jumping to the card corresponding to a specific day from the yearly calendar view, or automatically looking up the card corresponding to a person's first name from a mention of the name in the text on a different card. | |
| 39 | ||
| 40 | Alongside Spreadsheets, *Hypercard* remains one of the most successful implementations of end-user programming, even today. | |
| 41 | While it's technical abilities have been long matched and passed by other software (such as the ubiquitous HTML hypertext markup language), these technical successors have failed the legacy of *Hypercard* as an end-user tool: | |
| 42 | while it is easier than ever to publish content on the web (through various social media and microblogging services), the benefits of hypermedia as a customizable medium for personal management have nearly vanished. | |
| 43 | End-users do not create hypertext anymore. | |
| 44 | ||
| 45 | *** | |
| 46 | ||
| 47 | The *UNIX Philosophy* describes the software design paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs | |
| 48 | research center in the 1960s. The concepts are considered quite influental and are still notably applied in the Linux community. | |
| 49 | Many attempts at summaries exist, but the following includes the pieces that are especially relevant even today: | |
| 50 | ||
| 51 | > Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. | |
| 52 | > Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be | |
| 53 | > written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs | |
| 54 | > than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, | |
| 55 | > become general and useful tools. | |
| 56 | ||
| 57 | (B. Kernighan, R. Pike: The UNIX Programming Environment) | |
| 58 | ||
| 59 | This appraoch has multiple benefits with regard to end-user programmability: | |
| 60 | Assembling the system out of simple, modular pieces means that for any given task a user may want to implement, | |
| 61 | it is very likely that preexisting parts of the system can help the user realize a solution. | |
| 62 | Wherever such a preexisting part exists, it pays off designing it in such a way that it is easy to integrate for the user later. | |
| 63 | Assembling the system as a collection of modular, interacting pieces also enables future growth and customization, | |
| 64 | since pieces may be swapped out with customized or alternate software at any time. | |
| 65 | ||
| 66 | *** | |
| 67 | ||
| 0 | 68 | Based on this, a modern data storage and processing ecosystem should enable transclusion of both content and behaviours |
| 1 | 69 | between contexts. |
| 2 | 70 | Content should be able to be transcluded and referenced to facilitate the creation of flexible data formats and interactions, |
| 12 | 80 | with as little caveats as possible. |
| 13 | 81 | |
| 14 | 82 | The system needs to be browsable and understandable by users. |
| 83 | ||
| 84 | Editing content in the system and customizing the system itself should follow the same principles and be nearly indistinguishable. According to Kay (1991), building the system out of "the same kinds of building blocks" that their system is made out of lets end-users "aspire to \[create\] the kinds of things that they find in their environment". | |
| 85 | One way of ensuring this consistency of experience and logical continuity of system and content, | |
| 86 | is to develop the system to be 'self-hosting' as much as possible, i.e. to implement it in terms of the system itself. Any part of the system that is implemented as content of the system itself automatically becomes part accessible to the end-user as part of their experience, and thereby becomes customizable and transparent. | |
| 87 | ||
| 88 | https://tinlizzie.org/IA/index.php/End-User_Programming_by_Alan_Kay_(1991) | |
| 0 | 0 | # motivation |
| 1 | ||
| 2 | The majority of users interacts with modern computing systems in the form of smartphones, laptops or desktop PCs, | |
| 3 | using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android. | |
| 4 | ||
| 5 | All of these operating systems share the concept of *Applications* (or *Apps*) as one of the core pieces of their interaction model. | |
| 6 | Functionality and capabilities of the digital devices are bundled in, marketed, sold and distributed as *Applications*. | |
| 7 | ||
| 8 | In addition, a lot of functionality is nowadays delivered in the form of *Web Apps*, which are used inside a *Browser* (which is an *Application* itself). | |
| 9 | *Web Apps* often offer similar functionality to other *Applications*, but are subject to some limitations: | |
| 10 | In most cases, they are only accessible or functional in the presence of a stable internet connection, | |
| 11 | and they have very limited access to the resources of the physical computer they are running on. | |
| 12 | For example, they usually cannot interact directly with the file system, hardware peripherals or other applications, | |
| 13 | other than through a standardized set of interactions (e.g. selecting a file via a visual menu, capturing audio and video from a webcam, opening another website). | |
| 14 | ||
| 15 | On the two Desktop Operating Systems (Mac OS X and Windows), file management and the concepts of *Documents* are still central | |
| 16 | elements of interactions with the system. The two prevalent smartphone systems deemphasize this concept by only allowing access to the | |
| 17 | data actually stored on the device through an app itself. | |
| 18 | ||
| 19 | This focus on *Applications* as the primary unit of systems can be seen as the root cause of multiple problems: | |
| 20 | Because applications are the products companies produce, and software represents a market of users, | |
| 21 | developers compete on features integrated into their applications. | |
| 22 | ||
| 23 | However this lack of control over data access is not the only problem the application-centric approach induces: | |
| 24 | A consequence of this is that interoperability between applications and data formats is rare. | |
| 25 | To stay relevant, monlithic software or software suites are designed to | |
| 26 | As a result applications tend to accrete features rather then modularise and delegate to other software [P Chiusano]. | |
| 27 | Because applications are incentivised to keep customers, they make use of network effects to keep customers locked-in. | |
| 28 | This often means re-implementing services and functinality that is already available | |
| 29 | and integrating it directly in other applications produced by the same organisation. | |
| 30 | ||
| 31 | This leads to massively complex file formats, | |
| 32 | such as for example the .docx format commonly used for storing mostly | |
| 33 | textual data enriched with images and videos on occasion. | |
| 34 | The docx format is in fact an archive that can contain many virtual files internally, | |
| 35 | such as the images and videos referenced before. | |
| 36 | However this is completely unknown to the operating system, | |
| 37 | and so users are unable to access the contents in this way. | |
| 38 | As a result, editing an image contained in a word document is far from a trivial task: | |
| 39 | first the document has to be opened in a word processing application, | |
| 40 | then the image has to be exported from it and saved in its own, temporary file. | |
| 41 | This file can then be edited and saved back to disk. | |
| 42 | Once updated, the image may be reimported into the .docx document. | |
| 43 | If the word-processing application supports this, | |
| 44 | the old image may be replaced directly, otherwise the user may have to remove the old image, | |
| 45 | insert the new one and carefully ensure that the positioning in the document remains intact. | |
| 46 | ||
| 47 | https://www.theverge.com/2019/10/7/20904030/adobe-venezuela-photoshop-behance-us-sanctions | |
| 48 | ||
| 49 | ||
| 1 | 50 | The application-centric computing paradigm common today is harmful to users, |
| 2 | 51 | because it leaves behind "intert" data as D. Cragg calls it: |
| 3 | 52 | |
| 17 | 66 | where they are subject to foreign laws and privacy concerns are intransparently handled by the companies. |
| 18 | 67 | Should the company, for any reason, be unable or unwanting to continue servicing a customer, |
| 19 | 68 | the data may be irrecoverably lost (or access prevented). |
| 20 | ||
| 21 | However this lack of control over data access is not the only problem the application-centric approach induces: | |
| 22 | Another consequence is that interoperability between applications and data formats is hindered. | |
| 23 | Because applications are incentivised to keep customers, they make use of network effects to keep customers locked-in. | |
| 24 | As a result applications tend to accrete features rather then modularise and delegate to other software [P Chiusano]. | |
| 25 | ||
| 26 | This leads to massively complex file formats, | |
| 27 | such as for example the .docx format commonly used for storing mostly | |
| 28 | textual data enriched with images and videos on occasion. | |
| 29 | The docx format is in fact an archive that can contain many virtual files internally, | |
| 30 | such as the images and videos referenced before. | |
| 31 | However this is completely unknown to the operating system, | |
| 32 | and so users are unable to access the contents in this way. | |
| 33 | As a result, editing an image contained in a word document is far from a trivial task: | |
| 34 | first the document has to be opened in a word processing application, | |
| 35 | then the image has to be exported from it and saved in its own, temporary file. | |
| 36 | This file can then be edited and saved back to disk. | |
| 37 | Once updated, the image may be reimported into the .docx document. | |
| 38 | If the word-processing application supports this, | |
| 39 | the old image may be replaced directly, otherwise the user may have to remove the old image, | |
| 40 | insert the new one and carefully ensure that the positioning in the document remains intact. | |
| 41 | ||
| 42 | In fact all of this is unnecessary, since the image had been stored in a compatible format on disk in the first place: | |
| 43 | The system was simply unaware of this because the word document had to be archived into a single file | |
| 44 | for ease of use by the word processor, and this single file is opaque to the system. | |
| 45 | 69 | |
| 46 | 70 | Data rarely really fits the metaphora of files very well, |
| 47 | 71 | and even when it does it is rarely exposed to the user that way: |
| 68 | 92 | integration into the users' other systems and customization, |
| 69 | 93 | rather than lure into the walled-gardens of corporate ecosystems using network-effects. |
| 70 | 94 | |
| 71 | Services like this are | |
| 72 | ||
| 73 | not even directly accessible to end-users anymore | |
| 74 | Data is inert ko[Cragg 2016] | |
| 95 | Data is inert [Cragg 2016] | |
| 75 | 96 | |
| 76 | 97 | Key points: |
| 77 | 98 | - data ownership |
| 99 | 120 | contained data is lost. It is for example a non-trivial and unenjoyable task to edit an image file contained |
| 100 | 121 | in a word document in another application and have the changes apply to the document. In the same way, |
| 101 | 122 | text contained in a photoshop document cannot be edited in a text editor of your choice. |
| 123 | ||
| 124 | Creative use of computer technology is limited to programmers, since applications constrain their users to the | |
| 125 | paths and abilities that the developers anticipated and deemed useful. | |
| 126 | Note that 'creative' here does not only encompass 'artistic': this applies to any field and means | |
| 127 | that innovative use of technology is unlikely to happen as a result of practice by domain experts. | |
| 27 | 27 | table.insert args, style: { 'list-style': 'none', 'font-size': '0.8em' } |
| 28 | 28 | ol table.unpack args |
| 29 | 29 | |
| 30 | -- @TODO: s/filesystem/a way of organizing files/g | |
| 31 | append h1 'mmmfs', style: { 'margin-bottom': 0 } | |
| 32 | append p "a file and operating system to live in", style: { 'margin-top': 0, 'padding-bottom': '0.2em', 'border-bottom': '1px solid black' } | |
| 30 | append h1 'Empowered End-User Computing', style: { 'margin-bottom': 0 } | |
| 31 | append p "A Historical Investigation and Development of a File-System-Based Environment", style: { 'margin-top': 0, 'padding-bottom': '0.2em', 'border-bottom': '1px solid black' } | |
| 33 | 32 | |
| 34 | 33 | -- render a preview block |
| 35 | 34 | do_section = (child) -> |