On Jun 9, 2014, at 4:21 PM, Piotr Koszuliński
wrote:
> Responding to browser UI is one thing and I totally agree with the need for
> user intent events. If user shakes iPhone editor should be notified that user
> wanted to undo. But I does not tie this to commands at this point at all.
> Even
Responding to browser UI is one thing and I totally agree with the need for
user intent events. If user shakes iPhone editor should be notified that
user wanted to undo. But I does not tie this to commands at this point at
all. Events exist to notify app that something is going to happen. The
defau
Is it just browser UI that leads you to want to start over? The goal of
CommandEvents is to allow sites/frameworks to work with browser UI, whether
toolbars like Safari or gestures or speech or accessibility tools or whatever
else in the future. I understand that browser UI can be a problem toda
On Fri, Jun 6, 2014 at 6:39 PM, Ryosuke Niwa wrote:
> On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński
> wrote:
> > 1. That we need any native UI related to cE at all.
> > We don't. We can display our own toolbars, with our own buttons, with
> our own icons and implementing our own logic. So the ea
On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński
wrote:
> 1. That we need any native UI related to cE at all.
> We don't. We can display our own toolbars, with our own buttons, with our own
> icons and implementing our own logic. So the easiest solution to the problem
> with irrelevant native UI i
On Jun 6, 2014, at 7:30 AM, Robin Berjon wrote:
> On 06/06/2014 13:29 , Piotr Koszuliński wrote:
>> 1. That we need any native UI related to cE at all.
>> We don't. We can display our own toolbars, with our own buttons, with
>> our own icons and implementing our own logic. So the easiest solutio
On 06/06/2014 13:29 , Piotr Koszuliński wrote:
1. That we need any native UI related to cE at all.
We don't. We can display our own toolbars, with our own buttons, with
our own icons and implementing our own logic. So the easiest solution to
the problem with irrelevant native UI is to not display
On Fri, Jun 6, 2014 at 1:29 PM, Piotr Koszuliński <
p.koszulin...@cksource.com> wrote:
>
> TL;DR
> 1. Let's drop execCommand and queryCommandState. They have no real value
> for developers and clearly conflict with cE=minimal. JavaScript frameworks
> will be created which will allow implementing t
On Wed, Jun 4, 2014 at 8:31 PM, Ben Peters wrote:
> 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.
I think that it was me talking about mobile Safari dis
On Jun 5, 2014, at 10:42 AM, Ben Peters wrote:
>> From: Ryosuke Niwa [mailto:rn...@apple.com]
>>
>> Can this be an attribute on elements instead? Otherwise, browsers would
>> have to repeatedly call these functions to update edit menu, etc...
>
> This may be an issue, I agree. But since it's
On 6/5/14 1:42 PM, Ben Peters wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Can this be an attribute on elements instead? Otherwise, browsers would
have to repeatedly call these functions to update edit menu, etc...
This may be an issue, I agree. But since it's dynamic and changes every t
> From: Ryosuke Niwa [mailto:rn...@apple.com]
>
> Can this be an attribute on elements instead? Otherwise, browsers would
> have to repeatedly call these functions to update edit menu, etc...
This may be an issue, I agree. But since it's dynamic and changes every time
the selection/caret moves,
Can this be an attribute on elements instead? Otherwise, browsers would have
to repeatedly call these functions to update edit menu, etc...
Also, we should talk with people working on Indie UI
(http://www.w3.org/WAI/IndieUI/). The problem we're solving here is very
similar to the one they're
13 matches
Mail list logo
