- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Tue, 30 Aug 2005 05:33:59 -0400
Hallvord Reiar Michaelsen Steen wrote: >>Whilst I agree the concept of contentEditable is not good, I don't >>think it should be solved by trying to modify the existing behaviour >>the accept="text/html" is a much better way of meeting your use case. > > If it gets implemented in a WYSIWYG form... > We have already discussed back and forth on whether using a TEXTAREA > is better, and I think we all agree that neither approach is really > good. Saying that contentEditable elements can become part of a form > will give us the best parts from each of the worlds IMO. I don't. You're talking about making every HTML element a potential form control. This is just plain confusing for the developer, not to mention hard to implement and technically complex. If I have a form element with |contenteditable|, can it have a |form| attribute? Can elements with both |contenteditable| and |form| also have |readonly| and |disabled| attributes? I think you're opening a real can of worms here. Personally, I like the following idea better: 1) Keep |contenteditable| (with some additional definition of behavior), and position it for use in situations where you'll be dynamically editing the entire document. Might be ideal for certain AJAX applications. 2) Keep <textarea accept="text/html"> as-is, and suggest that it be used in backwards compatibility situations and for when you might want an enhanced editing control for hand-coded HTML. 3) Create a new <htmlarea> element (which I have defined elsewhere), that embodies the closest thing to an ideal HTML-based form control. Best for situations where you have a fixed parent element that you want to submit in most situations.
Received on Tuesday, 30 August 2005 02:33:59 UTC