I agree with James. The reason to have it in the list is to have a normalized
name for it (instead of worrying about platform specific clipboard types). As
long as the browser isn’t required to handle it or prevented from handling it,
it can included to make it both readable and writable by
[subject change]
Multiple selection is an important feature in the future. Table columns are
important, but we also need to think about BIDI. Depending on who you talk to,
BIDI should support selection in document order or layout order. Layout order
is not possible without multi-selection.
I
I'm not sure if any sites depend on the Gecko/Trident behavior, but I imagine
any such sites also work in Webkit/Blink. So I'm fine with changing this unless
anyone knows of an important dependency.
-Original Message-
From: Ryosuke Niwa [mailto:rn...@apple.com]
Sent: Tuesday, January
Peters; Gary Kacmarcik (Кошмарчик)
Cc: public-webapps@w3.org; public-editing-tf
Subject: Re: DOM L3 Events Input Events Work to the Editing Task Force
On 12/15/14 7:00 PM, Ben Peters wrote:
On Mon, Dec 8, 2014 at 2:33 PM, Gary Kacmarcik (Кошмарчик)
gary...@chromium.org wrote:
[...]
Thus, I
On Mon, Dec 8, 2014 at 2:33 PM, Gary Kacmarcik (Кошмарчик)
gary...@chromium.org wrote:
[...]
Thus, I wonder if a separate Input Event spec (that both D3E and Editing
would refer to) would make more sense.
I think so. I have started that spec at
You all have excellent points, thank you! Device Independent Events gets
straight to the point, and I like that. Are there any objections to calling
this concept Device Independent Events?
My goal with Responsive Input Events was to encourage web developers to use
them as part of the
[cross-posted]
There has been a lot of debate [1][2] about the correct name for device
independent events [3] as a concept*. We have considered Intention Events,
Command Events, and Action Events among others. I believe we now have a good
name for them- Responsive Input Events. The reason for
Since the Editing Task Force is working on several input-related issues, we
would like to take over the work on Input Events. I have created an unofficial
document for that purpose at
http://w3c.github.io/editing-explainer/input-events.html. It is based on the
work in DOM L3. Can we move the
I believe we should design this with multiple Ranges in mind. Otherwise
multiple selection requires a lot of work in javascript. Even if we don't
actually support multi-selection in V1, we should not block it for a future
spec.
-Original Message-
From: Joanmarie Diggs
I'm not sure we need to address these in V1. 21700 is probably important, but I
don't think we need to solve the local content or other issues in V1. We should
get to the point of having browser and developer agreement on basic clipboard
functionality, create tests to verify it, and ship the
[cross-posted, please don't reply all]
WebApps is hosting a meeting at TPAC to discuss the future of Selection [1],
Editing [2], and User Intention events [3]. Understanding user intentions has
come up in many contexts, so anyone working in that area is welcome. This
meeting will help shape
Yes, that would be great!!
From: Piotr Koszuliński [mailto:p.koszulin...@cksource.com]
Sent: Wednesday, October 1, 2014 5:20 AM
To: Ben Peters
Cc: public-editing...@w3.org; public-indie...@w3.org; public-webapps
Subject: Re: [Editing] Tracking Issues in GitHub
Hey,
On the Extensible Web Summit
Yes, the spec is ready for that (major API areas and concepts should be
covered).
From: Kenji Baheux [mailto:kenjibah...@google.com]
Sent: Friday, September 26, 2014 1:45 AM
To: Arthur Barstow
Cc: public-webapps; Ryosuke Niwa; Ben Peters
Subject: Re: [selection-api] Moving toward First Public
In order to simplify and streamline communication on open issues for Editing
and Intentions, I suggest we have more conversations on GitHub. To that end, I
have opened Issues for the list of bugs in the spec, and removed them from the
spec itself. If there are no objections, please check out
Selection.extend is a separate API from Selection.modify. They are both listed
by Mozilla at
https://developer.mozilla.org/en-US/docs/Web/API/Selection?redirectlocale=en-USredirectslug=DOM%2FSelection
for reference. Thanks for the feedback!
Ben
From: e...@ictenablers.com
. 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 may also take in consideration that there are limited resources
available for working on the specs. Therefore the whole work could be
separated
I think what I'm hearing in this conversation about the shape of a new
contentEditable is really that a simple minimal is not going to work.
Instead, having something like a delimited list will satisfy more people. See
the bug on GitHub [1] for more details.
On Sat, Sep 6, 2014 at 1:54 AM, Johannes Wilm johan...@fiduswriter.org wrote:
These both look quite good!
On Example 3 on the commands explainer, I was wondering if it is the idea
that custom actions only can be triggered by specific key presses, whereas
for standard events are triggered by
document. Thanks!
[1] http://w3c.github.io/editing-explainer/
[2] http://w3c.github.io/editing-explainer/commands-explainer.html
On Mon, Aug 11, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote:
I agree with this. We should have a single 'shape' for these events and
shared terminology
On Tue, Aug 19, 2014 at 10:08 AM, Daniel Cheng dch...@chromium.org wrote:
On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen hst...@mozilla.com
wrote:
Does anyone else have input for/against this?
Conceptually, I guess RTF sort of covers the same use cases as HTML. That
doesn't
From: Ben Peters
On Tue, Aug 19, 2014 at 10:08 AM, Daniel Cheng dch...@chromium.org
wrote:
On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
Does anyone else have input for/against this?
Conceptually, I guess RTF sort of covers the same use cases
I agree with this. We should have a single 'shape' for these events and shared
terminology.
I think trying to solve all of the problems in one complete spec would be too
complex, but if we use an Intentions Explainer to divide the problem into
manageable pieces, we can continue on our
I don't understand the difference. setBaseAndExtent would then set all 4 of
these properties of selection? Do you have a definition to use for this?
From: Ryosuke Niwa [mailto:rn...@apple.com]
Sent: Wednesday, August 6, 2014 12:43 PM
To: James M. Greene
Cc: Ben Peters; public-webapps
Subject: Re
the difference between focus/anchor and
base/extent, and since it is only supported by WebKit based browsers, it is not
heavily used.
On Wed, Aug 6, 2014 at 12:58 PM, Ben Peters
ben.pet...@microsoft.commailto:ben.pet...@microsoft.com wrote:
I don’t understand the difference. setBaseAndExtent would
or
longer than node's length ([DOM4]). Otherwise, it must create a new range, set
([DOM4]) its start to (baseNode, baseOffset) and its and end to (extentNode,
extentOffset), and set the context object's range to the newly-created range.
From: Ben Peters
Sent: Tuesday, May 20, 2014 11:37 AM
?This API is already used on the web so we should probably keep it as-is.
From: James M. Greene james.m.gre...@gmail.com
Sent: Tuesday, August 5, 2014 4:58 PM
To: Ben Peters
Cc: Ryosuke Niwa; public-webapps
Subject: RE: [selection] Selection.setBaseAndExtent
?
From: Julie Parent jpar...@google.com
This is a great list, and I agree it is the right starting point.
On Mon, Jul 21, 2014 at 6:12 PM, Ben Peters ben.pet...@microsoft.com wrote:
We now have a good list of use cases on the Explainer[1]. I believe the next
step is to come up
-Original Message-
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
On Wed, Jul 23, 2014 at 12:17 AM, Ben Peters ben.pet...@microsoft.com
wrote:
[1] http://www.w3.org/TR/clipboard-apis/#semi-trusted-events
The default action of a synthetic paste event
-Original Message-
From: Perry Smith [mailto:pedz...@gmail.com]
As a side note: I would change isTrusted to fromUserAgent to make it
more honest. Folks are somewhat foolish to trust their browsers and all the
plugins. e.g. people unwittingly trust flash. I would remove trust from
Semi-trusted events in the Clipboard API spec [1] are a potential solution to
an important problem- sites should be able to use the same infrastructure
(clipboard events) with their own triggers (button with execCommand('paste') as
browser initiated clipboard operations (like user presses
Summary:
A few folks from the IndieUI TF came to the meeting today. We went over our
goals and the possibility of working together on solving User Intentions for
the web.
Minutes are available at http://www.w3.org/2014/07/11-webapps-minutes.html
Text version:
conference code?
BenjamP
There was discussion a few years back in bugs for both Mozilla[1] and Webkit[2]
that window.find() should be killed, but that it was used in TinyMCE (a broadly
used js framework). Does anyone still use this API? Has anyone reached out to
TinyMCE about this? Do we still believe it should be
(logged):
#webapps on irc.w3.org
-Original Message-
From: Ben Peters [mailto:ben.pet...@microsoft.com]
Sent: Tuesday, July 1, 2014 3:13 PM
To: public-webapps@w3.org; public-h...@w3.org; public-editing...@w3.org
Subject: [editing] Conference Call July 11th 8am San Francisco Time
Hi
I have added a new section[1] to the Commands Explainer that helps visualize
the way I see user intention information benefitting sites and frameworks.
Please review this and let me know how I can improve these diagrams. The main
point is Ideally, sites should have a more direct way of
Hi WebApps/HTML,
There has a been a lot of progress on figuring out goals and use cases for
Editing since the last call. I think it would be beneficial to do another call
next Friday, July 11th. Does everyone agree? We have the time reserved at 8am
Pacific Standard Time [1].
I will add all of
-Original Message-
On 23/06/2014 18:25 , Julie Parent wrote:
Well stated. I like contentEditable=cursor.
Works for me. Should I just scare up a draft? It is likely to be a pretty
short
spec :)
I'm really looking forward to getting things sorted out! But I think we may
want
The Clipboard API spec has a section on Mandatory Data Types [1]. It
says The implementation must recognise the native OS clipboard format
description for the following data types, and contains a list of 14
mime types. Most of them have clear purposes, but a few seem arbitrary
to me. Since I
From: Robin Berjon [mailto:ro...@w3.org]
On 06/06/2014 18:39 , Ryosuke Niwa 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
://www.w3.org/Guide/1998/08/teleconference-calendar#s_6399
-Original Message-
From: Ben Peters [mailto:ben.pet...@microsoft.com]
Hello Web Apps,
Our recent call [1] regarding HTML Editing (contentEditable, CommandEvent)
was quite valuable. It seems valuable to have a time reserved
On Tue, Jun 17, 2014 at 8:47 AM, Piotr Koszuliński p.koszulin...@cksource.com
wrote:
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
On Tue, Jun 17, 2014 at 4:50 PM, Olivier F teleclim...@gmail.com wrote:
On Tue, Jun 17, 2014 at 1:44 PM, Julie Parent jpar...@google.com wrote:
An app can have a cursor that isn't a native browser cursor. For example,
Google Docs does not use native browser cursors and draws their own, so that
There's been a good deal of discussion about the value of
contentEditable=minimal. Some of us think that being able to cancel all browser
actions with preventDefault on all Intention events is enough, while others
believe that having a single way to stop browsers from taking action makes
On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote:
If Intention events are (temporarily) moved out of scope,
I don’t think I’d say they’re out of scope, just that they will likely not be
ready as quickly as we could do contentEditable=’minimal’. Do you agree with
that?
On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com wrote:
Yes. I really like the idea of explicitly enabling what you want and of
separating the concepts. Being able to turn on commandEvents independent of
a cursor seems useful. An API like this leaves far fewer questions of
will close June 18th.
http://doodle.com/d8m624mfcvutnf4w
Ben Peters
[1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0842.html
[2]
http://www.worldtimebuddy.com/?pl=1lid=5391959,5128581,2950159,1850147h=2950159
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
I just filed this bug. Do we know of reasons why Chrome (Webkit?) doesn't throw
an exception for this scenario? It seems confusing to web devs.
Ben
-Original Message-
From: bugzi...@jessica.w3.org [mailto:bugzi...@jessica.w3.org]
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26005
From: Robin Berjon [mailto:ro...@w3.org]
On 21/05/2014 20:51 , Ben Peters wrote:
I’m not sure an extra event type is necessary here though: why not
use beforeinput for the input events, and selectionchange for
selection events? Ryosuke’s selection spec currently has a
placeholder
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,
Hi WebApps,
There will be a conference call on June 6th at 08:00 (8am) San Francisco time
(PST) to discuss the recent editing topics contentEditable=minimal and
CommandEvent[1]. We will be on #webapps with Zakim and will send minutes to
this list. The pin and further details will be sent
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. One way to solve this is to have an
event that would allow script to tell the browser what is relevant. Today,
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
: Robin Berjon [mailto:ro...@w3.org]
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
: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer
The discussion of which minimal default handling to include with
contenteditable=minimal makes me wonder if contentEditable=minimal is
necessary at all
:40 PM
To: Ben Peters
Cc: Julie Parent; public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer
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
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
On Thu, May 22, 2014 at 4:02 AM, Piotr Koszuliński p.koszulin...@cksource.com
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
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 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
Great to hear! I’m working on an explainer document that will be more
descriptive than the short wiki docs I wrote a couple weeks ago. My thoughts on
your questions should be made clearer there. I’ll update this thread by the end
of the week with more details, and my initial thoughts are below.
as an API, rather than as a standalone component
that tries to do everything itself. It discusses the idea of an edit intent
API, which is very in line with this proposal for CommandEvents.
https://medium.com/medium-eng/122d8a40e480
On Wed, May 21, 2014 at 11:51 AM, Ben Peters
ben.pet
I have filed a bug to track this issue [1].
Ben
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831
From: Ben Peters [mailto:ben.pet...@microsoft.com]
Sent: Monday, May 5, 2014 11:28 PM
To: Ryosuke Niwa; public-webapps@w3.org
Subject: [selection] Selection.setBaseAndExtent
I noticed
I noticed that some websites use selection.setBaseAndExtent [1]. According to
what limited documentation I could find, it works similar to selection.extend.
Is there any intention to standardize this, or is it made obsolete by
selection.extend?
Ben
[1]
I have been discussing a new concept with some people for enabling a subset of
contentEditable behavior without all of the built-in formatting and some other
functionality. It was discussed a bit at the Extensible Web Summit [1]. Below
is a draft I wrote about this, which is also on GitHub [2].
The Selection API Bugzilla component [1] is now available for bugs in the
Selection API spec [2]. I propose that we move selection-related bugs from the
HTML Editing APIs spec [3] to this new component. Are there any objections? If
not, we will be moving some bugs over (in case you're tracking
Also on Mac, there is no !--StartFragment-- and !--EndFragment-- and the
serialized markup copied into the clipboard (called pasteboard on Mac) needs
to contain the precisely the markup that got copied by the user.
Good point. Perhaps we should make sure any OS specific items like
After working with developers inside and outside Microsoft, it seems there
are several types of paste that make sense in various scenarios. For
instance,
1- if pasting into a rich document, it could be important to maintain
source styling information.
2- When pasting into a wiki from an
One possibility would be to do something similar to Firefox, but also
include a text/css clipboard item, which contains styles relevant to
what is copied
This seems like an excellent idea! I'm not sure how hard it is to implement,
but it might be doable without too much effort. Some
?
Ben Peters
* there is actually a way to do this, but it's a hack and we're trying to solve
it. Currently several implementations actually move the focus to a hidden
iframe, allow the paste to run, clean up the new DOM, and then move it to where
the paste happened. This causes issues because
Looking into selection in this brave new world (Shadow DOM for sure, but
there are issues as well with flexbox if I'm not mistaken), is definitely
something we are interested in.
I also agree with moving selection to its own spec. Solving selection first
opens the door to solving editing.
Hi Daniel,
I'm trying to make sure I correctly understand how the IE11 version of this
works. From the sample
(http://msdn.microsoft.com/en-us/library/ie/dn254935(v=vs.85).aspx), it looks
like if a user pastes in some HTML that references local images, IE11
automatically captures the
Second, can you provide the javascript for how a site would put them into
the pasted markup during paste?
The way I thought this would work, would be that the site starts XHR
uploads from the paste processing, and shows some intermediate 'loading'
animation or something before it gets the
Of course it would be nice to support a script that wants to generate random
HTML with embedded files to place on the clipboard (although I think most of
those use cases can already be met by using URLs and assuming that any
software reading HTML from the clipboard can understand URLs..).
in the example I found online [3].
* Some sites prefer DataURI to Blob because it’s all inline and doesn’t require
sending separate objects or managing memory, so I don’t think DataURI is
something we should discount.
Looking forward to seeing your sample code!
Ben Peters
[1] http
77 matches
Mail list logo
