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 whol
On Jun 6, 2014, at 9:52 AM, Ryosuke Niwa wrote:
> On Jun 6, 2014, at 6:40 AM, Robin Berjon 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 t
On Jun 6, 2014, at 6:40 AM, Robin Berjon 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.
>
> I'd b
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 co
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 m
On May 23, 2014, at 1:37 PM, Robin Berjon wrote:
> On 23/05/2014 21:32 , Jonas Sicking wrote:
>> On Fri, May 23, 2014 at 4:43 AM, Robin Berjon wrote:
>>> On 23/05/2014 12:28 , Jonas Sicking wrote:
And on mobile autocorrect of misspelled words is common, though that
can probably be hand
On May 27, 2014, at 1:33 AM, Robin Berjon 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
On May 22, 2014, at 1:52 AM, Jonas Sicking wrote:
> On Thu, May 1, 2014 at 5:31 PM, Ben Peters 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 th
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
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:
> 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
On Tue, May 27, 2014 at 11:01 AM, Robin Berjon 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.
>>
>> T
[mailto:ro...@w3.org]
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 w
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 s
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
featu
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 w
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 t
On Tue, May 27, 2014 at 1:48 AM, Ben Peters wrote:
> >>> 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
> 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
> >
> -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
> -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 ,
>>> 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
On May 23, 2014, at 5:19 , Robin Berjon 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
> bidi. The rea
On 26/05/2014 05:43 , Norbert Lindenberg wrote:
On May 23, 2014, at 5:19 , Robin Berjon 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
>
>
>
> * 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 select
>
>
> > 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 opt
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 i
On 23/05/2014 21:32 , Jonas Sicking wrote:
On Fri, May 23, 2014 at 4:43 AM, Robin Berjon 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 writin
On Fri, May 23, 2014 at 4:43 AM, Robin Berjon 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.
>
> Autocorrect
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 accountin
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 wha
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 Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński
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 think these are the hard
> 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
On 22/05/14 09:52, Jonas Sicking wrote:
On Thu, May 1, 2014 at 5:31 PM, Ben Peters 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,
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/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 DO
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 potentiall
On Thu, May 1, 2014 at 5:31 PM, Ben Peters 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
> contentEditable='minimal'
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 are
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 conceiv
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 whe
43 matches
Mail list logo
