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 <[email protected]> wrote: > On Thu, Nov 24, 2011 at 9:32 AM, Ian Hickson <[email protected]> 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 > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
