- From: Jim Ley <jim.ley@gmail.com>
- Date: Tue, 30 Aug 2005 10:29:13 +0100
On 8/29/05, Matthew Raymond <mattraymond at earthlink.net> wrote: > By the way, I think Hallvord's asking for giving the UA vendors > flexibility in what tools are available for HTML editing in a document, > not asking for anything to be mandatory. Vendors are likely to implement > what they feel is useful for the users anyway. Sure, but I'm saying they're not useful for the use cases of contentEditable as it is used today, we've seen lots of people asking what are the use cases for contentEditable, and I'm not completely sure everyone is actually looking at if their proposals meet them. contentEditable is not used for authoring of full pages, it's used for simple authoring - wiki like markup for people who can't do wiki-markup basically. I've seen very few outside email apps that don't limit what can be achieved. > Servers must validate all input, regardless of whether or not it came > from a form control. Validating the semantic appropriateness of mark-up is not computationally feasible, however it's not possible to have a link or an image semantically invalid, they are what they are. This is the difference, limiting what the user can create in their contentEditable is important to maintain semantic appropriateness. For ensuring only elements and tags you want are in the CMS, that's fine, but rejecting it, it will not be possible to give a meaningful answer of why the edit failed to user of a wysiwyg control - "you used a blockquote, please resend without a blockquote" - If a user's done nothing but gone, give me a left margin in his editor, he'll not have a clue on how to fix that or WTF a blockquote is. > It would be nice to be able to explicitly define what markup can be > used in a |contenteditable| element. Any suggestions how that can be > defined? It might be nice, but I can't see how a user agent could really achieve such a thing, what's it going to do change its edit bar for every user, that would lose any consistency that would be gained by providing it in browser. I think a rich textarea is a good idea, I just see it as distinct from contentEditable - something with existing implementations and uses. Jim.
Received on Tuesday, 30 August 2005 02:29:13 UTC