[whatwg] Authoring Re: several messages about HTML5

[Andrew Fedoniouk]

----- Original Message ----- 
From: "Dave Raggett" <dsr at w3.org>
To: "Andrew Fedoniouk" <news at terrainformatica.com>
Cc: "Adrian Sutton" <adrian.sutton at ephox.com>; "Karl Dubost" <karl at w3.org>; 
<whatwg at lists.whatwg.org>
Sent: Friday, February 23, 2007 4:03 AM
Subject: Re: [whatwg] Authoring Re: several messages about HTML5


| On Thu, 22 Feb 2007, Andrew Fedoniouk wrote:
|
| > In reality WYSIWYG principle has one hidden part:
| > What You See Is What You Will Get and What You Can
| > Change Consistently by Using Solely UI Facilities/Tools.
| > That is real meaning of modern WYSIWYG interpretation.
|
| I think I understand what you mean, and that is the wysiwyg approach
| has to be supplemented by other UI. In my case, this is provided
| using a context pane that gives users the means to access and
| manipulate the information that is hidden in the purely
| presentational wysiwyg pane. The inspiration comes from Visual Basic
| forms editors where a properties pane is provided for the currently
| selected object. In my case the context is associated with the
| position of the editing caret in the wysiwyg pane. Users can widen
| or narrow the context as needed to look at the properties of
| ancestor elements.

Person that edits VB form and person that wtites blog entry (one of the main
sources of web content these days) belong to different groups of actors
and these are completely different use cases.

There are more or less successfull applications on the market already
that support (or assist) WYSIWYG editing for the actor group
"Web Designer with at least basic knowledge of
html and its DOM".  This kind of actors are ready to consume
concept of "properties of ancestor elements".

But there are no consistent WYSIWYG HTML/CSS editor applications
in the wild that support in full actor model "Writer without knowledge
of HTML and CSS". Simply because of the nature of HTML and CSS.

Think about <htmlarea> (WYSIWYG editor) or the like element
on the blog page. Or <htmlarea> that allow you to edit "richtext e-mail"

Such widget:

1) shall alow "richtext" editing without reading HTML specification.
2) shall alow to use of only structural constructs that have
strong and clear(consistent) semantic meaning.
3) reaction on all UI actions like pressing "Enter" key, Ctrl-B, etc.
shall be predictable upfront.
4) reaction on all UI actions shall be exactly reproducible - the same
set of actions in different instances of the widget shall produce exactly
same structure of the content.
5) shall not introduce new entites for the actor that are not related
to the main task: creating of the content.
6) shall present (render on the screen) only those markup element/attributes
that current actor can change in the current editing context (True WYSIWYG).
7) No hidden information is allowed - author and authenticity principle.

etc.

|
| As an example, consider a form field. The user selects the text for
| use as a field label and clicks on the field button (part of the
| editing toolbar). The editor then inserts the field and sets up the
| label. The user then uses the context pane to enter the name of the
| field, and to set additional properties. My forms-lite/xforms-tiny
| library supports JavaScript expressions for validation constraints,
| calculated field values, the context in which the field must be
| filled out, and when it is relevant. The user can define these
| expressions by filling out the input fields within the context pane
| that appear when the field is selected in the wysiwyg pane.
|
| The context pane isn't a slavish UI for element attributes, but
| rather a means to support the tasks that users are expected to do.

Here is what I do not understand in your use case:

Design of input forms implies design of server side code thus
set of programming skills and knowledge of some specific abstractions.

So actor here is a programmer - person
who knows about concept of two views: "source code" and
final rendering.

For the actor "Programmer", why do you think that
editing of text :
  <input onvalidate="someformula"> is harder than
sequence of actions:
1) click on the toolbar
2) select 'onvalidate' property in editing property panel and
3) type that formula in the field that appear.

?

|
| p.s. with the use of an editing style sheet and the notion of
| skinning the page as a separate operation, the wysiwyg pane can use
| CSS to show borders for div elements etc. as appropriate to support
| the editing task. That is very much application dependent and not a
| fixed part of the design.

Dave, I would like to hear your definition of the actor that
is supposed to use this. As for me your task really appears
a bit out of scope of HTML WYSIWYG editing.

Andrew Fedoniouk.
http://terrainformatica.com


|
| Cheers,
|
|  Dave Raggett <dsr at w3.org> http://www.w3.org/People/Raggett
|