I'm not sure if I remember correctly, but I believe that after long
discussions we left the question what should contenteditable=minimal be?
unanswered. First the intention events lists should be created, so we can
see what needs to be handled. And this is what Ben Peters is working on.
Still we
On Tue, Jul 1, 2014 at 1:19 AM, Ryosuke Niwa rn...@apple.com wrote:
On Jun 24, 2014, at 3:44 AM, Robin Berjon ro...@w3.org wrote:
Second, it doesn't address the point made below about native UI exposing a
likely non-natural subset of the commands I wish to support.
That presumes an
On Tue, Jun 24, 2014 at 12:34 PM, Robin Berjon ro...@w3.org wrote:
On 23/06/2014 20:33 , Johannes Wilm wrote:
I filed bugs on this on both Firefox and Chrome in spring 2013. It was
briefly fixed in Chrome, but the fix was then retracted and we never
heard any more of it. It was also reported
I think that first we need to clarify how we understand some
terms/concepts, because I was confused many times and I'm afraid that I
also haven't been understood correctly.
1. Separation of basic user intent events and rich command events.
Examples:
* user intent events - insert character
On Tue, Jun 17, 2014 at 2:39 AM, Julie Parent jpar...@google.com wrote:
I certainly understand the concern that it would be impossible to properly
catch and cancel all events.
I'm not concerned only about this. I'm concerned about the fact that
currently existing commands and editable-related
On Sun, Jun 15, 2014 at 5:15 AM, Olivier F teleclim...@gmail.com wrote:
On Fri, Jun 13, 2014 at 11:37 AM, Ben Peters ben.pet...@microsoft.com
wrote:
On Fri, Jun 13, 2014 at 1:01 AM, Ryosuke Niwa rn...@apple.com wrote:
On Jun 12, 2014, at 5:07 PM, Olivier F teleclim...@gmail.com wrote:
On Fri, Jun 6, 2014 at 6:39 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński p.koszulin...@cksource.com
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
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
On Wed, Jun 4, 2014 at 8:31 PM, Ben Peters ben.pet...@microsoft.com 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
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 totally
On Tue, May 27, 2014 at 11:01 AM, Robin Berjon ro...@w3.org wrote:
On 25/05/2014 20:40 , Piotr Koszuliński wrote:
Making some things unselectable might also be useful. IE has
unselectable, there's also -moz-user-select and friends. But this is
small fries for later I'd reckon
But what is the default behaviour then? What will we be preventing?
There's no accepted specification for current contentEditable=true AFAIK,
so I thought that the goal of contentEditable=minimal is to avoid the need
to write a specification for contentEditable=true. Otherwise, developers
may
On Tue, May 27, 2014 at 1:48 AM, Ben Peters ben.pet...@microsoft.comwrote:
5. There should be no native toolbars in cE=minimal (and other native
UI
interfering) like the one Safari opens on iOS if you have non-empty
selection.
I haven't yet checked exactly what's in the iOS toolbar, but
to imagine how all of this will function (e.g. I'm not sure I
understand what and how I will have to handle about composition). And it
will be a nice addition to spec in the future.
On Fri, May 23, 2014 at 11:55 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, May 22, 2014 at 3:59 AM, Piotr
6. Spell check. When you want a native spell check you cannot override
context menu. When you want custom context menu, you need custom spell
check
(which is extremely hard). And context menu is very important for many
users
because they used to look there for contextual options, so
* Cursor navigation, including reacting to touch events, mouse clicks
and keyboard events. Cursor navigation would likely also fire
cancelable events.
Yes. Cursor navigation can be represented through selections (that may be
collapsed). In general it is important that selection changes
Moreover, the clipboard is systemwide, when selection exists per document.
So in my opinion window is a better choice.
On Fri, May 23, 2014 at 3:21 PM, James Greene james.m.gre...@gmail.comwrote:
I wouldn't put this on window though; why not put it on Selection?
This kind of copy does not
I wrote a longer reply in the contentEditable=minimal thread, which touches
some aspects of command events. Actually, before some stable point about
cE=minimal is reached I feel that it may be hard to design command events
in a way that both are interoperable. Command events should be an extension
Great news and a great idea. I totally second a concept of making
contenteditable simpler and a lot more controllable for us, editors
developers. Even if it would be possible to make cE=true interoperable,
there are cases which depend on editor's logic. For example, in CKEditor
Bold command may be
19 matches
Mail list logo
