- From: Robert Koberg <rob@koberg.com>
- Date: Tue, 8 Jan 2002 12:45:17 -0800
- 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 UTC