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

Re: ? what to do ?

From: Robert Koberg <rob@koberg.com>
Date: Tue, 8 Jan 2002 12:45:17 -0800
Message-ID: <17f401c19885$63275940$6501a8c0@TILLER>
To: "Christian Wolfgang Hujer" <Christian.Hujer@itcqis.com>, <www-html@w3.org>
Hello again :)

> From: "Christian Wolfgang Hujer" <Christian.Hujer@itcqis.com>
> > -----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?

that is up to the tool/page developer to deliver a usable gui, but it
doesn't have anything to do with contentEditable. The only thing it does is
enable editing for that tag (not block element like I said before)

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

I don't understand why it is bad.  Can you explain why?Are attributes in
HTML the problem?  I just don't see how the contentEditable affects layout.
You can set the tag to have a background color (maybe on click or mouseOver)
but that is a css thing not the attribute.


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

IE6 is the only "real world" browser that suppoorts DOM1 and CSS1

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

No, that did it :) and that would work for me. It seems MSIE team adopts the
standards faster than the other browsers so I guess they would eventually
wind up on the same page. Until that day I can get the user agent and send
them what they need...

thanks,
-Rob
Received on Tuesday, 8 January 2002 15:48:31 GMT

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