I have completed a first-draft explainer document [1], taking the generous
feedback of many of you into account. There are 6 open issues on the document
currently, and I'm sure there are others that I have missed. It would be great
to know if this is heading in in the right direction.
My vision
> 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 Thu, May 22, 2014 at 4:02 AM, Piotr Koszuliński
wrote:
>
> 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
>
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
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
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 5/14/14 2:46 PM, Arthur Barstow wrote:
NOTE: in the absence of any non-resolvable feedback, this proposal
will carry i.e. [3] will be updated to include this joint spec.
FYI, this has been done.
(I also explicitly added the Selection API and made a couple of
additional edits based on input
On 5/21/14 10:47 AM, Brian Kardell wrote:
I've kind of thought of Web Platform Docs as the developer end of
things and w3c specs for implementers and wgs - is it possible to set
something up under that banner?
Perhaps; I haven't followed WPD so if anyone has data about its actual
usage by
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765
Anne changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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'
On Thu, May 22, 2014 at 1:45 AM, Jonas Sicking wrote:
> The fact that we allow passing blobs around is no different from the
> fact that we allow passing an ArrayBuffer or a string around. Once a
> page knows that it has the blob/arraybuffer/string the only way to
> have it XSS you is to eval() it
14 matches
Mail list logo
