[Webkit-unassigned] [Bug 83993] Unsupported commands in execCommand/queryCommand* should throw except queryCommandSupported

Thu Apr 19 00:56:12 PDT 2012

https://bugs.webkit.org/show_bug.cgi?id=83993

--- Comment #22 from Aryeh Gregor <ayg at aryeh.name>  2012-04-19 00:56:12 PST ---
(In reply to comment #21)
> I think that this argument is a generic one, subject to opinion. Web technologies in general don't make it easy to catch mistakes early. If we wanted to change this, we'd obsolete HTML for XML, because small typing errors can result in subtle and hard to catch problems with document structure.
> 
> I think that developer community has spoken very clearly that this is not what they want.

XML is horrible because a) it has obscure corner-cases that are fatal errors even though they probably signal nothing wrong, like inclusion of invalid code-points; b) there's no way to isolate the errors so that they don't break the page; c) the content is commonly user-controlled (involving user-submitted content) and so it's hard to verify the input.

By contrast, running an unsupported command definitely signals that the page is not going to act as expected; you can easily stop such errors from breaking the page by using try/catch; and the author normally has full control over which commands are run, with no user input involved (usually just hard-coded strings).

> My idea of "how the platform works" comes more from what CSSStyleDeclaration.setProperty does. Making element.style.setProperty("-webkit-foo", "bar") raise an exception would clearly be a bad idea!

On the other hand, most DOM methods throw if given invalid input, such as: insertBefore, appendChild, replaceChild, removeChild, querySelector(All), splitText, (substring|insert|delete|replace)Data, (extract|clone)Contents, insertNode, surroundContents, isPointInRange, comparePoint, . . .

In some of these cases, it will throw even in cases where a browser just doesn't support the new feature.  querySelector() will throw if the selector is unsupported, but we introduce new selectors regularly.

I will grant that the platform is not entirely consistent about this, or anything.  :)

> How desirable adding new execCommand verbs is? Could we get away of only adding reasonably ignorable new ones, and implementing other APIs in different ways? I don't really think that this should be an API of choice for everything editing related - if nothing else, double dispatch makes performance worse. Where it makes good sense is commands that have state (can only paste if there is something on clipboard etc.)

execCommand() is a horrible API in all sorts of ways, but it's the way that all current editing features are implemented.  If we introduced some new system, we'd have to support all the (useful) existing commands in the new system, which gives two ways of doing the same thing and complicates the platform even more.  So unfortunately, I don't think this is feasible unless there are really compelling advantages to the new API.  And yes, we do want to introduce new commands that aren't reasonably ignorable -- e.g., fontSizePt <https://www.w3.org/Bugs/Public/show_bug.cgi?id=14253>.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.