Note: the design on this page has never been implemented as an application; I wrote it in 1999 to encapsulate my ideas about what was missing from current HTML editors, which were anything but writers' tools. At the time, the closest implementation I found was XMeTaL, but that's expensive overkill for this purpose. In September 2002 the most promising tool was eWebEditPro. This design is ©1999 Peter Hilton (all rights reserved).
The problem at hand
When a novellist submits a manuscript its content is used, not its design. In the same way, authors of web pages, technical documentation and internal corporate communications are not and should not be the designers of those documents' appearances.
Word-processors do not allow this, as they are oriented towards typography. HTML has the potential for content and design to be separated, but unfortunately, current HTML editors do not allow this. This is presumably because they are addressing a different problem - WYSIWY(NT)G editing for graphic-rich content-free web page design.
Cascading Style Sheets
The abstract to the Cascading Style Sheets, level 2: CSS2 Specification describes Cascading Style Sheets (CSS) as follows.
CSS2 is a style sheet language that allows authors and users to attach style (e.g., fonts, spacing, and aural cues) to structured documents (e.g., HTML documents and XML applications). By separating the presentation style of documents from the content of documents, CSS2 simplifies Web authoring and site maintenance.
The separation of presentation style and content is crucial in making it possible to separate the roles of document designer and document author.
The HTML 4.0 Strict DTD
There are three document type definitions (DTDs) of HTML 4.0, which define three variants of the language. According to the World Wide Web Consortium (W3C) the 'HTML 4.0 Strict DTD includes all elements and attributes that have not been deprecated or do not appear in frameset documents. [...] We recommend that authors write documents that conform to the strict DTD rather than the other DTDs defined by [the HTML 4.0] specification'. In this document I shall refer to HTML that validates to the HTML 4.0 Strict DTD as Strict HTML 4.
The Strict HTML 4/CSS platform
The combination of and Strict HTML 4 and external Cascading Style Sheets promises separation of content and presentation in HTML, because this prohibits presentation mark-up in the HTML. Ideally this would let content authors concentrate on writing without having to code valid HTML by hand.
A visual editor that met the requirements listed in this document would make HTML 4.0 Strict/CSS a usable platform for many types of document, other than web pages, particularly internal company documents, for which presenting information in a standard format is more important than flexibility of design for individual documents.
Current visual HTML editors
The current visual editors - those which do not require knowledge of the HTML element names - are typified by Microsoft FrontPage. These editors reflect a trend to try to turn HTML into an ever-richer typographical page-description language, a purpose for which it was not designed, by those people who failed to understand the concept of structural mark-up.
HTML mark-up is concerned with structure and semantics, not presentation, so any editor that hides this is fundamentally flawed. See What HTML Is... and What It Isn't for a further explanation.
The goals of Lime
- allows content authors to produce HTML documents without knowledge of HTML markup
- guarantees valid version 4.0 strict HTML
- allows content authors to concentrate on content, not design
- is a simple and elegant application
This is clearly not achieved by a word-processor - the current default tool, or any current WYSIWYG editor.
One editor that almost meets these goals is Softquad's XMetaL, which is designed to be a customisable XML authoring tool. A simplified customised set-up can be created, for authoring HTML 4.0 Strict/CSS, but XMetaL is a more complex and expensive product than is really necessary.
Benefits of Lime and HTML/CSS
Lime will be better than a word-processor because
- it will be simple and easy-to-use as it will avoid the complexity associated with typographical and logout control
- it will generate smaller files, in an open human-readable format
- it will be a simpler action application
- it will allow authors to concentrate exclusively on content, without being distracted by formatting
- it will produce documents with a consistent design
- HTML and CSS are proven, well-supported and open technologies
- is will have an Open Source licence
These are the strict requirements for the basic concept to work.
Common application requirements
- For user-interface consistency, Lime shall comply with the Windows Interface Guidelines For Software Design, or whatever guidelines are appropriate for the chosen platform
- Lime shall have Find and Find/Replace facilities.
- Lime shall have online help.
- Lime shall have an Undo facility.
- Lime shall implement the clipboard.
- Lime shall implement the File menu MRU list.
- Lime shall provide keyboard shortcuts for most options
- Lime shall support multiple document windows.
- The content shall be editable in a view that renders the external style sheet.
- The user interface shall indicate the currently chosen block-level element and any current inline elements.
- The user interface shall allow block-level elements to be chosen from a fixed set of valid options.
- The user interface shall allow
SPANelements to be entered.
- The user interface shall allow inline elements to be chosen from a fixed set of valid options.
- Lime shall not allow multiple consecutive spaces to be entered.
- Lime shall not allow multiple empty paragraphs to be entered; and shall not save empty paragraphs.
- The user shall be able to include tables in the document.
- The user shall be able to add or remove rows and columns from a table.
- The user shall be able to add or remove table cells from a table.
- The user shall be able to split or merge table cells.
- The user shall be able to include ordered or unordered lists in the document.
- The user shall be able to include definition lists in the document.
- The user shall be able to nest lists.
- Lime shall load all versions of HTML, and shall attempt to interpret invalid mark-up, rather than fail to load the document.
- Lime shall always save HTML 4.0, which exludes all deprecated attributes and elements, most of which are for formatting.
- The user shall be able to choose an external style sheet for the current document.
- The user shall be able to edit values for all valid
HEADsection elements, including custom
- The user shall have the option to save either the contents of
BODYtag as an HTML fragment, or the complete HTML document.
- Lime shall have a spelling checker facility.
- Lime shall always present to the user full names for the HTML elements, as well as the tag names.
Successive versions of Lime
The priorities for successive versions of Lime are
- basic functionality
- style sheet support
- outliner functionality
- the remaining missing 'word-processor functionality'.
The extra requirements are
- Lime should provide a document map view that shows HTML heading styles with levels.
- Lime should include 'outliner' functionality, based on HTML heading styles.
- The user should be able to specify classes for HTML elements from a pick list of classes defined in the current style sheet(s).
- The user should be able to include HTML forms in the document.
- Lime should include a facility to sort tables, as in Microsoft Word.
- The user should be able to configure the list of valid tags.
- Lime should include version tracking functionality, using the
- The user should be able to insert and edit client-side scripts in the document.
The Find, Replace and About dialogue boxes
should provide standard functionality. The Document Properties dialogue box will allow the user to specify the data used in the HTML
HEAD section. The Insert Image and Insert Table dialogue boxes will allow the user to specify initial value, in order to create valid
TABLE elements, respectively.
The Structure Editor is a non-modal dialogue box, or inspector, that will show the document element structure as a tree control, with one node for each HTML element. The tree control selection indicates the current HTML element. The selected node will be synchronised with the cursor position in the main view. Clicking a node in the structure tree sets the document selection to that element's contents - a few emphasised words or a paragraph, for example.
The Attribute Editor is a non-modal dialogue box, or inspector, that lists attributes for the current HTML element as a list of name-value pairs, in a two-column grid control. Each attribute name cell is a type-in control that also has a pick-list. This pick-list gives a choice of the valid attributes for the current element that are not already in the element list.
The attribute value cells are just text-entry fields, except for the
class attribute, whose value should have a pick list of the available classes defined for the current element in the current style sheet.
Toolbars and status bar
Toolbars shall include
- standard buttons for common menu options
- a pulldown list to choose the current block-level element
- toggle buttons to show state of inline elements; turning one off removes the current span of that element; turning one on applies the element to the current selection, or the current word if there is no selection
- a URL toolbar, as on a web browser, that displays the current file URL and allows the user to specify a document to load
The status bar should show the current HTML context.
Ordered and unordered lists will be treated as block styles, rather
than deal with
LI tags separately. Choosing one of these block styles will set the current block tag to be
LI. If one of the two surrounding blocks is also an
LI in a list of the same type, then the current block will be merged into that list. Otherwise, a new
UL list will be created with the current block as its only list item.
Definition list terms and definitions will be treated
as separate block styles. Consecutive terms and definitions will form a single
DL element in the same way that consecutive
LI list items form either a
This section lists menus and menu options, with keyboard short-cut keys and descriptions of the menu options actions'. Where no action is given, the conventional behaviour under Windows should be assumed.
|Document Properties||Open the Document Properties dialogue box|
|Find...||F||Opens the Find dialogue box|
|Replace...||H||Opens the Replace dialogue box|
|Toolbar||Toggles display of the toolbar|
|Structure Editor||Toggles display of the Structure Editor|
|Attribute Editor||Toggles display of the Attribute Editor|
|Zoom In||]||Enlarges typefaces, images and all relative spacing|
|Zoom Out||[||Shrinks typefaces, images and all relative spacing|
|Normal Zoom||=||Sets typefaces, images and spacing to their default sizes|
|Use Style Sheet||Toggles whether the display is rendered according to the document's style sheet|
|Line Break||Shift Enter||Inserts an HTML
|List||L||Inserts a list at the cursor location, or a nested list if the current paragraph is a list item|
|Image...||Opens the Insert Image dialogue box, to allow the user to define a new image to insert at the current cursor location|
|File...||Opens a file selector, to allow the user to choose a file to insert at the current cursor location|
|Insert Table...||T||Opens the Insert Table dialogue box, to allow the user to define a new table to insert at the current cursor location|
|Delete Table||Deletes the current table|
|Split Table||Splits the current table into two tables, making the current row the first row of the second table|
|Insert Row/Column/Cell||Inserts a row, column or cell at the cursor location, according to the current selection|
|Delete Rows/Columns/Cells||Deletes a row, column or cell at the cursor location, according to the current selection|
|Merge Cells||Merges the currently selected cells, to form a single table cell|
|Split Cell||Splits the current cell into two adjacent cells|
|Select Row||Selects the current row|
|Select Column||Selects the current column|
|Select Table||Selects the current table|
|Help Contents||Displays the contents page of the online help|
|Lime Web Site||Launches the Lime web site|
|About Lime||Displays the About dialogue box|
Appendix: List of editable elements and attributes
The design implies that only the following tags will be used. For each tag, the valid attributes will be as defined in the HTML specification, for the Strict DTD.
|ADDRESS||contact information for the author|
|ABBR||abbreviated form (e.g., WWW, HTTP, etc.)|
|B||bold text style|
|BDO||I18N bi-directional text over-ride|
|BIG||large text style|
|BR||forced line break|
|CODE||computer code fragment|
|KBD||text to be entered by the user|
|I||italic text style|
|Q||short inline quotation|
|SAMP||sample program output, scripts, etc.|
|SMALL||small text style|
|TT||teletype or monospaced text style|
|VAR||instance of a variable or program argument|
The following core attributes apply to all of the elements listed above.
|id||document-wide unique id --|
|class||space separated list of classes|
|dir||direction for weak/neutral text||(but not |
|lang||space separated list of classes||(but not |
|style||associated style info|