[whatwg] [editing] HTML Editing APIs specification ready for implementer feedback

Thanks for working on this. Much appreciated!

A few things so far:

At the end of section 4, there's:

> the state of insertOrderedList and insertOrderedList might be true both  
> before and after calling

Is one of those supposed to be insertUnorderedList?

At the beginning of section 5, there's:

> An editing host is a node that is either an Element with a  
> contenteditable attribute set to the true state, or the Element child of  
> a Document whose designMode is enabled.

What does "Element child" refer to specifically in the latter? Is it the  
HTML body element or is that implementation-specific?

Still in section 5:

> A collapsed line break is a br that begins a line box which has nothing  
> else in it, and therefore has zero height.
>
> An extraneous line break is a br that has no visual effect, in that  
> removing it from the DOM would not change layout, except that a br that  
> is the sole child of an li is not extraneous.
>Is this a good definition at all?

Don't really have much opinion on the names or the definition.

Which one refers to a <br> that acts like a placeholder for a line (so the  
line is selectable) where the <br> disappears once the user starts editing  
that line or closes the paragraph?

At the end of section 5:

> When the user agent is instructed to run a particular method, it must  
> follow the steps defined for that method in the appropriate  
> specification, not act as though the method had actually been called  
> from JavaScript. In particular, if the author has overridden the method  
> with a custom method, the standard method must be run rather than the  
> custom one.

Is this saying that doing something like:

HTMLDocument.prototype.execCommand = function(a, b, c) {
     // stuff
};

, will have no effect or should throw an error or something?

If so, is this just matching what browsers do now or just something you  
think is a good thing to prevent?

In section 6.1 with:

> To set the tag name of an Element element to new name:
>
> 1. If element is an HTML element with local name equal to new name,  
> return element.
>
> 2. If element's parent is null, return element.
>
> 3. Let replacement element be the result of calling createElement(new  
> name) on the ownerDocument of element.
>
> 4. Insert replacement element into element's parent immediately before  
> element.
>
> 5. Copy all attributes of element to replacement element, in order.
>
> 6. While element has children, append the first child of element as the  
> last child of replacement element, preserving ranges.
>
> 7. Remove element from its parent.
>
> 8. Return replacement element.

I pretty much translate that as:

var replacementElement = document.createElement("differentTagName");
parent.insertBefore(replacementElement, element);
for (var i = 0; i < element.attributes.length; ++i) {
     replacementElement.setAttribute(element.attributes[i].name,  
element.attributes[i].value);
}
while (element.hasChildNodes()) {
     replacementElement.appendChild(element.removeChild(element.lastChild));
}
parent.removeChild(element);

That seems to be removing attributes and nodes from one element and  
appending them to another while they're both being displayed in the parent.

Do you intend for that to be strictly done like that or is doing it a  
different way (like copying to the replacementElement in the DOM and then  
doing a replace) allowed as long as it gives the same end result? Or, will  
that mess up the range preservation?

-- 
Michael

Received on Thursday, 28 July 2011 04:06:25 UTC