On Wed, 21 Feb 2007, Benjamin Hawkes-Lewis wrote:
Dave Raggett wrote:
I am therefore devoting a lot of my time into developing a
new kind of authoring environment that combines a semantic view with
a wysiwyg view, and which will use dictionaries to generate the
markup that few of us can be bothered to write directly.
This project sounds very interesting, although I'm a bit dubious about
the benefit of a single WYSIWYG view rather than a series of views
presenting how a given document skin would look in different devices
(e.g. mobile view, screen reader view, console view, magnifier view,
desktop view). This would help with the problem Chaals mentioned of
people continuing to view the web as essentially a visual medium. Is
this project of yours a public project? Are there more details about
what you're trying to do somewhere?
The wysiwyg view is for there for the purposes of authoring and
different style sheets are likely used for different delivery
contexts. I am very much interested in device independent authoring
tools as part of larger content management frameworks. The idea of
being able to combine content with different skins for different
delivery contexts is very appealing.
The editor project will be released as an open source project, at
least as far as the client side pieces are concerned. It is still
at an early stage but a beta release is expected by late Summer.
Perhaps the best metaphor for the separation of content and styles is
"skinning" or "theming", a concept almost as popularly familiar as
WYSIWIG itself.
indeed!
Daniel Glazman (of nVu fame) pointed out the difficulties of using
wysiwyg with the final style sheets in a presentation in XTech 2006.
How do you do wysiwyg editing if the style sheet hides the piece you
are editing? An authoring environment could provide one style sheet
for wysiwyg editing and a range of style sheets for delivery
purposes.
Authoring tools need to respect this separation of roles and avoid
burdening people with tasks that are inappropriate to their roles.
Yes I suspect moving away from single view to workflow models
would help here.
I am organizing a workshop on declarative models of distributed web
applications (June 5-6, Dublin, Ireland) with the goal of bringing
people together to discuss the modeling, security and usability
aspects of future authoring frameworks. Some details can be
found here:
http://www.w3.org/2006/10/uwa-charter.html#workshops
A call for participation will be announced shortly.
Getting back to HTML5, I am interested in a clean way to set an
editing caret within a document's markup, and independent of the
existing designMode/contentEditable/execCommand features. In my work
I am using a span element for the caret and manipulating it via the
DOM. That works pretty well modulo browser variations for where they
break lines. It would be good to have fine control of that too, e.g.
to prevent line breaking within words (except after hyphens) and
before or after span elements except when adjacent to whitespace.
The designMode/execCommand features in IE and copied by other
browsers are much to much oriented towards very simple word
processing (e.g. wordpad) and a poor match to the needs for editing
structured documents. Furthermore the markup generated varies
considerably across browsers, though this can be cleaned up to some
extent via post processing. HTML5 should include support for
editing, but I would strong recomend against standardizing
designMode and execCommand in their current form.
Dave Raggett <[EMAIL PROTECTED]> http://www.w3.org/People/Raggett
