RE: ? what to do ?

Hello Robert,

> -----Original Message-----
> Thanks for taking the time to respond!
>
> >From: "Christian Wolfgang Hujer" <Christian.Hujer@itcqis.com>
>
> > 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.
>
> I am not saying they shouldn't. Maybe what I am talking about shouldn't be
> considered a form.
I think it would be a great win for forms if we'd consider it as a form.
This would give forms a new dimension and great new power.

> > 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.
>
> How does contentEditable affect the layout? The point of it is
> NOT to affect the layout.
To be efficient, in my eyes, it must affect the layout - how else can the
user see which regions are editable and which are not? But that's of course
not the point wether it does belong to CSS or doesn't.
Perhaps CSS is just as bad a place for a contentEditable property as HTML
is.

As far as I see on the CSS3 Roadmap, forms are out of the scope of current
CSS3 development, probably because they have to wait for XForms 1.0 to
become quite mature.

> > What you desire can already be done using DOM in many browsers,
> though not
> > as comfortable as in IE5.0+.
> I don't see how this is possible in any browser other than IE5.5+
Simply modify the document using DOM via ECMAScript.
use Document.createElement() to create an element, use Element.appendChild()
to append an element...
But I don't know from my mind how far DOM Level 1 Core is implemented
properly in browsers.

> > 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.
> >
> good point. it would make the markup a mess. I am back to believing it
> should be an attribute.
Maybe it might be an attribute, but it must not be a HTML attribute, it is
out of the scope of HTML. Maybe an XForms attribute, like this:
<h2 xforms:contentEditable="true">Heading</h2>
And I think it is, at least in the near future, a good idea to request
support of that attribute in all user agents. But HTML as such is designed
for a wide variety of user agents, from small handies over PCs up to
mainframes.
This would give XForms a new dimension of interoperability. It would be
really great to see such a kind of improvement in XForms. But there still is
an unclear point: How to allow the user to add new elements like <strong/>
or <code/> to the result tree? Though I think that point should be easily to
clarify.


> > 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 will do this. I have some spare time between Macworld sessions
> :) Is there
> some information on how you guys like to see this examples like this? I am
> basically a hack and need all the help I can get with my communications.
I think just read some recommendations and notes and adopt their style.
And don't be too specific to your current problem, show a wide range of
usage possibilities.

> > 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.
>
> Yes, exactly. I use XSLT to transform a docbook-like (basically a mix of
> docbook and XHTML) XML structure to my specific HTML layout. I
> let the user
> edit the page similar to how they would work in MSWord.  Since the HTML is
> well-known to me I can 'round-trip' it back to XML for storage on
> a server.
> The XML can then be transformed to the clients prorietary markup (pure
> docbook perhaps) or used as is.
>
> > 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?
>
> I can't accept using forms to enter article content.

I think you didn't understand what I meant. Please read it again, especially
"WYSIWYG" :)
This would mean that a user agent that understands the HTML and XForm
namespaces can, given a HTML Schema, allow the user to edit valid HTML in a
WYSIWYG environment much comparable to a WYSIWYG text processor.

Please tell me if it's still unclear.


Greetings

Christian

Received on Tuesday, 8 January 2002 14:09:53 UTC