[webkit-dev] New feature: Implement command API in webkit

[Eric Seidel]

It appears no consensus was reached?  The patch is still up for review:
https://bugs.webkit.org/show_bug.cgi?id=72955

On Thu, Nov 24, 2011 at 11:34 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> On Thu, Nov 24, 2011 at 9:32 AM, Ian Hickson <ian at hixie.ch> wrote:
>>
>> On Thu, 24 Nov 2011, Ryosuke Niwa wrote:
>> >
>> > For example, the current design doesn't allow a single command be
>> > associated with multiple UI components such as toolbar, pane, and
>> > context menu because a command is defined at wherever UI component that
>> > triggers the command.
>> >
>> > However, in practice, many web apps share the same command state across
>> > multiple UI widgets such as toolbars and context menu. Take, "bold"
>> > command as an example. "bold" command can be disabled or checked (i.e.
>> > the selected text is in bold) and this state needs to shared across many
>> > UI elements.
>>
>> Correct, though that is only a temporary limitation. I avoided adding this
>> because I figured adding too much at once would cause implementors to
>> avoid it. I'm happy to add it already if that is what it takes to get it
>> implemented. :-) The idea is to add a command="" attribute which takes an
>> ID and would then make the element defer to the element with that ID, so
>> that you only need define the command once and then refer to it from the
>> various places in the UI where you want to refer to it.
>
>
> (At this point, we should probably move this discussion to public-html or
> whatwg but I'll post it here for the sake of consistency)
>
> That's an interesting idea. When Erik, Alex, and I were talking about this,
> we thought each command can have a name and command content attribute can
> refer to that.
>
> One thing I really want to do is to tie command's name space with that of
> execCommand since they already have useful functions like queryCommandState,
> and queryCommandValue.
>
> One big problem I have with the current design is that when a command can
> take multiple values like foreColor, "checked" state doesn't make much
> sense. In fact, we probably just need a generic "command value" that can
> be coerced into boolean as needed (i.e. what queryCommandValue returns for
> editing commands). Once we have that, whether a radiobox or checkbox is
> checked or not can be determined by whether command value matches the value
> or is boolean equivalent to true.
>
> So I don't think command state should include checked.
>
>> > I also don't think UA should auto-generate toolbars as most of web apps
>> > want to have a fine-grained control over the look and feel of their
>> > toolbars.
>>
>> Agreed with the fine-grained control issue. I figured we would do that
>> using pseudo-elements and component decorators, but I haven't specced
>> anything out yet because those aren't ready yet.
>
>
> I'm very skeptical that any author, especially those building web apps,
> would start using menu + command if decorating them was harder than it is
> today. I'd think that authors much rather keep command an abstract concept,
> and define toolbars themselves.
>
> Another big problem with the current design is modularity. We've got to make
> sure any commands defined in a widget will not interfere (i.e. should be
> unavailable or disabled, or even overridden by page's commands) with the
> rest of the page.
>
> - Ryosuke
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>