Hello Everyone,
The idea of a contentEditable spec that is usable for developers gives me
so much hope that I am drawn to make my very first comment on a W3 list.
First, thank-you Ben Peters for the original post.
I am an independent web developer who is frustrated because I feel there is
a
On 05/06/2014 09:02 , Ryosuke Niwa wrote:
I agree visual selection of bidirectional text is a problem worth
solving but I don't think adding a generic multi-range selection
support to the degree Gecko does is the right solution.
I'd be interested to hear how you propose to solve it in another
On 02/06/2014 23:01 , Ben Peters wrote:
From: Robin Berjon [mailto:ro...@w3.org] I think that the latter is
better because it gives the library the computed range that matches
the operation, which as far as I can imagine is what you actually
want to check (e.g. check that the newRange does not
On Jun 6, 2014, at 6:40 AM, Robin Berjon ro...@w3.org wrote:
On 05/06/2014 09:02 , Ryosuke Niwa wrote:
I agree visual selection of bidirectional text is a problem worth
solving but I don't think adding a generic multi-range selection
support to the degree Gecko does is the right solution.
On Jun 6, 2014, at 9:52 AM, Ryosuke Niwa rn...@apple.com wrote:
On Jun 6, 2014, at 6:40 AM, Robin Berjon ro...@w3.org wrote:
On 05/06/2014 09:02 , Ryosuke Niwa wrote:
I agree visual selection of bidirectional text is a problem worth
solving but I don't think adding a generic multi-range
On May 22, 2014, at 1:52 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, May 1, 2014 at 5:31 PM, Ben Peters ben.pet...@microsoft.com wrote:
Proposal
To make this simpler for sites, frameworks, and browsers, it makes sense to
enable a new, simpler version of contentEditable that provides
On May 27, 2014, at 1:33 AM, Robin Berjon ro...@w3.org wrote:
On 27/05/2014 01:47 , Ben Peters wrote:
-Original Message- From: Robin Berjon
On 26/05/2014 05:43 , Norbert Lindenberg wrote:
Were any speakers of bidirectional languages in the room when
this was discussed?
I don't
On May 23, 2014, at 1:37 PM, Robin Berjon ro...@w3.org wrote:
On 23/05/2014 21:32 , Jonas Sicking wrote:
On Fri, May 23, 2014 at 4:43 AM, Robin Berjon ro...@w3.org wrote:
On 23/05/2014 12:28 , Jonas Sicking wrote:
And on mobile autocorrect of misspelled words is common, though that
can
Message-
From: Ben Peters [mailto:ben.pet...@microsoft.com]
Sent: Monday, June 2, 2014 2:00 PM
To: Robin Berjon; Julie Parent
Cc: Johannes Wilm; public-webapps@w3.org
Subject: RE: contentEditable=minimal
Great context. Thanks! Let me ask my question another way- should
CompositionEvents be used
From: Robin Berjon [mailto:ro...@w3.org]
I think we agree at the high level but might disagree over smaller details.
You
seem to want something that would roughly resemble the
following:
BeforeSelectionChange
{
direction: forward
, step: word
}
whereas I would see
Great context. Thanks! Let me ask my question another way- should
CompositionEvents be used when there isn't a composition? Should typing 'a'
fire CompositionEnd? If not we still need a CommandEvent of type insertText,
and it seems inconsistent not to fire it for all typing, doesn't it?
From:
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.
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
On 27/05/2014 01:47 , Ben Peters wrote:
-Original Message- From: Robin Berjon
On 26/05/2014 05:43 , Norbert Lindenberg wrote:
Were any speakers of bidirectional languages in the room when
this was discussed?
I don't know what languages the others speak. That said, my
recollection was
Hi Ben,
On 27/05/2014 02:07 , Ben Peters wrote:
From: Robin Berjon [mailto:ro...@w3.org] Even without accounting
for touch screens, you really want the platform to be the thing
that knows what Ctrl-Shift-Left means so you don't have to support
it yourself (and get it wrong often).
Agree. One
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.
There are also nested non-editable islands. We built very important
On 27/05/2014 01:52 , Ben Peters wrote:
From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben
Peters wrote:
As I said I am unsure that the way in which composition events
are described in DOM 3 Events is perfect, but that's only
because I haven't used them in anger and they aren't
]
Sent: Tuesday, May 27, 2014 2:39 AM
To: Ben Peters; Julie Parent
Cc: Johannes Wilm; public-webapps@w3.org
Subject: Re: contentEditable=minimal
On 27/05/2014 01:52 , Ben Peters wrote:
From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben
Peters wrote:
As I said I am unsure that the way
On 26/05/2014 05:43 , Norbert Lindenberg wrote:
On May 23, 2014, at 5:19 , Robin Berjon ro...@w3.org wrote:
Which brings me to think: when we discussed this at the Summit,
there was some agreement (between all four of us :) that it was a
good idea to support multi-range selections. These are
On May 23, 2014, at 5:19 , Robin Berjon ro...@w3.org wrote:
Which brings me to think: when we discussed this at the Summit, there was
some agreement (between all four of us :) that it was a good idea to support
multi-range selections. These are useful not just for tables, but also for
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 generally
I don't think we should dictate UI. Clearly on mobile we don't want to
-Original Message-
From: Robin Berjon [mailto:ro...@w3.org]
Sent: Monday, May 26, 2014 1:41 AM
To: Norbert Lindenberg
Cc: Jonas Sicking; Piotr Koszuliński; Ben Peters; public-webapps
Subject: Re: contentEditable=minimal
On 26/05/2014 05:43 , Norbert Lindenberg wrote:
On May 23
-Original Message-
From: Robin Berjon [mailto:ro...@w3.org]
On 23/05/2014 01:23 , Ben Peters wrote:
As I said I am unsure that the way in which composition events are
described in DOM 3 Events is perfect, but that's only because I
haven't used them in anger and they aren't
From: Robin Berjon [mailto:ro...@w3.org]
On 23/05/2014 11:55 , Jonas Sicking wrote:
On Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński
5. Navigating with arrow keys, selection with SHIFT, CTRL modifier.
Agreed. Developers have to deal with selection moving around anyway
since they
At the beginning I've been sceptical regarding cE=minimal not doing any DOM
modification at all. The ideal situation which I imagined was that you can
easily use cE=minimal in basic case like a single paragraph of text with a
bold and italic buttons (which you need to implement by yourself). This
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
On Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński
p.koszulin...@cksource.com wrote:
## What should cE=minimal handle?
Awesome feedback!
## What should cE=minimal handle?
1. Selection and caret drawing.
2. Selection API
Agreed on both!
3. Typing characters.
4. Delete, backspace.
I
On 23/05/2014 01:23 , Ben Peters wrote:
As I said I am unsure that the way in which composition events are
described in DOM 3 Events is perfect, but that's only because I
haven't used them in anger and they aren't supported much.
My thought is that we can use CommandEvent with type=insertText.
On 23/05/2014 12:28 , Jonas Sicking wrote:
And on mobile autocorrect of misspelled words is common, though that
can probably be handled by moving the selection to the misspelled word
and then writing the fixed word.
Autocorrect should be handled like composition. Composition is pretty
much
On 23/05/2014 11:55 , Jonas Sicking wrote:
On Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński
5. Navigating with arrow keys, selection with SHIFT, CTRL modifier.
Agreed. Developers have to deal with selection moving around anyway
since they should handle touch screens.
Even without
On Fri, May 23, 2014 at 4:43 AM, Robin Berjon ro...@w3.org wrote:
On 23/05/2014 12:28 , Jonas Sicking wrote:
And on mobile autocorrect of misspelled words is common, though that
can probably be handled by moving the selection to the misspelled word
and then writing the fixed word.
On Thu, May 1, 2014 at 5:31 PM, Ben Peters ben.pet...@microsoft.com wrote:
Proposal
To make this simpler for sites, frameworks, and browsers, it makes sense to
enable a new, simpler version of contentEditable that provides basic
functionality only. For the sake of discussion, call it
On 22/05/2014 00:43 , Julie Parent wrote:
I question whether contentEditable=minimal should actually handle text
input. If the idea is to provide the base platform on which a developer
can build the editing product of their dreams, isn't text insertion just
another behavior they could
On 22/05/2014 10:52 , Jonas Sicking wrote:
This sounds like a super promising approach.
\o/
If I understand the proposal correctly, when the user does something
that causes input, like pressing the enter key, we would fire a key
event, but we wouldn't actually modify the DOM. Modifying the
Thanks Jonas for clarification. Now, I understand contentEditable=minmal
doesn't modify DOM.
For drawing IME UI, text composition, Blink inserts text node with text
decoration to display on going text composition, IME UI. So, implementing
contentEditable=minimal, Blink should remove text nodes at
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
On 22/05/14 09:52, Jonas Sicking wrote:
On Thu, May 1, 2014 at 5:31 PM, Ben Peters ben.pet...@microsoft.com wrote:
Proposal
To make this simpler for sites, frameworks, and browsers, it makes sense to
enable a new, simpler version of contentEditable that provides basic
functionality only. For
Let us take the relatively simple issue with typing ñ on a keyboard setup
that does not natively support the character. On my keyboard, that is done
by first typing Alt-N, then N.
At the more complete end of the spectrum, what we have today, without
the developer doing anything, when I type
I question whether contentEditable=minimal should actually handle text
input. If the idea is to provide the base platform on which a developer
can build the editing product of their dreams, isn't text insertion just
another behavior they could potentially need to disable?
Stepping back, there
On 12/05/2014 00:46 , Johannes Wilm wrote:
Also this looks good. There seems to be consensus that contenteditable
is just not going o get fixed, and so removing the faulty behavior
entirely and replacing it with this would be almost as good.
It depends on what you mean by fixed. It is
Also this looks good. There seems to be consensus that contenteditable is
just not going o get fixed, and so removing the faulty behavior entirely
and replacing it with this would be almost as good. Intercepting key
strokes is already now possible and probably the best one can do. The one
thing
42 matches
Mail list logo
