[whatwg] Authoring Re: several messages about HTML5
Dave Raggett
dsr at w3.org
Sat Feb 24 02:22:59 PST 2007
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
More information about the whatwg
mailing list