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

[Ryosuke Niwa]

I don't think we should implement the API as spec'ed today. e.g. Mozilla
doesn't want to implement it either as far as I know.

- Ryosuke

On Thu, Apr 19, 2012 at 4:34 PM, Eric Seidel <eric at webkit.org> wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120419/b0a1d8be/attachment.html>