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

Wed Apr 18 09:31:14 PDT 2012

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

--- Comment #21 from Alexey Proskuryakov <ap at webkit.org>  2012-04-18 09:31:14 PST ---
> But it's also bad that if an author writes document.execCommand("insertHoriznotalRule") it will silently fail and it will possibly take them a long time to figure out what's wrong.

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.

> This is not how the web platform works.

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!

I think that the latest proposal (specify silent failure for legacy IE verbs) accurately describes what engines would do anyway if we move forward with raising the exceptions. However, there is non-trivial cognitive and implementation burden - a seemingly random set of verbs will behave differently than others.

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.)

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