Re: several messages about contentEditable, text selection, and related subjects

Executive summary: Nothing too drastic, just some incremental changes to 
the contentEditable section to fix a number of issues. See revisions r1349 
to r1372.

On Tue, 22 Feb 2005, Roman Ivanov wrote:
> 
> I think that web developers really need a standard on working with 
> selection in textarea and input type=text fields.
> 
> Now there's no standard that describes how to get starting point of 
> selection, ending point of selection, and cursor position. Also there's 
> no standard that describes how to set selection and cursor position.

Does this section do what you need?:

   http://www.whatwg.org/specs/web-apps/current-work/#selection


On Tue, 22 Feb 2005, Olav Junker Kjær wrote:
> Roman Ivanov wrote:
> >
> > I think that web developers really need a standard on working with 
> > selection in textarea and input type=text fields.
> 
> Yes, that would be nice.
> It has been discussed before:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-August/001996.html
> 
> I think the best way would be if the value attribute of an input field 
> could be treated as if it were text content of the element. Then the DOM 
> Range spec (perhaps with some extensions) would cover how selections are 
> treated.
> 
> Also, this would make editing input and textarea elements consistent 
> with contentEditable, where the contents of an element is made directly 
> editable.

While I agree that the consistency would be nice, it seems the currently 
provided APIs are much simpler than any API we could achieve by trying to 
make the APIs compatible.


On Wed, 23 Feb 2005, Matthew Raymond wrote:
> 
>    So you see, if we want to establish a GUI selection interface for 
> DOM/Javascript, we can use DOM Range as PART of the interface, but we 
> still have to define some way of getting the current selection and 
> setting the user selection. I'm thinking something like this:
> 
> | var myRange = document.getSelection();
> 
>    The above gets the current selection within the document. If the 
> document doesn't have a selection, it returns document.createRange(). 

   var myRanges = document.getSelection();


>    If you wish to deselect everything in the document, you could do the
> following:
> 
> | document.removeSelection();

   document.getSelection().removeAllRanges();


> Similarly, there will be a setSelection method:
> 
> | document.setSelection(myRange);

   document.getSelection().addRange(myRange);


>    If you want to select a specific element, you'd do something like this:
> 
> | var myRange = document.createRange();
> | var myElement = document.getElementById('myID');
> |
> | myRange.selectNode(myElement);
> | document.setSelection(myRange);

   document.getSelection().selectAllChildren(document.getElementById('myID'));

...or:

   var myRange = document.createRange();
   var myElement = document.getElementById('myID');
   myRange.selectNode(myElement);
   document.getSelection().addRange(myRange);

...if you want to include the element itself, not just its contents.


>    Do we need a way of maintaining multiple user selections? I don't 
> think IE supports this.

It seems important, especially for things like discontinuous cell 
selections or <select> element selections, or if we want to represent 
visual selections of logical bidi text.


>    Question: Should any element with |contentEditable| be submitted if 
> it's within a <form> and has a |name| attribute?

Making it _any_ element would lead to some interesting problems, like what 
if you split the element in half, or what if such elements already exist 
and start getting submitted... Maybe something like this, though, would be 
useful.


On Wed, 23 Feb 2005, Matthew Thomas wrote:
> >
> > | document.setSelection(myRange);
> > | document.removeSelection();
> 
> .... But those two, unfortunately, seem more likely to be abused than 
> usefully used. Annoying authors would repeatedly clear any selection in 
> a misguided attempt to prevent people from copying text, more often than 
> application authors would use those functions for legitimate purposes. 
> (Yes, you could work around this by turning off JavaScript, but that 
> would work only for the small proportion of users who understand what's 
> causing the problem.)
> 
> I know that authors can be annoying no matter what you give them (for 
> example, displaying text as graphics), but I think this would make being 
> annoying far too easy.

I've added a couple of suggestions in the spec to mitigate this. In 
practice few authors bother with this kind of thing, so it's not too bad.


On Thu, 24 Feb 2005, Olav Junker Kjær wrote:
> 
> The important thing is to have contentEditable and an interface to 
> manipulate the current selection. Then execCommand can be built on top 
> of that in script. (The execCommand interface in IE is cool though, 
> because it supports undo. Except that the undo history is cleared when 
> any DOM manipulation is done using any other method than execCommand, 
> which limits its usefulness).

An undo mechanism exists in the spec, though it has issues. What do people 
think of it?


On Wed, 23 Feb 2005, Matthew Raymond wrote:
> 
>    The Mozilla getSelection method doesn't actually return a DOM Range, 
> though, so I'm inclined to pass on it, even though we're introducing 
> window in WA1. It just strikes me as too complicated; it introduces a 
> completely new selection object, multiple ranges, et cetera...
> 
>    Then again, if you have a really good argument for it, I'm willing to 
> hear it.

Well, it's implemented, which is a big argument.


>    Perhaps we should change getSelection to getSelections and have it 
> return a collection of ranges... Hmm...

That's what it does.


On Thu, 24 Feb 2005, Olav Junker Kjær wrote:
> 
> True. The execCommand encapsulates quite a bit of complexity. The 
> problem with the IE version is that it is a black box. You cannot modify 
> how a command works, you cannot create your own commands, and if you 
> work outside of the box (and directly through the DOM), the undo history 
> (which is the killer feature) is cleared.

Well, the spec says to not remove the undo history.


> If WA1 should include execCommand, it should be a more general 
> framework, which should allow you to create your own undoable commands. 
> In the end this gets rather complicated.

I'm open to suggestions but don't really know what you mean.


> It does make sense though, to standardize the execCommand interface, 
> since lots of CMS frontends rely on contentEditable+execCommand, and 
> this is an area where IE have a stronghold, since its still the only 
> browser (as far as I know) that support contentEditable.

The spec has execCommand().


On Thu, 24 Feb 2005, Olav Junker Kjær wrote:
> 
> I think it makes most sense to have the selection be a property of the 
> viewport i.e. the window object. If we consider two frames containing 
> two different views of the same document (this is theoretically possible 
> according to the dom spec), it would seem natural to allow different 
> focus and selections in each view. (If e.g. an HTML editor allowed two 
> different wiews on the same page while editing, this would matter.)

window.getSelection() is what I have specced, but document.getSelection() 
gets the default view's selection for compat reasons.


> Btw. the DocumentFocus interface in WA1 (section 11.3) also seem to 
> assume that focus is a propery of the document rather than the viewport. 
> Again I think its more correct to have it a property of the viewport.

hasFocus is on a Document, yeah... (for compat reasons again) Hmm. Maybe 
Anne is right, and we should just drop the multiple view theory...


On Tue, 19 Apr 2005, Jerrett Taylor wrote:
>
> Something else that might be worth taking into consideration is the 
> mangling (formating?) that the editors output as.
> 
> Having similar behavrious is one thing, but if the markup output is 
> drasticly different it can be a nightmare to try to get the end result 
> displayed the same .. then you get different people editing the same 
> content with different browsers, and changing a lot more than the typo 
> they went to fix....

Yeah... I have no idea how to specify that.


On Wed, 20 Apr 2005, Anne van Kesteren wrote:
> 
> Besides your other points I think it would also be important to specify 
> the content model the element can have and the possibility to restrict 
> this content model.
> 
> For example, you could allow any element that is allowed as a child of 
> the particular element that has contentEditable set, but there should be 
> a way to exclude certain elements (and perhaps attributes) if you don't 
> want those.
> 
>  <em contentEditable="true" exclude="a em strong span">

I think it's actually a lot more complicated than that -- e.g. you might 
want to allow <a href=""> for HTTP but not javascript:, you might want to 
allow style="color: red" but not style="display: none", or you might want 
to allow <section> in <blockquote> but not outside it...

I'm not sure how to expose that.


On Wed, 20 Apr 2005, Brad Fults wrote:
>
> Although such a selection method would be convenient, I think it makes 
> more sense to specify such exceptions on the elements themselves, 
> removing the need to add a new attribute. For instance,
> 
> <div contenteditable="true">
>   <a href="#header" contenteditable="false">Header</a>
>   <a href="#footer">Footer</a>
> </div>
> 
> In this case the first link would be manipulated as an unbreakable unit 
> inside the div.

Sadly this doesn't prevent you from adding other headers.


On Wed, 20 Apr 2005, James Graham wrote:
>
> But this alone doesn't prevent the authot _inserting_ another <a> 
> element into the contenteditable <div>. Anne's solution does allow for 
> such restrictions but doesn't seem to generalise well e.g. it's not 
> clear how to prevent an attribute from being inserted on an editable 
> element or allow for realistic restrictions like "href attributes in <a> 
> elements must point to http:// resources". Given that, I'm not sure what 
> of the restrictions should be managed declaratively and what should be 
> managed via scripting, since, at some level, scripting will almost 
> certainly be needed to ensure acceptable input.

Indeed.


On Sun, 8 May 2005, Ben Meadowcroft wrote:
>
> Regarding the Editing section, at the moment only contentEditable is 
> mentioned. While this is probably the most common method, designMode 
> should also be included.

It's there now.


On Sat, 25 Jun 2005, Matthew Raymond wrote:
>
> *** |selection| attribute ***
> *** |selectable| attribute ***
> *** |selected| attribute ***

I'm not sure I really understand the problems these are solving.


On Thu, 21 Jul 2005, Anne van Kesteren wrote:
>
> <http://annevankesteren.nl/projects/whatwg/spec>
> 
> * The sections on line-break and block-break have been significantly 
> revised.

In fact, I think in that draft they are over-specified. Why does it matter 
exactly how blocks are broken, for instance?


> * Copying, pasting and cutting have been dropped from the draft.
>   (Might be added back later, but not for execCommand...)

The drag and drop covers these now.


On Mon, 1 Aug 2005, Anne van Kesteren wrote:
>
> Danial Glazman asked me to e-mail this to the list:
> 
> <glazou>   beaufour: I suppose all elements in a document edited by the
>            editor become :read-write?
> <beaufour> glazou: well, that's my best guess too... but I do not have
>            a clue about how the editor works...
> <glazou>   I think it should probably _not_ apply
> <glazou>   because otherwise editing could become hell
> <glazou>   imagine *:read-write { border: red dotted 1px }
> <glazou>   that should not apply in the editor
> <glazou>   see my point?
> 
> This should probably go to www-style eventually as well.
> 
> IMHO it makes some sense. Especially when :read-write etc. come in wide 
> use. In an editor you want to edit what you see and what will be the end 
> result, if you add :read-write you are thinking about the end result, 
> not editing environment.
> 
> See also: <https://bugzilla.mozilla.org/show_bug.cgi?id=302188#c17>

This seems reasonable to me, but is it something that HTML5 should talk 
about?


On Tue, 23 Aug 2005, Dimitri Glazkov wrote:
>
> I've been following this thread for a little while. I too think that the 
> contentEditable is not done quite right.
> 
> My biggest problem with it (and this was pointed out before) is that it 
> is a half-way effort: there is markup that enables the editing, but 
> there is no markup that provides any information about submission for 
> the edits. IMHO, this is incomplete. If you provide means for entry, it 
> shall be your responsibility to provide means for exit.

One can easily just do:

   <form onsubmit="text.value = document.getElementById('editor').innerHTML">
    <input type=hidden name="text">
    <div id=editor contentEditable></div>
    <input type=submit>
   </form>

Is that not enough?


On Sun, 28 Aug 2005, Lachlan Hunt wrote:
> > >
> > > and (b) the way it was designed is too presentationally oriented for 
> > > a semantic markup language - it basically suffers from the same 
> > > design flaws as every other WYSIWYG editor.

Note that this is mostly because the concept of a non-WYSIWYG editor that 
is usable is still pie in the sky.


> Most (if not all) WYSIWYG editors don't cleanly seperate the editing of 
> content and of presentation.  Users are able to enter text and then 
> directly speficify how that text should look, often through toolbar 
> options like font family, font size, bold, italic, underline, colour, 
> background, border, etc. If you open up any WYSIWYG editor or word 
> processor, the chances are that you'll find most of those options 
> available on one of the standard toolbars.
> 
> Although some editors do also provide some semantic options, they're 
> usually limited in their abilities.  Some have some semantic block level 
> elements like headings, paragraphs, lists and maybe blockquote. However, 
> few have semantic elements like abbr, cite, code, dfn, kbd, samp, var, q 
> and strong/em (some, like contentEditable, mistakenly use bold and 
> italic options for those).  I often have to jump through hoops just to 
> get <code> in my markup while using dreamweaver, by using the buttons 
> for <b> and/or <i> and then running search and replace to fix up the 
> markup.
> 
> Additionally, even fewer WYSIWYG editors allow authors to easily 
> categorise (or class) semantic elements easily.  As a user, I should be 
> able to, for example, mark up a note by first selecting a paragraph and 
> then saying that it belongs in the "note" class.  I know of no way to do 
> so with contentEditable and I haven't found an easy way to do so with an 
> editor like dreamweaver, short of editing the markup directly.

All this isn't a limitation of contentEditable, it's a limitation of the 
state of the art. In fact, contentEditable lets you implement what you 
want, and, as specified today, strongly discourages what you describe as 
bad. I'm not sure what more we can do.


> For example: Adding a new element around content should be done somewhat 
> like this:
> 
> var selection = ... // Assume this is set to the Range selected by the
>                     // user
> selection.surroundContents(document.createElement("code"));

Right, you can do that. You don't have to use execCommand().


> That's far more extensible than using the execCommand() method, which 
> requires the commandIdentifier to be know for each element it an insert, 
> and for which there is no command I know of for adding a code element. 
> If DOMRange were used, then contentEditable may become usable for 
> non-HTML languages and even with new elements added to HTML.  Correct me 
> if I'm wrong, but I don't believe it can be used for that, the way it's 
> been designed and implemented.

I don't see why not.


On Mon, 29 Aug 2005, Matthew Raymond wrote:
> >>
> >>So, effectively, what you're saying about <textarea 
> >>accept="text/html"> is the following:
> >>
> >>1) The HTML in a <textarea> is unstyled (at least unstyled by the 
> >>parent document) unless styles or stylesheets are specified within the 
> >><textarea> contents.
> > 
> > There is no defined rendering for <textarea>. The UA would be 
> > perfectly within its rights to interpret the contents of such an 
> > element and style it using the styles of the containing document.
> 
>    The trouble is that if you don't have a DOM, CSS really doesn't make 
> a lot of sense. For instance, "textarea p" is illogical because the <p> 
> element isn't actually a child of the <textarea> because the control can 
> only have a text node as its child.

So create a separate DOM document. :-)


> >>2) There is no way to use the DOM to manipulate the contents of the 
> >><textarea> without using a proprietary UA interface.
> > 
> > Sure, you could do something like:
> > 
> >    my DOM = document.createElement('div');
> >    DOM.innerHTML = textarea.value;
> >    // ...manipulate DOM...
> >    textarea.value = DOM.innerHTML;
> > 
> > ...or some such.
> 
>    Sure you could, but WHY?!! It's not a functional improvement over
> your previous example:
> 
> | <form onsubmit="d.value = firstChild.innerHTML" ...>
> |   <div contentEditable> ... </div>
> |   <input name="d" type="hidden">
> |   <input type="submit" ...>
> | </form>

What more do we need?


>    Granted, the <textarea> still allows you to reset the control, but 
> you need CSS to hide the the <div>.

You don't have to put the DIV in the document.


> You also need extra parsing and serialization steps every time you 
> manipulate the HTML inside the <textarea>. There's also issues of 
> managing the current text selection that I don't think you've addressed.

The text selection could be managed relatively easily (just save it 
before and put it back after). It's not clear to me exactly what problem 
we're trying to solve here, though.


> >>The simple fact of the matter is that, with the version of HTML5 you 
> >>currently propose, there is no way to submit HTML in the DOM without 
> >>scripting.
> > 
> > That is certainly true, yes. I'm not sure why this is a problem, 
> > though.
> 
>    You mean other than the fact that the author has to know Javascript 
> just to have a rich text control? And while we're at it, let's remember 
> that they need scripting for resets, read-only and disabled 
> functionality, maxlength and any other form control-related feature.

But why is that a problem? It's not like it's that much script, and they 
don't need to implement the bits they don't need (e.g. read only, 
disabled, maxlength, etc), and the bits they'll need are more than likely 
going to be far more complex than anything we can provide declaratively 
(e.g. content model restrictions).


> > The scripting is simple, and would only be an [insignificant] part of 
> > the actual scripting involved in writing an editing UI using 
> > contentEditable.
> 
>    Once you get beyond the most basic level of editing support, that's 
> no longer the case. For instance, you may need to write script to save 
> the editing area at load time and to restore once someone hits a reset 
> button. You need special CSS to handled "disabled" and "enabled" states 
> because an <div> with |contenteditable| won't match :disabled or 
> :enabled. For a "read-only" state, you have to make the value of 
> .contentEditable and the presentation of the <div> match the read state 
> of the <input type="hidden"> element you're using to submit. And what 
> about |required|? I thought it was created for the very purpose of 
> reducing the amount of script needed.

Sure, but all that pales in comparison to the amount of script that you 
would need just for things like providing buttons for marking up 
semantics, doing semantic styling, etc.


>    The bottom line is that in order to simulate an <htmlarea>-like 
> control you need massive amounts of Javascript and specialized CSS, and 
> it all turns into a static, unsubmittable block of HTML if you try to 
> use it with a legacy browser. Remember that you'd have to put the entire 
> serialized contents of the <div> into the |value| attribute of the 
> <input type="hidden"> element _in_the_markup_ in order to simply submit 
> the default contents when Javascript is turned off or unavailable.

You could certainly default to a textarea with HTML editing, and have that 
be turned into a live editor using script.


>    Generally, there are five things that would make up an ideal HTML 
> editing control:
> 
> 1) Supports the "parent" document's CSS for the control contents.
> 2) Supports access via DOM.
> 3) Supports |readonly| and |disabled|.
> 4) Supports reset with the serialized initial contents as the default.
> 5) No scripting necessary.
> 
>    According to you, <textarea accept="text/html"> takes care of 1, 3 
> and 5, with 4 somewhat covered as well. That's pretty close, but it's 
> not enough. We can never really make DOM work for <textarea> contents 
> because there are too many complications. An element with 
> |contenteditable| doesn't really work either, because it only really 
> matches the first two items in the list.
> 
>    Perhaps the best idea is to keep <textarea accept="text/html"> and 
> |contenteditable| in with their existing limitations and introduce an 
> official <htmlarea> form control element. This element would have the 
> following properties:
> 
> 1) It would allow any HTML contents you can put in an <div> or <span>.
> 2) You could style it as easily as a <div> or <span>.
> 3) Because the contents are in the DOM, CSS works as expected.
> 4) It would have all the <textarea> attributes (save |rows| and |cols|).
> 5) The DOM property .defaultValue would be a serialization of the
>    initial <htmlarea> contents.
> 6) The DOM property .value could be a serialization of the current
>    <htmlarea> contents. (Pretty much the same as innerHTML.)
> 7) Resetting the form restores the innerHTML of the control to
>    defaultValue.

...and you would need script to enforce custom content models, to change 
the UI to provide custom buttons (e.g. "signature" buttons like on wikis), 
and to make it work in legacy UAs. At which point, why not just take the 
things that already exist, and use them together with a bit of script glue 
to get the same effect?


On Mon, 29 Aug 2005, Matthew Raymond wrote:
> > 
> > Right but there's nothing to stop a UA creating a DOM from the text in 
> > the textarea and making this avaliable in some 
> > implementation-dependent way.
> 
>    Yes there is: XHTML. Legacy XHTML user agents will treat the document 
> as invalid.

I don't understand.


On Mon, 29 Aug 2005, Hallvord Reiar Michaelsen Steen wrote:
> 
> > contentEditable needs scripting anyway, to offer things like "insert 
> > <em> element here", etc.
> 
> Why must contentEditable depend on scripting? What if we make sure the 
> wording of the spec allows non-scripting implementations?

Well, you don't have to have scripting, but in practice people want to 
provide custom UIs, since each site has its own specific needs.


> For example, nothing should prevent the UA from making its own toolbar 
> available with formatting commands (whether those are FONT or STRONG is 
> an entirely different debate), or supporting common editing shortcuts 
> (like Word's Ctrl-B for Bold text) when in editing mode. If the 
> contentEditable element can also act as a form control, we have a 
> perfectly fine basic option for authors who aren't interested in a 
> complex, full editor with lots of buttons.

We have that now, with one extra line of script. I don't think one line of 
script is a big problem.


> > Well, you can do that now:
> > <form action="" method="post"
> >       onsubmit="savedata.value = firstChild.innerHTML"
> >   ><div contentEditable="true"></div><input name="savedata" 
> > type="hidden"> </form>
> 
> My question is whether we could make contentEditable more useful for 
> HTML/CMS authors by removing scripting requirements. I'm not against a 
> scripting dependency per se, I just thought it would be a very nice 
> option for a small-scale CMS to just add a FORM tag and contenteditable 
> + form attributes instead of having to find and implement a big JS 
> library for an editor.

I don't think the extra benefit is that huge. I think in practice finding 
a JS library would be easy enough. There are too many edge cases to have 
to deal with if we try to get UAs to implement this natively, IMHO.


On Tue, 30 Aug 2005, Matthew Raymond wrote:
>
>    There are implementations of <htmlarea>-style controls that use 
> |contenteditable|. I find it hard to believe that such a control would 
> be hard to implement using an HTC (or at least no harder than other 
> things, like a date picker). Most of the problems associated with 
> <htmlarea> are identical to those for either <textarea accept> or 
> |contenteditable|, so once the former two are worked out, the latter is 
> quite easy to implement. Is a simple, straight-forward rich editing 
> control too much to ask for?

Given how much trouble we've had getting a simple non-submtting 
contentEditable framework, probably yes! :-)


On Mon, 29 Aug 2005, Lachlan Hunt wrote:
> Ian Hickson wrote:
> > On Wed, 24 Aug 2005, Lachlan Hunt wrote:
> > > contentEditiable is not semantic, it's behavioural and belongs in the DOM
> > > interface only, not the markup.
> > 
> > How is it not semantic?
> 
> How is it semantic?

It means "this section can be edited". That's a meaning, a semantic. It's 
doesn't say how the user agent should expose this.


> > It's not behavioural...
> 
> It's behavioual because it specifies how content should be entered by 
> the user (i.e. using a WYSIWYG editor) rather than just what kind of 
> content is expected and leaving the editing/input methods up to the UA. 
> It also (currently) requires scripts to be used at all, and scripts are 
> behavioural.

It isn't required that the editing be WYSIWYG, heck, it's not even 
required that the editing be visual.


On Sat, 10 Sep 2005, Jorgen Horstink wrote:
>> 
> Why don't we introduce a for-attribute to bind the content of an editing 
> host to a form field?

That could work (though I'd be tempted to make the association go the 
other way, i.e. have the input control of type=hidden have an attribute 
editing-host= that takes the ID of the editing host, or some such).

But does it really gain us much over the one line of script?


On Sat, 10 Sep 2005 whatwg@jorgenhorstink.nl wrote:
>
> contentEditable - block breaks (enter)
> 
> A few weeks ago I was working with Anne van Kesteren on the 
> contentEditable behaviour of Internet Explorer. I noticed IE does not 
> behave correctly to my mind when it comes to block breaks (pressing the 
> enter key).
> 
> So I was wondering; how should block break behaviour work? I have 
> written a small document on block break behaviour and I was wondering 
> whether or not this is valuable for the WA spec.
> 
> http://jorgenhorstink.nl/projects/whatwg/blockbreak.htm
> 
> The document is not even nearly complete, but I want to start the 
> discussion about contentEditable and block breaks.

The question is do we really want to specify this? What benefit is there? 
The spec already requires that the output not be non-conforming.


On Mon, 27 Feb 2006, Maciej Stachowiak wrote:
> On Feb 27, 2006, at 4:34 PM, Jonas Sicking wrote:
> > Maciej Stachowiak wrote:
> > > I would like copy/paste integration to be on the agenda. I believe these
> > > operations can be offered securely (and implemented in various nonstandard
> > > ways by IE, Firefox and in some cases Safari):
> > > 1) copy
> > > 2) cut (in an editable context)
> > > 3) event on copy that lets you prevent the default action and substitute
> > > other content
> > > 4) event on paste that lets you prevent the default action and substitite
> > > other content
> > 
> > An issue with 1-3 is that a site could stop the user from copying 
> > content off the site. We already see a similar thing happening where 
> > sites cancel the rightclick event to prevent users from doing "view 
> > source".
> > 
> > A site could use the copy-event in 3 to always replace the copied 
> > contents with an empty string (or a string containing some copyright 
> > statement). Or the site could on every key-press and mouse-click 
> > cut/copy an empty string to the clipboard.
> 
> I think this is only an issue with #3 (unless you think sites will spin 
> in a loop doing a copy on an empty selection, I think this is unlikely). 
> However, IE already has these features. Perhaps we can come up with 
> something compatible that doesn't make it possible to totally lock out 
> the user. Or perhaps the copy end is not as important as the paste end 
> for substituting custom content. Maybe it is enough to just allow adding 
> extra clipboard types, and not overriding of standard ones.

Do the current features in the spec address this need enough?


On Mon, 20 Mar 2006, Henri Sivonen wrote:
> 
> 5.1.1.
> I think the spec should suggest shift-return as the key combo for 
> inserting a line separator to make it even more clear that plain return 
> should break the block.

Done.


> 5.1.1.
> "(Updating the default* DOM attributes causes content attributs to be updated
> as well.)"
> 
> attributes

Couldn't find that typo.


On Thu, 6 Apr 2006, Maciej Stachowiak wrote:
> 
>         boolean execCommand(in DOMString command,
>                             in boolean userInterface,
>                             in DOMString value);
>         boolean queryCommandEnabled(in DOMString command);
>         boolean queryCommandIndeterm(in DOMString command);
>         boolean queryCommandState(in DOMString command);
>         boolean queryCommandSupported(in DOMString command);
>         DOMString queryCommandValue(in DOMString command);

I've tried to specify these.


On Tue, 9 May 2006, Jorgen Horstink wrote:
>
> �The contenteditable attribute is a common attribute. User agents must 
> support this attribute on all HTML elements.�
> 
> How about del? It sounds odd to me to allow content of a del element to 
> be editable.

It's odd, but if we don't allow it, how do you mark something as deleted 
and then unmark it when you realise you marked the wrong bit?


> Second, I am interested why User Editing actions are mostly 
> UA-dependent. To my mind there should be one standard for editing. It is 
> very frustrating if applications behave differently in different 
> browsers.

Frustrating to whom, and why?


> I'd suggest at least to rephrase the 'break block' and 'insert a line 
> seperator' sections. Whenever a user requests a break (block break or 
> inline break) the behaviour should depend on the state the editing is 
> in. It is stupid to insert two inline breaks (is it really? I guess so). 
> I.E.
> 
> <p>
> foo
> <br>
> <br>
> foo
> </p>
> 
> Above example does not make sense. Because of this fact, inserting 
> 'block breaks' and 'inline breaks' can be invoked with one and the same 
> action (pressing the enter key, talking to the browser whatever).
> 
> If the last action was not a break request, an 'inline break' will be 
> inserted. If the last action was a break request, a block break will be 
> inserted.
> 
> The pipe represents the carret in the examples below:
> 
> <p>
> foo|
> </p>
> 
> After requesting a break, an inline break will be inserted:
> 
> <p>
> foo<br>|
> </p>
> 
> After requesting another break, an block break will be inserted. Note the last
> BR will be removed.
> 
> <p>
> foo
> </p>
> <p>
> |
> </p>
> 
> I hope the idea of this algorithm is clear. I was wondering whether it 
> has potential to be added to the spec (there are quite a lot edge cases 
> though).

I don't see why we'd want to specify this. It seems like something that 
browser vendors can legitimately compete on (having the most reliable and 
useful editor), and it doesn't affect interoperability really, only 
usability.

In particular, given the very immature state of the art in this field, we 
don't want to constrain implementations from finding better ways to 
express these actions. For instance, maybe pressing "enter" once should 
create a new <p> straight away, instead of starting with a line break. 
Maybe it should behave differently in lists than in paragraphs. Etc.


On Mon, 29 May 2006, Cow wrote:
> 
> I was wondering whether the WhatWG have thought about having a 
> standardized rich text editor tag, like a rich text version of 
> <textarea> ( I hope you guys don't mind "feature requests"). At the 
> moment a lot of scripts such as TinyMCE take a textarea, hides it using 
> CSS, creates an iframe with contenteditable, then copies the contents of 
> the iframe back into the textarea for submission. Scripts like TinyMCE 
> can also be about 150KB.

It seems that 150KB is probably doing a lot more than just providing a 
basic editor!


> Instead of providing a very low level API such as contenteditable, a new 
> form control for rich text editing could:
> 
> * Be more accessible to those without Javascript and have standardized 
> keyboard shortcuts to perform tasks

Browsers can provide common shortcuts to all contentEditable hosts. I 
agree that contentEditable doesn't work well without script, but it seems 
like you'd likely want to have script anyway to do things like check on 
content models (e.g. disallowing <script> from being inserted).


> * Provide a standardized rich text editor for developers and users which 
> is familiar and easy to implement

Not sure what you mean here.


> * No hacks

Well, specifying something doesn't guarentee that hacks won't be needed to 
get around bugs.


> * Right Click > Edit in [ Dreamweaver, Nvu, MS Word...]

That's already something browsers could implement with contentEditable.


> * Browser preferences could allow someone to always edit in rich text, 
> HTML, XHTML, etc.

It seems like the server would want to control the submission format, not 
the user.


> * Allow browser features such as spell check to continue to work.

Those can already be provided.


> IMO at the moment rich text editing on the web is not very web-like - a 
> web developer can't roll their own WYSIWYG very easily, there are 
> browser issues and there are all kinds of different hacks, licenses and 
> bugs in different implementations of WYSIWYG. This could be a great 
> opportunity to standardize and improve the editing interfaces in 
> blogs/CMS.

The browser issues and hacks and bugs aren't going to be fixed by adding 
more features.


On Tue, 30 May 2006, Matthew Raymond wrote:
>
> three different use cases:
> 
> 1) Simple WYSIWYG editing. For this, I support using an <htmlarea> 
> element.
> 
> 2) Advanced text-based editing and/or editing with HTML 4.01 fallback. 
> For this, <textarea accept> is the best solution. (Note that the 
> |accept| attribute will allow you to use non-HTML formats such as 
> BBCode.)
> 
> 3) Wiki-style editing where you can change everything in the page. The 
> |contenteditable| attribute is best in this situation.

I don't really understand the scenarios for these three use cases (except 
the 'wiki' case). It would be interesting to have a more detailed study of 
what people need editing for.


On Wed, 12 Jul 2006, Anne van Kesteren wrote:
> 
> Sure, but this behavior actually makes sense to me. It's just an error 
> handling rule for when the value is not the empty string (to allow <div 
> contenteditable>, true, or false)... In other words, it makes:
> 
>   <div contenteditable><p></div>
> 
> ... equivalent to:
> 
>   <div contenteditable><p contenteditable=x-test></div>
> 
> ... which doesn't seem that bad. This doesn't change how 
> contentEditable, isContentEditable or anything would work.

Fixed.


On Thu, 13 Jul 2006, Peter Van der Beken wrote:
> 
> "User agents must allow users to move the caret to any position within 
> an editing host, even into nested editable elements."
> 
> Does "nested editable elements" include nested editing hosts? I'm 
> assuming not, otherwise there's an inconsistency when starting the caret 
> move from the inner editing host vs when starting the caret move from 
> the outer editing host.

How so?


> "User agents must allow users to change the selection within an editing 
> host, even into nested editable elements."
> 
> Same question as above, does "nested editable elements" include nested 
> editing hosts?

I've added a note that says that selections crossing from editable to 
non-editable elements are not a requirement.


> Also, how does that interact with non-editable elements? Given the 
> following:
> 
> <div contenteditable="true">
> abc
> <span contenteditable=false">def</span>
> <span contenteditable="true">ghi</span>
> </div>
> 
> If the user starts selecting from before the a to after the i, is def 
> selected?

Yes.


> And if the user deletes the selection, does that remove the first span 
> too?

Sure.

I've tried to clarify these a bit.


On Mon, 8 Jan 2007, Simon Pieters wrote:
> 
> The contenteditable spec says:
> 
>   Insert, and wrap text in, semantic elements
> 
>      UAs should offer a way for the user to mark text as
>      having stress emphasis and as being important, and
>      may offer the user the ability to mark text and blocks
>      with other semantics.
> 
> I think it is no surprise that most UAs will implement this as emitting 
> <em> for CTRL+I and <stong> for CTRL+B, or similar interfaces that imply 
> that the user actually requested italics or bold with (to the UA) 
> unknown intended semantics. (IE and Opera emit <em> and <strong>, Safari 
> emits <SPAN class="Apple-style-span" style="font-weight: bold;">.) I 
> think <i> and <b> should be emitted instead, and the above text should 
> reflect that.

I've tried to suggest that.


On Tue, 9 Jan 2007, Henri Sivonen wrote:
> 
> Two of the four implementations that the WHATWG cares about 
> interoperate. Is it worthwhile to disrupt that situation�especially 
> considering that changes to Trident are the hardest for the WHATWG to 
> induce?

The cost of trying seems to be near nothing in this case.


> I think using span with a style attribute is a bad idea in this case.

I agree. I'm not quite sure how to make it non-conforming though.


> P.S. I don�t believe semantic markup to be axiomatically better than 
> presentational markup. Semantic markup shouldn�t be an end in itself. 
> When semantic markup doesn't serve a useful end, such as media 
> independence or particularly useful data mining, in *practice*, there is 
> no point.

The purpose here is making content usefully reusable in other media (e.g. 
speech), though of course if the user doesn't give the UA enough 
information to distinguish stress from keywords from importance from a 
mood change, there's no much we can do.


On Tue, 9 Jan 2007, Benjamin Hawkes-Lewis wrote:
> 
> An actual test would have been to provide people with a widespread 
> interface that accurately reported that they were emphasizing rather 
> than italicizing.

Unfortunately, nobody has demonstrated that it is possible to do this in a 
usable way.


> There are consequences to using <i> and <b> instead of <em> and 
> <strong>. Being ambiguous, <i> and <b> are insufficient hooks for speech 
> CSS styling by the author, at least not without additional classes.)

Yeah.... theoretically I guess. :-)


> Because they are so ambiguous, talking UAs will have to announce those 
> elements as "italic" and "bold" rather than applying any specific aural 
> styling such as a different rate or pitch of speech.  Because 
> announcements slow down reading speed much more than voice alterations, 
> it is likely that talking agent users will turn them off. Which means 
> their web experience will be ultimately degraded.

I think in practice speech UAs almost certainly default em and i to 
identical styling.


On Wed, 10 Jan 2007, fantasai wrote:
> 
> That depends, actually, on the language. Browsing the Chinese journal 
> section of a university East Asian Library, I noticed that the Chinese 
> journals didn't use normal/italics -- instead they switched the style of 
> font between their equivalents of serif and cursive. Granted these 
> switches were on a per-paragraph level in the text I saw, but East Asian 
> typesetting tends not to use italics in general. They have other means 
> of indicating emphasis: various underlining styles, bold, (in Japanese) 
> a switch to katakana, and "emphasis marks" which are placed 
> above/below/beside individual characters in an emphasized phrase. East 
> Asian texts also don't use italics for works titles: they have a set of 
> special punctuation for that. You can argue that italics and bold should 
> be strictly equivalent to em and strong because all that matters is that 
> their presentation is the same, but that argument doesn't hold up for 
> non-Latin texts. Restyling <em> sitewide to use 'text-emphasis' instead 
> of 'font-style: italic' would be a nifty thing on a Japanese website. 
> Restyling <i> the same way would just be silly.

It sounds like styling <i> with a different font-family would make sense 
given the definition of <i> and what you say above.


On Wed, 10 Jan 2007 mail@jorgenhorstink.nl wrote:
>
> The question is, what logic lies beneath the typical bold button? I've 
> been developing a lot of wysiwyg tools and analyzed a lot of them. 
> Almost every tool I have seen just uses the bold execCommand;
> 
> execCommand('bold', false, null);
> 
> So the question is, what should this command return? As the name of the 
> command states, a request is made to make the selection bold. So use a 
> <b> element! I suggest to extend the Command Identifier List to also 
> allow 'important' and 'emphasis'. The latter should use a <em> element 
> and the former the <strong> element.
> 
> execCommand('important', false, null);
> execCommand('emphasis', false, null);
> 
> Now we have defined the right purpose of the specific command 
> identifiers, it is up to the author of the WYSIWYG tool to decide which 
> command to use. An author who knows about semantics and has read this 
> discussion would use the bold command for the bold button and the italic 
> command for the italic button.
> 
> To emphasize text of to make text important, extra buttons or menu items 
> should be used. The way the traditional bold and italic buttons are 
> being used should not be altered. That would be inconsistent.

I've added 'bold' and 'italic'. I don't want to add new commands yet, 
we're still trying to get the existing ones implemented right.



On Wed, 10 Jan 2007, Nicholas Shanks wrote:
>
> Having come in to this conversation half way, I'd like to give my 
> opinions. In the following 'default style' means in the UAs style 
> declarations for all documents of the language.
> 
> There should be three emphasis elements:
> 
> <em> Increases emphatic semantics by one level. *No* default rendering 
> style for visual media, default rendering for other media not specified.
> 
> <i> Equivalent semantics to <em>. Default rendering style for visual 
> media is a language-dependant alternative glyph set of the same font 
> family and weight (e.g. italic/курсив, oblique, カタカナ). 
> Default rendering style for other media not specified (at least the same 
> as <em>).
> 
> <b> Equivalent semantics to <em>. Default rendering style for visual 
> media is the same font family and glyph collection, but higher weight. 
> Default rendering style for other media not specified (at least the same 
> as <em>, perhaps louder for aural).
> 
> The <strong> element is deprecated, replaced by nested levels of <em> or 
> it's visual-specific variants.
> 
> Thus where visual presentation is important, <i> and <b> can be used 
> semantically (they are equivalent) and <em> ignored. Where visual 
> presentation is not important, <em> can be used without concern for what 
> <i> should sound like. The basic point is that <em> has no default 
> rendering style, discouraging it's misuse for "i want italic text and 
> people tell me <i> is bad these days, so i'll use <em>".

I think the current distinct semantics for the four elements is a better 
solution.


(Snipped a huge discussion on <b> and <i> and so forth, which didn't 
really add anything new, and which predates our current solution with 
those elements.)


On Wed, 10 Jan 2007, Simon Pieters wrote:
> 
> However as it is now the spec sort of contradicts itself -- it says 
> <strong> must only be used to denote importance yet the contenteditable 
> "bold" feature will emit <strong>.

Fixed.


On Fri, 19 Jan 2007, Anne van Kesteren wrote:
>
> [re contentEditable] The following would match Internet Explorer (and 
> Opera's current implementation):
> 
>  - The empty string
>  - "true" (case-insensitive match)
>    -> Content of the element is editable.
> 
>  - "false" (case-insensitive match)
>    -> Content of the element is *not* editable.
> 
>  - Any other value
>    -> Equivalent to not specifying the attribute.
> 
> This is based on some tests I made last year 
> http://dump.testsuite.org/2006/contenteditable/ to find out what we had 
> to do in Opera.

Done.


> I think it would also be a good idea to add the isContentEditable DOM 
> attribute to HTMLElement as it needs to be supported for compatibility 
> and it allows you to find out whether or not an element is editable when 
> the contenteditable attribute is not directly specified on it (but on an 
> ancestor element).

On Fri, 19 Jan 2007, Jorgen Horstink wrote:
>
> I second Anne's opinion about a new attribute isContentEditable. Both 
> Internet Explorer and Safari have implemented this already although 
> Safari's support for inherit has a few bugs. It really is needed for 
> compatibility.

Added.


On Wed, 21 Feb 2007, Dave Raggett wrote:
> 
> I am organizing a workshop on declarative models of distributed web 
> applications (June 5-6, Dublin, Ireland) with the goal of bringing 
> people together to discuss the modeling, security and usability aspects 
> of future authoring frameworks. Some details can be found here:
> 
>   http://www.w3.org/2006/10/uwa-charter.html#workshops

Did anything come of this that could be used to improve HTML?


> Getting back to HTML5, I am interested in a clean way to set an editing 
> caret within a document's markup, and independent of the existing 
> designMode/contentEditable/execCommand features. In my work I am using a 
> span element for the caret and manipulating it via the DOM. That works 
> pretty well modulo browser variations for where they break lines. It 
> would be good to have fine control of that too, e.g. to prevent line 
> breaking within words (except after hyphens) and before or after span 
> elements except when adjacent to whitespace.
> 
> The designMode/execCommand features in IE and copied by other browsers 
> are much to much oriented towards very simple word processing (e.g. 
> wordpad) and a poor match to the needs for editing structured documents. 
> Furthermore the markup generated varies considerably across browsers, 
> though this can be cleaned up to some extent via post processing. HTML5 
> should include support for editing, but I would strong recomend against 
> standardizing designMode and execCommand in their current form.

Could you elaborate on what contentEditable does that you don't like?


On Wed, 25 Apr 2007, David Hyatt wrote:
> 
> I like the idea of having a way of associating a file upload control 
> with a contenteditable region and I also like the idea of having some 
> way for the dropped resources associated with the control to display in 
> the page.  The use case of being able to drop images into a 
> contenteditable region and have them show up as <img> elements at the 
> appropriate place and then get automatically uploaded somewhere is a 
> really compelling one.

Yes, that would be interesting indeed. Some of this may fall out of future 
work on "blobs" similar to what Gears is doing and in line with what 
Firefox has implemented recently, but any specific suggestions would be 
welcome too. How would you see implementing this?


On Mon, 11 Jun 2007, Anne van Kesteren wrote:
> 
> There is one problem with the text though. That is that when the 
> attribute has an invalid value it should be treated the same as if the 
> attribute was not set at all. This means for instance that:
> 
>   <div contenteditable>
>     <div contenteditable=foobar>
>       This will be editable.
> 
> I think I already made a comment regarding that on the WHATWG mailing 
> list...

Yes... twice even. :-)


On Thu, 6 Sep 2007, Simon Pieters wrote:
> 
> The spec says about designMode:
> 
>    Enabling designMode causes scripts in general to be disabled and the
>    document to become editable.
> 
>    When the Document has designMode enabled, event listeners registered on
>    the document or any elements owned by the document must do nothing.
> 
> Shouldn't the first paragraph be phrased as a requirement, as in 
> "scripts that are in the document must not be executed"?

The requirement is in the scripting section, I believe.


> The second paragraph doesn't match what Firefox does. This is how it 
> works in Firefox, AFAICT:
> 
> When you set designMode="on" on a document, all event listeners that 
> were registered on the document with addEventListener() with a script 
> that was itself in the same document must be ignored. Additionally, all 
> event listeners that were registered using onXXX="" attributes in the 
> markup, as well as .onXXX DOM attributes, must be ignored, regardless of 
> where they came from.
> 
> This is required because editing apps still want to be able to listen to 
> events in the document for e.g. context menus.

Fixed.


On Tue, 9 Oct 2007, Mihai Sucan wrote:
> 
> 1. In the fourth paragraph of section 5.2. there's an error:
> 
> "Otherwise, either the HTML element has a contenteditable attribute set 
> to the false state, or its nearest ancestor with the contenteditable 
> attribute set is not editable, or it has no ancestor with the 
> contenteditable attribute set and the Document itself has designMode 
> disabled, *and the element is thus not editable*."
> 
> I think there's something missing "and the element is ... thus not 
> editable". Or maybe that should be only "then the element is not 
> editable".
> 
> I don't know for sure what was the initial intent.

Fixed.


> 2. In the fifth paragraph of the same section, the "true" and "false" 
> values only have the left quote, without the right quote mark.

Fixed.


> 3. In section 5.2.1. "User editing actions" [2]:
> 
> The "move the caret" and "change the selection" action definitions 
> mention the "mouseydown" event. That should actually be the "mousedown" 
> event.

This seems to have gotten fixed.


> 4. In the same section 5.2.1, the last paragraph: the Enter key is 
> marked-up with two <kbd> nested tags - should only be one <kbd>.

Actually HTML5 defines one of them as meaning "type the word "Enter"" and 
two of them as meaning hit the key Enter.


> 5. In section 5.2.2. "Making entire documents editable" [3], the second 
> paragraph, first phrase:
> 
> "The designMode DOM attribute on the Document object *takes takes* two 
> values, "on" and "off". "
> 
> Eliminate the duplication: "takes takes".

Fixed.


> 6. How does a script determine the exact caret position? By "exact" I 
> mean: in which element node, at which character position within the 
> element is it?

It appears that there's no way to do this right now using the API defined 
in the spec for the selection of text with contentEditable. We could add 
something, though... What do implementors think?


> Also, I certainly dislike the current selectionStart/selectionEnd 
> solutions for finding the caret position. The reason is simple: they are 
> just unreliable solutions within the limits of today's APIs. "We cannot 
> get the caret position, but we have the selection, and I can use it to 
> get the caret position in IE and Firefox - that is enough for me."

Yeah... the advantage is that it is implemented in at least one browser...


> 7. There's absolutely no mention about cut/copy/paste. The WYSIWYG 
> editing capability is one of the most important use-cases for 
> cut/copy/paste-related APIs in the "Drag and Drop" section [5].

The drag and drop sections now has stuff for copy/paste.


> Section 5.2 should detail a bit how it relates to the "copy and paste" 
> section [6] of the DND API.

Not sure what you want here.


> 8. There's no mention of how editable content behaves in regards to 
> context menus.

It doesn't behave any differently than anything else.


> Can we have a context menu associated with an editing host? Can we use 
> the contextmenu attribute on elements within an editing host?

Yes.


> How do we check on which node the user right-clicked within the editing 
> host? This is needed for context-aware menus.

I've added a note in the spec about this. We need to have this available.


> When the user right-clicks within an editing host, does the 
> "contextmenu" event fire and bubbles-up on the specific node within the 
> editing host? If yes, then the authors can create contextmenus with an 
> event listener on the editing host, which checks where the event 
> started. Thus, creating menu items as needed.

Yes, we should support this. I've added an issue marker to this effect.


> 9. The spec does not define what happens to the editing hosts and child 
> nodes, with regards to event listeners and scripts. Can child nodes have 
> event listeners? designMode is defined such that child nodes, nor the 
> document itself, can have any event listeners, nor any scripts running,

As specced, nothing special happens to event listeners with 
contentEditable (they continue working).


> Also, it's generally undefined what happens with CSS :hover, :focus, 
> :checked, and other "state-aware" pseudo-classes.

Nothing special happens per spec right now... What should happen?


> 10. Here's a scenario:
> 
> a) One loads a complex Web application;
> b) One enables designMode on the entire document;
> c) One does many changes, to fields, to various data, which would normally
> have event handlers, which would do various things, including, but not limited
> to, retrieving data from the server, or disallowing certain input values, etc.
> d) One disables designMode. What happens now? The user played like "God" and
> altered the state of the entire application, creating, possibly, even
> security-related issues.
> 
> The application is not notified that designMode will be enabled/disabled.
> 
> Will the scripts continue to run in the application? Or all scripts are 
> forever stopped, even after disabling designMode? Will event listeners 
> still be valid for the nodes which remained in the document, without 
> being removed during editing?

The exact same thing happens as if the document's tree was mutated via 
Firefox's DOM Inspector or equivalent, or if a script from another page 
went in and made all these changes itself.


> Based on some concerns raised by this scenario, I suggest defining that 
> the "designMode" event fires at the document before it's enabled, and 
> after it's disabled, such that scripts can "know" this has happend. The 
> event must not be cancelable.

Well, a script has to trigger designMode in the first place. So, that 
script can notify the page as desired.


> Similarly, a "contenteditable" event (bubble true, cancel false) should 
> fire at the element node for which contenteditable is enabled/disabled.

Same with this.


> Use case: a banking site, a Web mail application, or some other Web
> application where security is critical, could have a script which can disallow
> such (malicious) user behavior

No, it couldn't. The client is always in control, and could do whatever it 
wanted to the page without the page knowing. This has been possible ever 
since javascript: URIs were invented, and is extremely possible today with 
debugging tools.


> 11. Another scenario:
> 
> a) The user loads a page with a script which sets contenteditable to true for
> one node.
> b) Then the running function inserts a <script> into the node.
> c) Then contenteditable is set to false.
> 
> Does the <script> ever execute? If yes, when?

It executes when it is inserted. The spec defines this currently.


> What if the <script> has a src attribute, thus trying to load an 
> external script?
> 
> What about <style tags? and <link rel=stylesheet>?

The spec defines all this. contentEditable doesn't affect it.


> 1. My internal WYSIWYG editor (Awebitor) is not full-fledged like 
> others, yet it makes use of commands which are not in the spec.
> 
> a) The "createlink" command which encloses the selection within an 
> anchor with the href attribute having the given value.
> 
> Use case: for "create a link" buttons within the editor UI. Otherwise, 
> the author has to use the 'inserthtml' command with some manually 
> generated code, prone to errors.

Added.


> b) The "unlink" command which removes all the links in the selection.
> 
> Use case: similar to the above. This is more desirable than writing our 
> own code which parses the DOM, or parses the source code as a string.

Added.


> c) The "removeformat" command which removes all the formating of a 
> selection. This actually removes style attributes, bold, italics, 
> underline, align left/center/right/justify and some more. Proper testing 
> needs to be done to determine the precise behavior. I can do it, if this 
> command is to be added to the spec.
> 
> The command is quite useful in many cases when editing a document. It 
> would be quite much work, prone to errors, for authors to write their 
> own implementations.

Should removeformat remove things like 'em' and 'strong' and 'cite' and 
'var' and 'b' and 'i' and 'span' and 'a'?


> d) The "bold", "italic", "underline", and "strikethrough" commands are 
> also left undefined.

I've added bold and italic. The other two map to elements that aren't in 
HTML5, so I haven't included them.


> e) The "forecolor" and "hilitecolor" commands left undefined. The former 
> changes the text color, and the latter changes the background color, of 
> the selection - based on the provided value argument.
> 
> f) The "fontname", "fontsize", "justifyleft", "justifycenter", 
> "justifyright", and "justifyfull", [...] "indent", and "outdent" 
> commands are also undefined.

It's not clear to me what these should map to. They are dependent on how 
we solve the style="" attribute issue. I've left a note in there about 
these for now.


> ... "insertorderedlist", "insertunorderedlist" ...

Added.


> g) The "formatblock" should also allow "div", and all the values should 
> not be case sensitive.

Added.


> h) The "heading" command should be defined as well. The value provided 
> can be h1, h2, h3, h4, h5, or h6. This is used for inserting headings in 
> the document, as needed.
> j) A rather important command for me, is the "inserthtml" command, which 
> works like innerHTML on the entire selection - or as "insert HTML at the 
> caret position" (if no selection is available). Even if "innerHTML 
> sucks", I would say this is quite useful.

I've not added these, since IE don't support them. I agree it would make 
sense to add them later, though. (insertHTML would need changes to the 
parser section too, though.)


> i) The "insertimage" command - value being the URI/IRI of the image src 
> attribute.

Added.


> 2. Based on experience and testing, commandId should be defined as 
> case-insensitive.

Fixed.


> 3. Regarding the "unselect" command:
> 
> "Big Issue: We need some sort of way in which the user can make a 
> selection without risk of script clobbering it."
> 
> Suggestion: why not limit the number of consecutive "unselect" commands? 
> Say a bad script tries to automatically unselect anything more than 3 
> times. The fourth time ... the command does nothing. Automatic 
> protection against "unselect" abuse.

Added something vaguely like this.


> 4. The doShowUI argument has a weird name. Doesn't "showUI" sound 
> better?

Changed.



On Fri, 19 Oct 2007, Simon Pieters wrote:
> 
> For compat with existing implementations, the commandId parameter of
> execCommand() should be ASCII case insensitive.
> 
>    http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cbody%20contenteditable%3Dtrue%3E%3Cp%3Ex%3C%2Fp%3E%3Cscript%3Ewindow.onload%3Dfunction(){document.execCommand(%22selectall%22%2Cnull%2C%22%22)%3Bdocument.execCommand(%22superSCRIPT%22%2Cnull%2C%22%22)}%3C%2Fscript%3E
> 
>    http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cbody%20contenteditable%3Dtrue%3E%3Cp%3Ex%3C%2Fp%3E%3Cscript%3Ewindow.onload%3Dfunction(){document.execCommand(%22selectall%22%2Cnull%2C%22%22)%3Bdocument.execCommand(%22superscr%C4%B1pt%22%2Cnull%2C%22%22)}%3C%2Fscript%3E
> 
>    http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cbody%20contenteditable%3Dtrue%3E%3Cp%3Ex%3C%2Fp%3E%3Cscript%3Ewindow.onload%3Dfunction(){document.execCommand(%22selectall%22%2Cnull%2C%22%22)%3Bdocument.execCommand(%22superscr%C4%B0pt%22%2Cnull%2C%22%22)}%3C%2Fscript%3E

Fixed.


> For the formatblock command, the value parameter is Unicode case insensitive
> in IE, and ASCII case insensitive in Firefox, Safari and Opera. I don't have
> an opinion on whom to follow but it certainly shouldn't be case *sensitive*.
> 
>    http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cbody%20contenteditable%3Dtrue%3E%3Cp%3Ex%3C%2Fp%3E%3Cscript%3Ewindow.onload%3Dfunction(){document.execCommand(%22selectall%22%2Cnull%2C%22%22)%3Bdocument.execCommand(%22formatblock%22%2Cnull%2C%22%3Caddre%C3%9F%3E%22)}%3C%2Fscript%3E

Fixed.


> The values can also be specified without the < and > in IE, Safari and 
> Opera.
>
>    http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cbody%20contenteditable%3Dtrue%3E%3Cp%3Ex%3C%2Fp%3E%3Cscript%3Ewindow.onload%3Dfunction(){document.execCommand(%22selectall%22%2Cnull%2C%22%22)%3Bdocument.execCommand(%22formatblock%22%2Cnull%2C%22address%22)}%3C%2Fscript%3E

Fixed.


> Also, in IE and Opera, the formatblock command is not restricted to editing
> hosts only.
> 
>    http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cp%3Ex%3C%2Fp%3E%3Cscript%3Edocument.execCommand(%22selectall%22%2Cnull%2C%22%22)%3Bdocument.execCommand(%22formatblock%22%2Cnull%2C%22%3Caddress%3E%22)%3C%2Fscript%3E

I couldn't reproduce this in IE8 (and my Opera for some reason just 
spins).


On Fri, 19 Oct 2007, Simon Pieters wrote:
> 
> Hmm, for IE, it seems this was only true for "address".

I've allowed it for everything so far. Should I change that?


On Fri, 19 Oct 2007, Thomas Broyer wrote:
> 
> With IE 7.0.6000.16546 on Windows Vista, it isn't even true for 
> "address".

Odd.


On Wed, 31 Oct 2007, Mikko Rantalainen wrote:
> 
> 5.6.2. APIs for the text field selections
> http://www.whatwg.org/specs/web-apps/current-work/#textFieldSelection
> 
> These features are enough to identify the selected data and possibly 
> modify the contents of text field by scripting so that the modification 
> is affected by selected region.
> 
> There're some problems, though. I represent the following use case:
> 
> A page contains a textarea. Author adds an additional button for adding 
> a pair of parenthesis around the selected text. The javascript code for 
> this feature (given that "e" is the text field element) is
> 
> e.value = e.value.substr(0,e.selectionStart) + "(" +
> e.value.substr(e.selectionStart,e.selectionEnd) + ")" +
> e.value.substr(e.selectionEnd);
> 
> The problems with the above code:
> 
> 1) From the UA view, the entire contents of the field has been replaced 
> with a new value and therefore the undo feature of the field cannot 
> represent the fact that the script only added character "(" before the 
> selection and character ")" after the selection. A method to update only 
> the selected part of the value would be needed to correctly describe the 
> real change to the value to the UA.
>
> For the issue 1) I suggest adding a new method
>  replaceSelectionText(in string selection_value)
> which replaces the section of field's value between offsets
> selectionStart and selectionEnd with the string selection_value. This
> replacement should not destroy the text field's undo history - instead
> it should be treated similarly to paste (text) operation.

You can do this by remembering where the selection is and just resetting 
it afterwards, though, no?


> 2) There's no good way to set the selection because if the scripts calls
>  setSelectionRange() the UA "must set the selection of the text field" 
> but it is not required to modify the focus or scrolled part of the text 
> field in any way. In addition, there's no way to query the scroll 
> position of the selection so the script cannot work around this issue 
> either. As a result, setSelectionRange() may be used to set the 
> selection but the selected selection may end up being out of the view 
> from the user point of view. As textarea element may have soft wrapping 
> enabled, the script has no way to even compute the correct line number 
> for the selection start.
>
> For the issue 2) I suggest changing the behavior of setSelectionRange() 
> to require that the selection must be made visible to the user. Perhaps 
> something along the lines "UA must scroll the text field so that the 
> start of the selection is visible." As an alternative, a method such as 
> void focusSelection() could be added so that the script may hint the UA 
> that the selection should be made visible after the script has called 
> setSelectionRange() and replaceSelectionText() multiple times (so that 
> these actions do not repeatedly scroll the text field's viewport).

Isn't this the user agent's problem? It seems like a good user agent would 
focus the part of the selection that was selected before, in this kind of 
scenario. Isn't this something that should always happen?


On Mon, 12 Nov 2007, Daniel Glazman wrote:
> 
> But that's really a 1998 thing being finally put into the standard, not 
> a 2007 solution. I think the interactions between designMode and 
> contenteditable values have to be better documented and have to be 
> extended. In particular, I would like to have the possibility to have 
> the following
> 
>    <html designMode="on">
>      ..
>      <p contenteditable="false">bla</p>
>      ..
>    </html>
> 
> In such a document, a visual browser would disable content editing in 
> the paragraph holding contenteditable="false".

That's what the spec currently requires.


> I would also be able to specify an element is not removable, I already 
> sent a message about it in the early days of the what-wg IIRC.

I've made a note to add this to v2.


-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'