[whatwg] Authoring Re: several messages about HTML5

[Dave Raggett]

On Fri, 23 Feb 2007, Andrew Fedoniouk wrote:

> 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.

I think people need to have some knowledge of the basic kinds of 
document components available in HTML, e.g. headings, paragraphs, 
the three kinds of lists, blockquotes, preformatted blocks, various 
kinds of emphasis and their respective role, hypertext links, 
images, etc. But, that doesn't mean they need to know the markup, 
for these components, although that may be helpful.

CSS varies from very simple rendering properties to very complex 
features that require expert knowledge. Providing support for simple 
features is straightforward. Complex layout features can be hidden 
as templates that are provided by experts, for example, the palette 
of slide templates offered to authors by PowerPoint and Impress. 
CSS experts will also be involved in the preparation of skins or 
themes that can be applied to the content produced by an editor.

> | 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.

Think of the difference between someone able to put together simple 
spreadsheet applications versus someone with a knowledge of SQL and 
the theory and practice of relational databases. The spreadsheet 
developer needs to understand the practical requirements of what 
they are trying to do, but the server side support is the same for 
all such spreadsheets and can be provided by someone else. The 
person with the rich knowledge of SQL etc. could separately include 
specific spreadsheets as part of a workflow process, but that is an 
entirely different role from creating the spreadsheets in the first 
place. The next generation of HTML forms should provide the ease and 
convenience of spreadsheets for simple applications, without the 
need for authors to know about scripting and events etc.

> 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.

Hoping the above helps.

p.s. From your website: [BlockNote.Net] "allows you to edit your 
documents exactly as they will appear in all popular browsers."

    http://blocknote.net/features.shtml

I can see why you are focussing on that, but it isn't always 
appropriate, and it depends on what use cases you are going after. 
For example, where a website is developed by a team of people with 
different roles that separate content from page layout. Another 
example is where content needs to be delivered to a wide range of 
devices with policies controlling the choice of styling and layout 
as appropriate to different classes of device.

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