I'll describe a use case first, since I think it answers some of your
questions.
Consider a CMS with a browser-based editing interface. For ease of use,
it is designed so that pages in "edit mode" looks as much like the
public site as possible. Different people are allowed to edit different
parts
Note: In the context of this email, I'm using the theoretical
attribute |usehtml| as a trigger for converting a standard text-based
to one that supports HTML content.
Olav Junker Kjær wrote:
> Lachlan Hunt wrote:
>>How is that any different from a text area form control with a specified
>>acc
I'm pretty sure Safari 2.x does support contentEditable the exact same
way win/ie does.
-c
> Certainly the IE implementation (which is the only non-beta
> implementation i know of) has its issues, but I dont see how its
> "conceptually broken". Its very useful, despite its shortcomings.
>
> rega
Lachlan Hunt wrote:
How is that any different from a text area form control with a specified
accept type of text/html, which would allow a UA to load any external
editor (eg. XStandard) or degrade to a regular text area?
The point of contentEditable is that some areas of a page can be made
ed
Quoting Lachlan Hunt <[EMAIL PROTECTED]>:
Could you be more specific? It basically enables WYSIWYG editing for
web pages.
(With the freedom that you can restrict certain elements from being
edited, et
cetera.)
How is that any different from a text area form control with a
specified accept ty
Anne van Kesteren wrote:
Quoting dolphinling <[EMAIL PROTECTED]>:
Perhaps I've missed something, but while I've seen lots on what
contentEditable does and how it works and how various other things are
associated with it, I've never actually seen anything explaining *why*
it exists. So... what'
