RE: ? what to do ?

Hello Robert,

> -----Original Message-----
> Hello again :)
> 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)
To drop in something new: How is the browser supposed to keep the result
valid? How does the browser forbid to add a <h1/>-child to a <p/>-Node? The
browser would be required to have much better XML capabilities (which I'd,
of course, welcome).


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

It is bad to define something in a standard which that standard is not meant
for.

It is bad to define layout properties in HTML (if you follow the development
of XHTML, you see, they get removed step by step - goodbye <font/>, goodbye
<basefont/>, goodbye <body bgcolor/>, goodbye <table bgcolor/>...).
HTML is for defining the structure of a hypertext page. I currently don't
see why making a region editable should be part of hypertext markup. An
editable region only makes sense when the result is sent back to the server,
which then requires some server interaction via HTTP POST or HTTP PUT. So
this belongs to XForms.

Attributes in HTML are not the problem. The purpose, the semantics are the
problem. And editable content is beyond the scope of HTML. At least in my
eyes. (The XHTML working group might of course see this different and when
they do so, they will have very good arguments against me ;)


The purpose of CSS is to define the layout of elements. A contentEditable
property might belong to CSS, as the task of CSS widens anyway, see the
drafts to CSS, they include behaviour properties, for instance. But, I agree
with you, contentEditable as such is not a layout task.

> > 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
Well, then just HTML4 is missing and it would be complete. And before I'd
use it, I'd wait for a version with less security holes, that runs on LinuX
without Wine or VMWare.
Yes, IE is not a HTML4, it doesn't support <q/> and some other elements. And
the <link/> element is, except for rel="Stylesheet", completely ignored.

Well, it's a point of discussion wether Mozilla or Netscape 6.x may be
considered real world browsers, but they support DOM1 and CSS1 as well as
most of DOM2 and CSS2 - more than IE 6.

Opera does not support DOM1 completely yet, all DOM methods modifying the
DOM Tree are not supported yet.

I will check out Konqueror's DOM capabilities in just a few minutes.

I tested it using the following code:
<html>
	<head>
		<title>DOMTest</title>
		<script type="text/javascript">
			function doIt() {
				newEl=document.createElement("s");
				h1El=document.getElementById("bla");
				text=document.createTextNode("hello");
				newEl.appendChild(text);
				h1El.appendChild(newEl);
				return true;
			}
		</script>
	</head>
	<body>
		<h1>DOMTest</h1>
		<h1 id="bla">Test</h1>
		<span onclick="doIt();">click me!</span>
	</body>
</html>


> > > > 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...
That's definitely untrue.
IE 6 still does not support HTML 4.

Greetings

Christian

Received on Wednesday, 9 January 2002 07:19:30 UTC