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.
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.
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.
Cheers,
Dave Raggett <[EMAIL PROTECTED]> http://www.w3.org/People/Raggett
