[whatwg] [editing] queryCommand(Indeterm|State|Value) for commands where they make no sense

Aryeh Gregor ayg at aryeh.name
Thu Sep 15 13:39:15 PDT 2011

I'm still using the whatwg list, because discussion on whether using
public-webapps is okay is (of course) still ongoing:


What should the correct behavior be in the following cases?

* queryCommand*("insertimage").  Neither state, value, nor indeterm
make sense for insertImage.
* queryCommandState("fontname").  Value and indeterm make sense, but
state does not.
* queryCommandValue("bold").  State and indeterm make sense, but value does not.

Browsers behave as follows:

* queryCommand*("insertimage"): IE10PP2 and Chrome 15 dev return
boolean false for all three (even value, it seems).  Firefox 8.0a2
throws NS_ERROR_FAILURE for indeterm and state, and returns "" for
value.  Opera 11.50 returns boolean false for state and "" for value
(it doesn't support indeterm at all).
* queryCommandState("fontname"): IE10PP2, Chrome 15 dev, and Opera
11.50 return false.  Firefox 8.0a2 throws NS_ERROR_FAILURE.
* queryCommandValue("bold"): IE9 returns the same as the state:
boolean true or false (not strings).  Firefox 8.0a2 and Opera 11.50
return the empty string.  Chrome 15 dev returns the state cast to a
string, so either "true" or "false".  (Actually, I think I caught
Opera 11.50 returning boolean false in one case, but I'm not sure what
triggered it.)

So there are two related questions here:

1) What should the value be for commands where only state really makes
sense, like bold or italic?  IE returns the state as a boolean, WebKit
returns the state cast to a string, and Gecko/Opera return the empty
string always.

I think WebKit is clearly wrong here.  "true" and "false" are just
going to be confusing -- authors will say things like if
(document.queryCommandValue("bold")) and be confused when it always is
true.  When they alert() the values, it will look like booleans.  If
the value is going to correspond to the state, it should evaluate to
the same thing when cast to a boolean.

IE is also unreasonable, because it returns booleans.  It makes more
sense for queryCommandValue() to have a fixed return type, namely
string.  IE's behavior doesn't really gain anything anyway, since it
just duplicates the functionality of queryCommandState().

That leaves the Gecko/Opera behavior.  I don't like it much -- it
means that calling queryCommandValue("bold") just does nothing useful,
so it indicates a bug in the author's code.  It would make the most
sense to throw an exception.  But that might not be web-compatible,
since no one does it.  Does anyone want to try and find out?  The spec
currently says to throw in this case, but it's a compat break that
might not be justifiable.

So my current thought here is to throw an exception if we think the
compat risk is acceptable, and failing that always return an empty
string.  Thoughts?  (The spec currently requires throwing an

2) What should happen for indeterm, state, and value for commands
where they make no sense?  IE, Chrome and Opera all return a fixed
dummy value for all three (well, except Opera doesn't support
indeterm).  Gecko throws for indeterm and state, but returns the empty
string for value.

As with value, I think throwing makes the most sense.  If we throw for
(1), we should definitely throw here.  If we return an empty string
for (1), then I'd say we should return an empty string for value, and
false for indeterm/state, for consistency's sake.  Again, thoughts?
(I don't think returning boolean false for value is worthwhile, since
returning the empty string is a more consistent return type and
behaves practically the same.)

I think the exception-throwing behavior is preferable in principle,
but for compat, I suspect the right behavior is to always return
boolean false for state and indeterm, and "" for value.  This
basically matches everyone but Gecko for commands where none of them
make sense, and matches Gecko/Opera for the value of commands where
only state makes sense.  Throwing doesn't match anyone except Gecko,
and then only in some cases.  If others agree, I'll change the spec
and tests accordingly.

More information about the whatwg mailing list