W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

[editing] CommandQuery Object and Event

From: Ben Peters <Ben.Peters@microsoft.com>
Date: Wed, 4 Jun 2014 18:31:06 +0000
To: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <e5f022e57f5e4872ade230073a8026a1@BLUPR03MB437.namprd03.prod.outlook.com>
There has been some conversation about browser UI for Commands with ContentEdtiable=minimal. Some people seem to believe that UI should not be displayed because it may not be relevant. One way to solve this is to have an event that would allow script to tell the browser what is relevant. Today, there are several ways to ask the browser if a given command is enabled/relevant. This includes queryCommandEnabled, queryCommandSupported, and QueryCommandValue. However, the site is not able to influence the return value of these events. In order to give more power to browsers, frameworks, and sites, it seems to make sense to allow these values to be modified. Therefore I propose a new method:


which returns a new read-only object (called CommandQuery for now):

	Boolean isSupportedByUA;
	Boolean isSupported;
	Boolean isEnabled;
	Object currentValue;

By default, this object will match the browser's support for this command in the current context. However, before it returns, a CommandQuery event will fire with a read/write CommandQuery object. If a framework or site wishes to indicate different values for the command state, it can do so in that event.

CommandQueryEvent: Event {
	CommandQuery commandQuery;

In this way, a framework can enable commands that a browser does not natively support. Further, a browser could fire CommandQueryEvents to determine the correct toolbar buttons to display. Thoughts?

Received on Wednesday, 4 June 2014 18:31:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC