Freeway maintains its own internal description of the site and the objects
contained therein.
[Long]
Lifted from my blog over at <
http://quercus.livejournal.com/
157332.html>
It's widely known and accepted that "web design" should separate HTML
"structure" from CSS "presentation". This distinction works for
individual pages, but it's insufficient for whole-site design and even
for some aspects of page design.
There is much current interest in "semantic HTML", the idea that
document semantics are expressed by the HTML. This is limited by the
trivial semantic capability of unadorned HTML. Although broad
semantics are important for correctly authoring HTML, in turn HTML is
not able to express useful semantics.
Efficient site design should allow the re-use of CSS between pages.
Achieving this needs more than page-specific semantics, as those turn
out to be too context-sensitive and variable between pages.
Consistency of binding to styling across a large site must operate at
a deeper level than is expressible by HTML alone, or is typically
expressed by the simple use of HTML with class or id attributes.
A really good design must separate out more than this. It needs to
take a "Structuralist" view of HTML, in the sense of the post-WW2
French Structuralist linguists.
Saussure's distinction between langue and parole is relevant here.
HTML expresses the parole or "speech" but the stable underlying
meaning (which we need to recognise before we can attach a stable and
relevant presentation to it) must depend on the langue or "language"
instead. Our authoring task becomes to identify and manipulate this
level.
Application to WYSIWYG Editing Tools
The necessity for finding the langue is most evident in the problems
surrounding WYSIWYG editing. Thus far, WYSIWYG has been a failure in
providing useful web editing tools. This same failure is repeated and
similar in the case of all such tools. The reason for this is best
explained in a Structuralist context.
WYSIWYG has been successful for DTP and paper-based "page-design"
problems. It is an obviously attractive interface metaphor to extend
to web authors. Although such tools (e.g. DreamWeaver) have even
become popular, they still fail to be well-regarded by expert web
designers. This is usually put down merely to the mutability of web
rendering devices (i.e. desktop computers vs. phones) compared to
static paper. The author's view is that the Structuralist requirement
on authoring is more fundamental than this and must be addressed
before WYSIWYG editing can become successful.
Some axioms are assumed for the purpose of this essay:
* Technically incompetent WYSIWYG editors are obviously
incompetent and thus uninteresting. If an editor (e.g. FrontPage)
fails even to generate basically valid code, then its semantic basis
is of no interest.
* The needs of some authors can be met by the lowest of standards.
The Web is by design accommodating of error and such authoring still
has its place. This essay is focused at a rather higher level.
* The "What You See Is Not What Others See" problem of web-
authoring compared to static paper does not need to be re-stated.
A typical "best current practice" WYSIWYG editing tool might operate
in the following manner:
* "Content units" are placed on the page. Drag-and-drop tools
allow them to be positioned.
* The semantics of each unit are implied, by the author selecting
an appropriate HTML element to represent them. This operates at no
more than the bare HTML level of <div> / <p> / <li> etc.
* The length dimension for sizing and positioning the units is
chosen; hopefully as ems, but typically as pixels.
* Additional decorators may be applied manually as class or id
attributes.
* CSS may be manually edited for each unit, often attached
directly through the style attribute.
* Output HTML is generated. As a minimum (e.g. Freeware), each
unit gives rise to a <div> or similar element, with a CSS style
attribute using absolute positioning to place it onto the page. A more
sophisticated generator might extract this CSS into a stylesheet, but
still uses an ordinal identifier (i.e. an id attribute per element) to
link each element with its own CSS block.
Cruder output methods could bludgeon the long-suffering <table>
element with absolute positioning. Better ones might normalise some
CSS rules such that properties set to common values are grouped into
broader rules and their selectors simplified mechanically by simple
set logic.
Current WYSIWYG editing tools fail to support the following features,
in any way more sophisticated than that of source-level editing.
* Attaching CSS rules as a "style" by class, rather than ordinally
to an element.
* Attaching CSS to a set of elements, generating appropriate
selectors and possibly even additional class attributes in the HTML.
* Flexible positioning methods that recognise the varying
relationships between elements and choose appropriate positioning.
* Real understanding of the fluid nature of the "web canvas",
compared to static paper and page-layout.
Of these four omissions noted, only the last is part of the usually
identified "the web is not static paper" complaint on WYSIWYG web
authoring. The first indicate the need for a Structuralist
understanding of the site's meta-structure, so as to achieve real
progress towards a WYSIWYG editor.
Towards a Structuralist WYSIWYG editor
Such an editor makes manifest the underlying structure of the site and
documents. This structure forms the basis of the authoring operations.
Authoring now consists of two phases, executed iteratively. One is of
adding content to a meta-structure, the other is of refining this meta-
structure, either by describing it ab initio, or by inferring it from
existing HTML structure. The inferencing step can be used both to
import existing HTML content and also to continuously refactor a
site's structure as it is developed further. New structural content
may be attached to an existing simple meta-structure and the meta-
structure may then grow more complex as the structure is analysed and
refactored. This refactoring also permits a site to grow from an
initially empty meta structure.
Presentation styling is added manually, but operates upon the meta-
structure as a framework, rather than directly onto the structure. As
the meta-structure is more fundamental and stable than the structure,
this reduces time-consuming rework of trivia during the evolution of a
site.
Generation of the site's code is based on the structural elements, as
for the current generation of WYSIWYG editors. Annotation (through
HTML element selection, class and id) is also added automatically,
describing the structure's relation to the described meta-structure.
CSS output is based almost entirely on querying the meta-structural
model and outputting the necessary selectors and rules.
It is not clear as yet if such a structure must be stored separately
from the HTML, may be embedded into the HTML by explicit metadata, or
may reliably be inferred from the bare HTML structure. Obviously these
options are of increasing benefit, but also increasing difficulty in
their achievement.
