W3C home > Mailing lists > Public > www-html@w3.org > January 2002

RE: ? what to do ?

From: Christian Wolfgang Hujer <Christian.Hujer@itcqis.com>
Date: Tue, 8 Jan 2002 16:53:21 +0100
To: "Robert Koberg" <rob@koberg.com>, <www-html@w3.org>
Message-ID: <001601c1985c$990465e0$0795e23e@andromedacwh>
Hello Robert,

> -----Original Message-----
> How would you use forms to create a document like this:
>
> <body>
> <h1>title blah</h1>
> <p>a para graph that has arbitrary <strong>bold text</strong</p>
> <p> then maybe an image underneath here</p>
> <img src="blah.gif" alt="blah"/>
> <h2>sub section title</h2>
> <ol>
> <li>one</li>
> <li>two</li>
> <li>three</li>
> </ol>
> </body>
>
> oops, no, I meant:
>
> <body>
> <h1>title blah</h1>
> <ol>
> <li>one</li>
> <li>two</li>
> <li>three</li>
> </ol>
> <p>a para graph that has arbitrary <strong>bold text</strong</p>
> <h2>sub section title</h2>
> <p> then maybe an image underneath here</p>
> <img src="blah.gif" alt="blah"/>
> </body>
I wouldn't use forms for this, I'd use vi improved ;)

> My point is that writing an arbitray 'article' document is extremely
> difficult with forms.  I have been working for major publishers and used
> many of the form based solutions. The editors HATE them. Why not just flip
> the switch to turn on inline editing? I have an editor i am
> getting ready to
> release that does just that for IE5.5+. I would like to eventually support
> other browsers/systems but most people don't seem to be aware that such
> functionality can exist.
I understand the point.

But the point is that:
1. Forms are not the task of HTML anymore. They are the task of XForms. Why
should only HTML contain forms, but not XSL:FO, SVG, SMIL, MathML, DocBook?
So XForms will be the pluggable language to add forms to content.

2. Content-Editable as an attribute is not a good idea. The task of HTML is
to form a structural basis for hypertext. Layout properties are the task of
style sheets like CSS.

What you desire can already be done using DOM in many browsers, though not
as comfortable as in IE5.0+.
But simply adding content-editable as a CSS property won't solve the
problem. How does one tell that marked text shall be marked-up using
<strong/>? So there's the requirement for DOM anyway.

XForms might, in combination with DOM, do in the future what you desire.

I suggest that you write a detailed example of what you desire with an
indepth documentation containing a deep explanation (like that's the form...
these are the possibilities the user shall have... that's a possible
result...), especially stating that current forms have a fixed structure
like a record in a relational database and that you desire forms having a
dynamic structure, forms, that evolve on the client depending on the user's
actions.

I think it's not so much the point that you want editable HTML pages. That's
just one idea how to use that feature. Another idea would be a HTML form for
editing DocBook or MathML.
The XForm usually is given a Schema describing the result of the form. XForm
user agents could use that Schema to allow the user to construct any
structure that follows that Schema. If the user agent knows the name space
of the Schema, it could do WYSIWYG, if possible, otherwise it should display
structural markup.
Is that an idea?

> But your point about using CSS sound interesting. I guess I will ask them
> about it :)
>
> thanks,
> -Rob
Greetings

Christian Hujer
Received on Tuesday, 8 January 2002 10:55:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:50 GMT