RE: [clipboard API] platform integration stuff - in spec or out of scope?

[Ben Peters]

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 script. I haven’t seen 
vender pushback, but I haven’t been involved for as long as some.

From: James M. Greene [mailto:james.m.gre...@gmail.com]
Sent: Wednesday, February 11, 2015 6:59 PM
To: Hallvord Steen
Cc: public-webapps; Paul Libbrecht
Subject: Re: [clipboard API] platform integration stuff - in spec or out of 
scope?


Allow me to clarify my position.

My expectation is NOT for the browsers' default action on "copy"/"cut" to 
convert HTML into RTF. I do not see any such implication of that behavior in 
the spec language [1].

Rather, I just want to ensure that browsers will honor/maintain that clipboard 
format/segment if it is set during a custom "copy" event handler using the 
`event.clipboardData.setData` method. The current language of the spec [2] 
leaves the possibility open for an implementor to choose to ignore/discard any 
data formats that are not on the mandatory data types list [1], and I find that 
worrysome.

Is the problem that spec may be implying that the browser must know what to do 
with the data when PASTING from a clipboard segment associated with a mandatory 
data type? I could see that as more of a sticking point for implementors... but 
again, I really just want to ensure that the "application/rtf" clipboard 
segment is simply left intact bi-directionally. If the spec were to be updated 
to generally ensure that type of maintained/untouched transfer for data types 
that are NOT on the mandatory data types list (i.e. "custom data types"), then 
I would be fine leaving "application/rtf" OFF the mandatory data types list.

Can we get some clarification on the vendor pushback reasoning in this regard?

Thanks!

[1]: http://dev.w3.org/2006/webapi/clipops/clipops.html#mandatory-data-types
[2]: 
http://dev.w3.org/2006/webapi/clipops/clipops.html#writing-contents-to-the-clipboard

Sincerely,
   James M. Greene
On Feb 11, 2015 3:15 PM, "Hallvord Reiar Michaelsen Steen" 
mailto:hst...@mozilla.com>> wrote:
On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene 
mailto:james.m.gre...@gmail.com>> wrote:
We never really came to a decision on if RTF ("application/rtf") should be 
listed as a mandatory MIME type but the general consensus seemed to be leaning 
toward "yes":
   https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0197.html

There was some pushback from vendors - and I think their arguments were 
reasonable. Why should a web browser have to include code to generate RTF 
documents to write them to the clipboard? It's going to be a non-trivial amount 
of code, it will be rarely executed and could easily come with exploitable 
security vulnerabilities. It only makes sense to require this if there is a 
significant amount of software out there that supports pasting RTF data but 
does *NOT* support pasting HTML data - so that if we mandate support for 
writing HTML to the clipboard but leave RTF out, many users will have problems 
pasting text with formatting into another application. How many applications 
would have this issue on the various platforms? How widely are they used? Would 
users even expect to be able to preserve formatting on pasting into or copying 
from these applications?

A reply from you in the earlier discussion of these questions is here:
https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0325.html

-Hallvord, wearing an invisible clipboard spec editor hat

[Selection] Support of Multiple Selection (was: Should selection.getRangeAt return a clone or a reference?)

[Ben Peters]

[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 do not believe “everyone wants to kill it” is accurate. I agree with Olivier 
that it’s crucial to a full-featured editor. We don’t want to make sites 
implement this themselves.

From: Olivier Forget [mailto:teleclim...@gmail.com]
Sent: Monday, January 12, 2015 10:56 AM
To: Aryeh Gregor
Cc: Ryosuke Niwa; Koji Ishii; Webapps WG
Subject: Re: [Selection] Should selection.getRangeAt return a clone or a 
reference?

On Sat Jan 10 2015 at 8:30:34 AM Aryeh Gregor 
mailto:a...@aryeh.name>> wrote:

I don't remember whether it was ever discussed on the mailing list in
depth.  The gist is that no one has ever implemented it except Gecko,
and I'm pretty sure no one else is interested in implementing it.  The
Selection interface was invented by Netscape to support multiple
ranges to begin with, but all the other UAs that reverse-engineered it
and/or implemented from the DOM Range specs deliberately made it
support only one range (in incompatible UA-specific ways, naturally).
Ehsan Akhgari, maintainer of the editor component for Gecko, is in
favor of removing (user-visible) support for multiple selection ranges
from Gecko, and last I heard no one objected in principle.  So the
consensus of implementers is to support only one range.  As far as I
know, the only reason Gecko still supports multiple ranges is because
no one has gotten around to removing them.  (Ehsan would know more
about that.)
OK I understand that. My concern here is that the general attitude is to ignore 
this problem and hope it somehow goes away. Unfortunately multiple range 
selections are not a "nice to have". All "real" editors (MS Word, Google Docs, 
etc..) support selecting multiple ranges, and it's very common for users to 
select a column of  a table. As the web platform makes great strides forward 
rich editing capabilities should also keep up.

If today we decide that multiple ranges is out then we are doing two things:
- promoting the "Selection is only ever one continuous range" fallacy to all 
web developers.
- delaying the arrival a decent spec that actually handles multiple ranges (or 
disjoint ranges or whatever it takes to do "real world" selections.)

I am worried this means it will be a very long time before the web platform 
supports developing editors with commonly accepted editing paradigms.

RE: [Selection] Should selection.getRangeAt return a clone or a reference?

[Ben Peters]

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 6, 2015 2:32 PM
To: Webapps WG
Subject: [Selection] Should selection.getRangeAt return a clone or a reference?

https://github.com/w3c/selection-api/issues/40

Trident (since IE10) and Gecko both return a live Range, which can be modified 
to update selection.  WebKit and Blink both return a clone Range so that any 
changes to the Range doesn't update the selection.

It appears that there is a moderate interest at Mozilla to change Gecko's 
behavior.  Does anyone have a strong opinion about this?

- R. Niwa

Re: DOM L3 Events Input Events Work to the Editing Task Force

[Ben Peters]

Let me get it cleaned up over the holidays and then let's start this process in 
Jan if the Task Force thinks it's ready. I'm going to do a teleconference on 
Jan 9.


From: Arthur Barstow 
Sent: Friday, December 19, 2014 4:23 AM
To: Ben 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 (Кошмарчик) 
>  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 
> http://w3c.github.io/editing-explainer/input-events.html.

Thanks Ben!

Does this spec now include all of the features expected, at least at a
breadth level? If so, perhaps we should move toward a FPWD. WDYT?

-Thanks, AB

RE: DOM L3 Events Input Events Work to the Editing Task Force

[Ben Peters]

On Mon, Dec 8, 2014 at 2:33 PM, Gary Kacmarcik (Кошмарчик) 
 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 
http://w3c.github.io/editing-explainer/input-events.html. 

RE: [editing] Responsive Input Terminology

[Ben Peters]

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 responsive design pattern, allowing sites to work 
regardless of device or input modality. But the point about not being tied to 
another concept is well taken. 

To answer the questions about the scope of this concept, I believe it can apply 
to more than just DOM L3 Input Events. At the moment, the use cases are Input 
and Selection, and there is talk of doing something related for Scrolling. This 
design pattern should cover any way a user interacts with a web page, and the 
goal should be to make such 'input' resilient to new devices or input types. 
But keep in mind that there is no desire to actually use this term in an API. 
It is a concept that we want to capture in an Explainer document so current and 
future efforts can follow and refer to the design pattern, and so web 
developers understand what we're trying to accomplish with beforeInput events 
and beforeSelectionChange events.

The reason I want to have this broad conversation about naming is simply for 
consistency in terminology across relevant specs. 

[editing] Responsive Input Terminology

[Ben Peters]

[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 this name is that it is 
the corollary to Responsive Layout: for input instead of output. Together these 
two concepts can help form the basis of Responsive Design going forward. 

This could potentially apply to areas outside of editing in the future, so if 
anyone has further feedback on this name we should get it locked down now so we 
have a consistent story going forward. Let me know if you have feedback!

Ben


* the concept is summarized in the Explainer [3] Introduction as "Today, sites 
mostly respond to Device-Specific Input directly, causing several issues 
including difficultly understanding what a user intends, complexity in building 
Accessible sites, and complex localization. This document is meant to describe 
the path forward for Responsive Input across multiple areas so that sites can 
be written more simply across devices and input modalities in an Accessible and 
future-ready way."

[1] https://github.com/w3c/editing-explainer/issues/7
[2] 
https://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=subject&hdr-1-query=Need+Agreement+on+Terminology&index-grp=Public_FULL&index-type=t&type-index=public-editing-tf
 
[3] http://w3c.github.io/editing-explainer/responsive-input-explainer.html

DOM L3 Events Input Events Work to the Editing Task Force

[Ben Peters]

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 DOM L3 Input Events design to be only what is 
already implemented in browsers (which should make it easier to finish DOM L3, 
right?), and work on it going forward in the Editing Task Force?

Ben

RE: [Selection API] Plans regarding multiple ranges?

[Ben Peters]

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 [mailto:jdi...@igalia.com] 
Sent: Wednesday, November 12, 2014 12:15 PM
To: public-webapps@w3.org
Cc: W3C WAI Protocols & Formats
Subject: [Selection API] Plans regarding multiple ranges?

Hi all.

The current draft of the Selection API states:

This specification follows non-Gecko engines in restricting
selections to at most one range, but the API was still originally
designed for selections with arbitrary numbers of ranges. This
explains oddities like the coexistence of removeRange() and
removeAllRanges(), and a getRangeAt() method that takes an integer
argument that must always be zero.

If things change and multiple ranges are supported, there may (or may
not) be associated accessibility needs to address or techniques to create. If 
multiple ranges are not supported, then there are clearly not such needs or 
techniques. So before we (PFWG) give it more thought, do you happen to know 
what your plans are for multiple ranges? In particular, if some non-Gecko 
engine added support for multiple ranges, would your API change to reflect 
that? Or are the corner cases just too unpleasant?

Thanks in advance. Take care.
--joanie

RE: Oct 2014 status report and plans

[Ben Peters]

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 spec.

Ben

On Fri, Oct 24, 2014 at 3:22 AM, Hallvord R. M. Steen  
wrote:
> Status of the Clipboard API spec: There are some open bugs. The test suite is 
> on its way into web-platform-test but there's no progress on the review AFAIK.
>
> Apart from those bugs I think the spec is quite solid. Here are the bugs:
> https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Clipboard%20API%20and%20events&resolution=---
>
> I'll comment on each to give a status update, please comment in the relevant 
> bugs if you have input or ideas:
>
...
>
> I'd like to get 21700, 23538, 27010 and 21698 addressed before a new WD. 
> Input from implementors and web developers is always welcome, of course.
> -Hallvord
>

Selection, Editing, User Intentions Meeting at TPAC

[Ben Peters]

[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 their direction for the next several months and work 
toward answers to open questions. Anyone interested is encouraged to attend on 
Monday October 27th at 15:00 in Santa Clara [4].
 
Ben

[1] http://www.w3.org/tr/selection-api/
[2] http://w3c.github.io/editing-explainer/
[3] http://w3c.github.io/editing-explainer/commands-explainer.html
[4] https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27

RE: [Editing] Tracking Issues in GitHub

[Ben Peters]

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 in Berlin we talked about creating a list of 
problems which we have with contenteditable, or more generally - when 
implementing editors. I started writing stuff down for such list. I've got 
things like what to do with bogus s (aka extraneous line breaks) or typing 
spaces at the end of blocks, standard way for getting range from point or even 
about nightmarish HTML in the clipboard. Do you think that this GitHub issues 
page is the right place for them?

On Tue, Sep 23, 2014 at 2:40 AM, Ben Peters 
mailto:ben.pet...@microsoft.com>> wrote:
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 our GitHub Issues 
page [1] to open new issues and comment on existing issues.

Ben

[1] https://github.com/w3c/editing-explainer/issues




--
Piotrek Koszuliński
CKEditor JavaScript Lead Developer

RE: [selection-api] Moving toward First Public Working Draft

[Ben Peters]

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 Working Draft

Publishing an FPWD sounds reasonable.

On Sat, Sep 20, 2014 at 9:52 PM, Arthur Barstow 
mailto:art.bars...@gmail.com>> wrote:
Hi Ryosuke, Ben, Kenji, All,

I'm looking for feedback about moving the Selection API [ED] to First Public 
Working Draft (FPWD) ...

A `rule of thumb` I generally use when considering if a spec is ready for a 
FPWD is if the feature set is mostly complete although there is no expectation 
all features are fleshed out in detail (IOW, looking for breadth mostly 
complete but not depth). The breadth question is important because a FPWD is 
also used as an "attorney snapshot" vis-à-vis the [PP]. Regarding the spec's 
open [Issues], there is no expectation a FPWD be bug/issue free (in fact, it 
would be rare if that was the case).

What are your thoughts about publishing a FPWD? Do you consider the latest ED 
to be feature complete; and if not, what major features are missing?

-Thanks, AB

[ED] http://w3c.github.io/selection-api/
[Issues] https://github.com/w3c/selection-api/issues
[PP] http://www.w3.org/Consortium/Patent-Policy/



--
Kenji BAHEUX
Product Manager - Chrome
Google Japan

[Editing] Tracking Issues in GitHub

[Ben Peters]

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 our GitHub Issues 
page [1] to open new issues and comment on existing issues.

Ben

[1] https://github.com/w3c/editing-explainer/issues

RE: User Intentions Explainer (was: List of Intentions)

[Ben Peters]

On Sat, Sep 6, 2014 at 1:54 AM, Johannes Wilm  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 "intentions". So say that we listen for
> CTRL+C to trigger our custom intention "checkGrammar" -- but the user's
> browser happens to use a locale where CTRL+C is the common standard for
> bold? Would it not be possible to create a new intention and bind it to
> CTRL+C unless that key combination is occupied already, in which case it's
> CTRL+L, etc.? Could there be a way to get all the key bindings defined for a
> given contenteditable=minimal area and their intentions? (to display in a
> help box, for example)

I think advanced things like custom localization will be out of scope, at least 
initially. This can be done by detecting languages and such. But we should keep 
it in mind.

> Also, would there be a way to bind intentions not just to key clicks but
> also to new items in the right click menu? An editor may want to use the
> internal spell checker, but add a custom thesauruses and a grammar checker
> to the menu. But maybe this is defined somewhere else?

This is something we should keep in mind, but probably won't be in our top 
priorities. If folks think it should be, we should include it though, so please 
give us feedback here.

RE: User Intentions Explainer (was: List of Intentions)

[Ben Peters]

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.

https://github.com/w3c/editing-explainer/issues/4 

On Mon, Sep 8, 2014 at 11:55 AM, Johannes Wilm  wrote:
>
>
>
> On Mon, Sep 8, 2014 at 6:05 PM, Frederico Knabben 
> wrote:
>
> 
>  
>>
>> IMHO, the following are the "minimal" features that it should provide:
>>
>> - Selection: UI (e.g. caret), creation (e.g. mouse) and modifications
>> (e.g. arrows)
>> - Focus (probably part of Selection, but it's so hard to make it right
>> that I'm listing it here to not stay forgotten)
>> - Input Text (typing)
>> - Insert New Line
>> - Delete / Backspace
>
>
> If we include deletion/backspace and input text, that will then also mean
> merging of paragraphs (and other nodes) when the caret is at the beginning
> of a second paragraph and the backspace key is being hit? Last I checked
> that was broken for example in Safari/Chrome (converting the HTML inside the
> two merged paragraphs from  into a mix of -tags and
> other outdated things).
>
>
> To me it's fine if inputting text/backspace is being included, as long as
> browser makers believe they will have the time and resources to fix the
> actual text editing part. That to me seems to be the most broken thing about
> the whole thing currently.
>
> If they on the other hand say they have no time for any of this (as not
> having fixed bugs in this area for some years might indicate) I would be OK
> with them leaving the input/deletion/undo history part out.
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org

RE: User Intentions Explainer (was: List of Intentions)

[Ben Peters]

I agree that we can divide this work, but so far I think we should do "2" 
first. Being able to remove browser functionality with a simple API is going to 
be far quicker to implement (in browsers) and provides immediate benefit. 
Solving Intentions will be a longer process, but is also important to really 
enable performance and "extensible-web" scenarios.

On Tue, Sep 9, 2014 at 4:28 AM, Piotr Koszuliński  
wrote:
> 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 may also take in consideration that there are limited resources
>> available for working on the specs. Therefore the whole work could be
>> separated into two *independent* topics:
>>  1. Intention events + execCommand.
>>  2. contenteditable=“minimal”
>
>
> That's what I was proposing as well - to have the base (which consists
> mainly of fixed selection API and intention events) ready as soon as
> possible, so hopefully browser makers can start implementing it and then we,
> editor makers, can start using it. This part will already improve the
> current situation a lot, but it's itself pretty hard as we can see. Then, if
> anyone will be still interested, a specification for default browser's
> actions can be created. It's a huge task and there are a lot of
> controversial topics like the famous delete/backspace behaviour when merging
> blocks and that's why I would not recommend starting these discussions right
> now.
>
>
>
> On Tue, Sep 9, 2014 at 12:59 PM, Frederico Knabben 
> wrote:
>>
>> On Tuesday, 9 September 2014 at 11:13, Frederico Knabben wrote:
>>
>> I don’t think that browsers having time/will for it today is a good
>> argumentation for not doing it. The specs have a critical and noble scope,
>> of serving as reference for the future of the web. We’re talking about the
>> future after all.
>>
>> 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 into two *independent* topics:
>>
>>  1. Intention events + execCommand.
>>  2. contenteditable=“minimal”
>>
>> “1” should be concluded asap, because it is the foundation for the success
>> of “2”. It is also compatible with the current contenteditable=“true”, so it
>> should enable sites/frameworks to fix the current status of things.
>>
>> “2” is the ideal world. Something that would require much more energy to
>> get done right. Still in the beginning, there should be an agreement on
>> what’s in and what’s out. Following that, several specs can get started,
>> each one defining the default behavior we want for each of the features we
>> want “minimal” to have. The first ofc, would be “Selection” (and “Focus”!).
>
>
>
>
> --
> Piotrek Koszuliński
> CKEditor JavaScript Lead Developer
> --
> CKSource - http://cksource.com
> --
> Follow CKEditor on: Twitter | Facebook | Google+ | LinkedIn

RE: [editing] Suggested selection.extend can not select based on how the text currently displayed

[Ben Peters]

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-US&redirectslug=DOM%2FSelection
 for reference. Thanks for the feedback!

Ben

From: e...@ictenablers.com [mailto:e...@ictenablers.com]
Sent: Wednesday, September 17, 2014 11:06 AM
To: public-webapps@w3.org
Cc: a...@aryeh.name
Subject: [editing] Suggested selection.extend can not select based on how the 
text currently displayed

Dear all,

My interpretation of the suggested selection.extend is that it can not select 
based on how the text is displayed. I'm thinking in particular of the feature 
to extend to the lineboundary, like this:

var selectionPoint = window.getSelection();

selectionPoint.modify('extend','backward','lineboundary');

Supported by most browsers (not IE) this could be used to for example select or 
highlight a line of text that the user clicks on.

This feature can have both practical and accessibility uses.



Best regards,

Erik

RE: User Intentions Explainer (was: List of Intentions)

[Ben Peters]

There is now an Editing Explainer [1] and a User Intentions Explainer [2], 
which should help scope the problems and help us drive forward on both areas. I 
haven't done much to fine tune them yet, but please let me know if you have 
feedback on this split from the initial Commands Explainer 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  wrote:
>
> 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 trajectory of creating these events 
> for Selection, Clipboard, Drag and Drop, Input (aka Editing), and perhaps 
> other user interactions. Are there objections to this approach? If not, I 
> will begin to adapt the Commands Explainer into a more generic Intentions 
> Explainer.
>

RE: [clipboard] Add RTF to the "mandatory data types" list?

[Ben Peters]

> From: Ben Peters
> 
> On Tue, Aug 19, 2014 at 10:08 AM, Daniel Cheng 
> wrote:
> >
> > On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen
>  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 necessarily mean we should not add it.
> >>
> >> I don't have "input" as such, but I have a few questions:
> >> Is there any widely used software that writes RTF data to the system
> clipboard but *not* HTML?
> >>
> >> If there's RTF on the clipboard and you try pasting into a rich text 
> >> editing
> element, does any browser convert RTF to HTML to preserve the formatting?
> >
> >
> > Chrome Mac should (though I've never tested this functionality). I think the
> code for this was inherited from Camino, so Firefox may have this as well. 
> It's
> not common--it's only implemented on Mac because there's some platform
> support already for parsing RTF into a NSAttributedString and then dumping
> the result as HTML.
> 
> Internet Explorer puts RTF on the clipboard during copy (as well as HTML,
> text, etc), so yes we should allow developers to access it.

Actually IE also supports converting RTF on the clipboard to HTML when pasted.

RE: [clipboard] Add RTF to the "mandatory data types" list?

[Ben Peters]

On Tue, Aug 19, 2014 at 10:08 AM, Daniel Cheng  wrote:
>
> On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen  
> 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 necessarily mean we should not add it.
>>
>> I don't have "input" as such, but I have a few questions:
>> Is there any widely used software that writes RTF data to the system 
>> clipboard but *not* HTML?
>>
>> If there's RTF on the clipboard and you try pasting into a rich text editing 
>> element, does any browser convert RTF to HTML to preserve the formatting?
>
>
> Chrome Mac should (though I've never tested this functionality). I think the 
> code for this was inherited from Camino, so Firefox may have this as well. 
> It's not common--it's only implemented on Mac because there's some platform 
> support already for parsing RTF into a NSAttributedString and then dumping 
> the result as HTML.

Internet Explorer puts RTF on the clipboard during copy (as well as HTML, text, 
etc), so yes we should allow developers to access it.

RE: User Intentions Explainer (was: List of Intentions)

[Ben Peters]

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 trajectory of creating these events 
for Selection, Clipboard, Drag and Drop, Input (aka Editing), and perhaps other 
user interactions. Are there objections to this approach? If not, I will begin 
to adapt the Commands Explainer into a more generic Intentions Explainer.

> -Original Message-
> From: Jason White [mailto:ja...@jasonjgw.net]
> Sent: Saturday, August 9, 2014 4:56 PM
> To: public-indie...@w3.org
> Cc: public-editing...@w3.org; public-webapps@w3.org
> Subject: Re: User Intentions Explainer (was: List of Intentions)
> 
> [Cross-posting the comments below per Janina's thoughtful request.]
> 
> I concur with Janina's insightful remark [at the Indie-UI teleconference on
> Thursday] that the "explainer" could evolve into a (potentially cross-group)
> requirements document. This raises several issues.
> 
> 1. Harmonization of terminology. We're already seeing differences between
> the terminology used by WEB Apps in connection with editing and our own
> terms for similar concepts, e.g., "abstract events" and "intentions". Naming
> conventions for events aren't harmonized either.
> 
> 2. Whether there should ultimately be one spec or several, and where the
> division should lie, is obviously up for discussion. Given the progress we've
> made to date, it makes good sense that support for interactive editing could
> reside in its own spec, with its own development schedule. This, after all, is
> work that we anticipated in Indie-UI but postponed.
> 
> 3. If there are two or more specs to be produced in this area, we should
> provide appropriate cross-references (perhaps a non-normative reference in
> each spec to the requirements would be sufficient), so that user agent and
> Web application implementors alike can readily appreciate the relationships
> between the technologies described in the respective documents.
> 
> My main concern at this point is that the designs be consistent and that
> terminology be unified wherever possible.
> 
> 

RE: [selection] Selection.setBaseAndExtent

[Ben Peters]

Interesting. I’ve noticed that setBaseAndExtent is used on gMail. Does it work 
basically like a ‘setAnchorAndFocus’ would (Base/Anchor and Extent/Focus are 
the same when set with this API, correct)?

From: Julie Parent [mailto:jpar...@google.com]
Sent: Wednesday, August 6, 2014 4:44 PM
To: Ben Peters
Cc: Ryosuke Niwa; James M. Greene; public-webapps
Subject: Re: [selection] Selection.setBaseAndExtent

For what its worth, we plan to remove base and extent from Blink/Chromium 
(https://code.google.com/p/chromium/issues/detail?id=230267).  We've found that 
developers do not understand 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 
mailto:ben.pet...@microsoft.com>> wrote:
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<mailto:rn...@apple.com>]
Sent: Wednesday, August 6, 2014 12:43 PM
To: James M. Greene
Cc: Ben Peters; public-webapps
Subject: Re: [selection] Selection.setBaseAndExtent

Focus and anchor are different concepts from base and extent. While the former 
always coincide with start and end, base and extent may be different from those 
two.

In particular, when a user selects text by double clicking on a word, base and 
extent stays at where the user had clicked while focus and anchor will extend 
to the beginning and the end of the word like start and end.

- R. Niwa

On Aug 5, 2014, at 4:58 PM, James M. Greene 
mailto:james.m.gre...@gmail.com>> wrote:

For consistent terminology with the rest of the API, shouldn't it be 
`setAnchorAndFocus`?

Sincerely,
James Greene
Sent from my [smart?]phone
On Aug 5, 2014 5:54 PM, "Ben Peters" 
mailto:ben.pet...@microsoft.com>> wrote:
I have added proposed text to this bug. Any objections to this?

Proposed text, based on the text for collapse():

void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node 
extentNode, unsigned long extentOffset);

The method must throw an IndexSizeError exception if offset is negative 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
To: Ben Peters; Ryosuke Niwa; 
public-webapps@w3.org<mailto:public-webapps@w3.org>
Subject: RE: [selection] Selection.setBaseAndExtent

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<mailto:public-webapps@w3.org>
Subject: [selection] Selection.setBaseAndExtent

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] 
http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse

RE: [selection] Selection.setBaseAndExtent

[Ben Peters]

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: [selection] Selection.setBaseAndExtent

Focus and anchor are different concepts from base and extent. While the former 
always coincide with start and end, base and extent may be different from those 
two.

In particular, when a user selects text by double clicking on a word, base and 
extent stays at where the user had clicked while focus and anchor will extend 
to the beginning and the end of the word like start and end.

- R. Niwa

On Aug 5, 2014, at 4:58 PM, James M. Greene 
mailto:james.m.gre...@gmail.com>> wrote:

For consistent terminology with the rest of the API, shouldn't it be 
`setAnchorAndFocus`?

Sincerely,
James Greene
Sent from my [smart?]phone
On Aug 5, 2014 5:54 PM, "Ben Peters" 
mailto:ben.pet...@microsoft.com>> wrote:
I have added proposed text to this bug. Any objections to this?

Proposed text, based on the text for collapse():

void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node 
extentNode, unsigned long extentOffset);

The method must throw an IndexSizeError exception if offset is negative 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
To: Ben Peters; Ryosuke Niwa; 
public-webapps@w3.org<mailto:public-webapps@w3.org>
Subject: RE: [selection] Selection.setBaseAndExtent

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<mailto:public-webapps@w3.org>
Subject: [selection] Selection.setBaseAndExtent

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] 
http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse

RE: [selection] Selection.setBaseAndExtent

[Ben Peters]

?This API is already used on the web so we should probably keep it as-is.



From: James M. Greene 
Sent: Tuesday, August 5, 2014 4:58 PM
To: Ben Peters
Cc: Ryosuke Niwa; public-webapps
Subject: RE: [selection] Selection.setBaseAndExtent


For consistent terminology with the rest of the API, shouldn't it be 
`setAnchorAndFocus`?

Sincerely,
James Greene
Sent from my [smart?]phone

On Aug 5, 2014 5:54 PM, "Ben Peters" 
mailto:ben.pet...@microsoft.com>> wrote:
I have added proposed text to this bug. Any objections to this?

Proposed text, based on the text for collapse():

void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node 
extentNode, unsigned long extentOffset);

The method must throw an IndexSizeError exception if offset is negative 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
To: Ben Peters; Ryosuke Niwa; 
public-webapps@w3.org<mailto:public-webapps@w3.org>
Subject: RE: [selection] Selection.setBaseAndExtent

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<mailto:public-webapps@w3.org>
Subject: [selection] Selection.setBaseAndExtent

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] 
http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse

RE: [selection] Selection.setBaseAndExtent

[Ben Peters]

I have added proposed text to this bug. Any objections to this?

Proposed text, based on the text for collapse():

void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node 
extentNode, unsigned long extentOffset);

The method must throw an IndexSizeError exception if offset is negative 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
To: Ben Peters; Ryosuke Niwa; public-webapps@w3.org
Subject: RE: [selection] Selection.setBaseAndExtent

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<mailto:public-webapps@w3.org>
Subject: [selection] Selection.setBaseAndExtent

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] 
http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse

User Intentions Explainer (was: List of Intentions)

[Ben Peters]

Cross-posted?: Editing TF, IndieUI TF, WebApps WG


In order to solve the broad issue of User Intentions, we have compiled below a 
list of User Intentions derived from all of the sources of intention-style 
events that I am aware of. I agree with Julie that some of the events below are 
not in scope for Editing at this time. However, they are in scope for IndieUI, 
and I think that we have an important opportunity here to bring all concepts of 
"Intentions" together in a single explainer document so that 1) web developers 
can have a coherent picture of how to understand User Intentions and 2) the 
specs that concern User Intentions do not overlap. To that end, I propose that 
we create a new User Intentions Explainer document, borrowing from the work of 
the Editing Explainer and IndieUI to give an overview of how all of the 
following Intention Events work together in a high-level non-normative form:

Clipboard API
HTML5 Drag and Drop
Selection API (beforeSelectionChange)
DOM Events (beforeInput)
IndieUI

Each of these specs solves some aspect of User Intentions, and they should be 
coherent. For instance, we need to solve how beforeInput does not overlap 
Clipboard and DnD, and consider moving some parts of IndieUI that apply to 
input (undo/redo) to beforeInput.

Further, I propose that we fine-tune the Editing Explainer, making it clear 
that there are two problems we're trying to solve in that space- Editing 
Intentions and Extensible Web Editing. From there we can begin to create 
normative specs for solving these two Editing problems.

The end result of this would be a high-level explainer for all known User 
Intention specs, and a high-level explainer for Editing. Then we can solve each 
individual problem more granularly while maintaining coherence. Thoughts?

From: Julie Parent 
>
> 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  wrote:
>>
>> We now have a good list of use cases on the Explainer[1]. I believe the next 
>> step is to come up with the Intentions that we need to allow sites and 
>> frameworks to respond to. After that, we can determine which current or new 
>> spec each Intention is covered by. Please let me know what you think of this 
>> list and if you agree it covers our use cases. The last several are borrowed 
>> from IndieUI[2], which we could use to cover those cases if we believe that 
>> is best.
>>
>> * Focus/place caret
>> * Move caret
>> * Start selection (eg mouse down to select)
>> * Update selection (eg mouse move during selection)
>> * Finish selection (eg mouse up after selecting)
>> * Modify selection (extend selection after it's finished. Might be covered 
>> by update/finish)
>> * Insert text
>> * Insert content / insert HTML
>> * Delete content
>> * Delete forward
>> * Delete backward
>> * Insert newline
>
>
> Do we need newline as a special case? Wouldn't this be covered by insert 
> text/content/HTML?
>
>>
>> * Undo
>> * Redo
>> * Paste
>> * Copy
>> * Cut
>> * Drag start/over/stop
>> * Drop
>> * Scroll/pan
>
>
>>
>> * Activate / Invoke
>>
>> * Expand
>> * Collapse
>> * Dismiss
>> * Media next/previous/start/stop/pause
>> * Rotate
>> * Zoom
>> * Value change
>
>
> Is this the set from indie-ui?  I think we should make a decision if we are 
> trying to cover these cases or not, as they do not make sense in the context 
> of rich text editing and might be out of scope.  It would help to have a list 
> of arguments for/against merging with indie-ui?
>
>>
>>
>> Ben
>> [1] http://w3c.github.io/editing-explainer/commands-explainer.html
>> [2] http://www.w3.org/TR/indie-ui-events/

RE: [clipboard] Semi-Trusted Events Alternative

[Ben Peters]

> -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 
> the
> names of things.
> 
> "semi-trusted" seems worse to me.  Reminds me of slightly-pregnant.  Its
> either one or the other.
> 
> It appears to me that isTrusted and semi-trusted are really trying to say "the
> user has not been fooled".  Which brings me back to my original question.
> What, precisely, are we afraid the user has been fooled into doing?
> 
> Thank you for your time,
> Perry

I agree with this. 'Semi-trusted' seems like a misnomer.

We need a way to understand that a user intended to copy/cut/paste for the 
given site. The argument that there is precedent here doesn't really seem to 
hold. Plugins have historically been a source of security issues, so saying 
that plugins allow this behavior doesn't really help. I still think we should 
try to figure out a model where the user knows what they're doing (like input 
type=file). Authors use that object because it's the way to get to files. If an 
'input type=clipboard' were the way to get to the clipboard, wouldn't authors 
use it? Surely we can come up with ways to style it to match website design 
without losing the clear intention of giving clipboard access.

RE: [clipboard] Semi-Trusted Events Alternative

[Ben Peters]

> -Original Message-
> From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
> 
> On Wed, Jul 23, 2014 at 12:17 AM, Ben Peters 
> wrote:
> > [1] http://www.w3.org/TR/clipboard-apis/#semi-trusted-events
> 
> "The default action of a synthetic paste event is to insert any data passed to
> the event constructor, if that data is suitable for the event target. If the 
> data
> type is not suitable for the event target, data must not be inserted."
> 
> Seems wrong. Why is that still in the editor's draft? Dispatching synthetic
> events should not cause actions.
> 
> 
> --
> http://annevankesteren.nl/

I agree. Why are synthetic events causing actions?

[clipboard] Semi-Trusted Events Alternative

[Ben Peters]

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 control+v or uses the 
context menu's 'paste' option). However, I don't really know if 'semi-trusted' 
events are the solution. Users will almost certainly be using the keyboard or 
mouse with websites, so requiring an event to originate from keyboard or mouse 
doesn't seem to make them trusted at all. I know there has been some discussion 
of removing them from the spec [2]. What is the status of that?

As an alternative to semi-trusted events, perhaps we should have something 
similar to input type="file"? Perhaps a new input type that must display a 
localized word for "cut", "copy", or "paste", and must not be occluded by any 
other element, could trigger real, trusted clipboard events? I'm not sure how 
this would work, but it seems worth a discussion at least.

Ben

[1] http://www.w3.org/TR/clipboard-apis/#semi-trusted-events
[2] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0086.html

{minutes} [editing] Conference Call July 11th 8am San Francisco Time

[Ben Peters]

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?

 9274

 janina_ code is 9274

thanks!

 scribe: janina

ben: schedule follows doc ...
 ... section 2in explainer overviews the problem to be solved
 ... notes this is his doc, welcoming comments
 ... ContentEditable is buggy, needs a fix
 ... full range of editing scenarios complicates this
 ... different expectations of editing, e.g. undo
 ... sites don't know specific actions from intent
 ... e.g. ctrl-a is select all
 ... these are the top two issues, we need to solve both
 ... if a browser implements an action, but site can't accept it, there's no 
way for the site to indiciate that
 ... so it's hard to understand what's implemented
 ... also difficult to create polyfills
 ... anyone to add anything here?

[crickets]

ben: we have wide range of cases around editing

 http://www.w3.org/TR/indie-ui-events/#RequestEvents
 
 ACTION: janina to forward URLs of IndieUI docs [recorded in 
http://www.w3.org/2014/07/11-webapps-minutes.html#action01]

 Error finding 'janina'. You can review and register nicknames at 
.

section 5 visualization

  http://w3c.github.io/editing-explainer/commands-explainer.html

ben: today actions and intentions are blurred today
 ... a11y tools often have to hack around to handle this
 ... main reason is that intentions are not clearly separatable from actions

cyns: is describing preferable default browser behavior in scope?

ben: perhaps, but needs to be stated more narrowly

cyns: I can help with alt texts for diags

ben: contemplating custom ui's for authors to define custom behavior
 ... enumerating behaviors for a11y tools is a goal
 ... has clipboard events, and also trying to figure out drag and drop
 ... working on word/char/etc selection
 ... and then concept called command events
 ... for editing our first task is solving selection
 ... want to begin with no default behavior in the editor
 ... phps exception is typing
 ... many sites already cancel default editing behavior

integrating with more web developers

ben: good feedback so far, want more participation

julie: was working with medium previous to this effort
 ... will contact them re this group

ben: also at ms

 Scribe: Janina

 ScribeNick: janina_

cyns: have internal wg in ms where there's a11y impact, can connect

next steps

julie: looking at 'before input' as well
 ... either 'before input' or command, both wouldn't make sense

integrating with indieUI

cyns: remember to look at overlap, include keyboard events in that

ben: might want to figure which indieui events already cover what's discussed 
here

Summary of Action Items
 [NEW] ACTION: janina to forward URLs of IndieUI docs [recorded in 
http://www.w3.org/2014/07/11-webapps-minutes.html#action01]
  
 [End of minutes]

[editing] Visualizing the benefits of user intention information

[Ben Peters]

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 understanding what a 
user is trying to do. Additionally, Accessibility Tools and other input 
modalities should be able to understand a user's intentions so they can list 
available behaviors and provide feedback to users about what has occurred." 

Note that this is only one part of what I see as the goal of this discussion. 
The other is providing the building blocks to create a wide range of editors in 
JavaScript.

Ben

[1] 
http://w3c.github.io/editing-explainer/commands-explainer.html#visualizing-user-intentions

RE: [editing] Conference Call July 11th 8am San Francisco Time

[Ben Peters]

The Editing Task Force will meet on July 11th 2014 for up to 60 minutes from 
15:00Z to 16:00Z.

http://timeanddate.com/s/2q3e

1. Go over the Explainer 
(http://w3c.github.io/editing-explainer/commands-explainer.html)
* Discuss problem (Section 2)
* Discuss use cases (Section 3)
* Discuss goals (Section 4)
* Integrating with IndieUI (Section 9)

2. Discuss potential solutions
* General shape of the solution 
* Provide the building blocks for complex editors
* Help sites both indicate and understand user intentions (Section 5)
* Potential Solution: Intention/Command Events

3. Next Steps:
* Integrating Web Developers
* Attracting interested parties
* IP Commitments
* Next steps for Explainer
* Moving docs forward on standards track

Dial-in Details:
Zakim Bridge +1.617.761.6200, conference 9274 ("WAPI")

IRC Chat (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 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 the recent goals and use cases to the explainer document
> between now and then. I will send an agenda 24 hours before the call.
> 
> Ben
> 
> [1] https://www.w3.org/Guide/1998/08/teleconference-calendar#s_6399

window.find deprecated?

[Ben Peters]

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 killed?

Ben

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=672395
[2] https://bugs.webkit.org/show_bug.cgi?id=64761 

RE: [editing] Use Cases (was: Leading with ContentEditable=Minimal)

[Ben Peters]

Great discussion on this! I have added these to the Explainer Doc[1]. Please 
let me know what you think of the list so far. I would also like discuss this 
in the meeting next Friday[2], so anyone that can come would be great!

Ben

[1] http://w3c.github.io/editing-explainer/commands-explainer.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0011.html

On Mon, Jun 30, 2014 at 10:33 PM, Johannes Wilm  
wrote:
>
>
>
> On Tue, Jul 1, 2014 at 4:39 AM, Ryosuke Niwa  wrote:
>>
>> On Jun 30, 2014, at 1:43 PM, Johannes Wilm 
>> wrote:
>>
>> On Mon, Jun 30, 2014 at 10:01 PM, Ryosuke Niwa  wrote:
>
>  
>>>
>>>
>>> Web-based DTP application: The app can creates a document that contains
>>> pagination, columns, and a complex illustrations.  It needs to let users
>>> edit any text that appears in the document.  Each editable text needs to be
>>> accessible, and styles applied to text need to be backed by the
>>> application's internal model of the document.
>>
>> Yes, but wouldn't this require some fragmentation logic? To create
>> something like what Quark Xpress was in the 1990s, I think you'd need CSS
>> Regions or equivalent. It seems as if that would be a little outside of the
>> scope of the caret moving logic, or how do you mean? I would find it great
>> if this ever happens, but as I understand it the whole fragmentation debate
>> was left aside for a while.
>>
>>
>> CSS regions is still shipped in iOS/OS X Safari, and I don't expect it to
>> go away anytime soon.  CSS columns support is still in Blink as well. 
>> Furthermore, I don't think CSS WG is halting the work on fragmentations
>> either.  We should still keep it as a use case for the new editing API.  In
>> addition, I would suggest that you go talk with people in CSS WG and add
>> your use case.
>
>
> Yes, I am aware of that. I spent a year creating a CSS Regions based book
> layout engine ( http://fiduswriter.github.io/pagination.js/ ) , so I am
> absolutely interested in fragmentation coming back one day. In the meantime
> I have created an ad-hoc solution using CSS columns (
> http://fiduswriter.github.io/simplePagination.js/simplePagination.html )
>
> The main difference is that the CSS fragmentation based version allows to
> combine it with contenteditable (text flowing from page to page while
> editing/writing it). Using Javascript/CSS multicolumns to create the same
> design means cutting up the DOM, so it has to be done after the text is
> written. We switched to this second approach when it became clear that CSS
> Regions would be removed from Chrome.
>
> The way we handle it is to let the user write the text in one large page
> with the footnotes off to the right. When the user hits CTRL+P, the current
> contents of the edited doc are copied, the original contents is hidden and
> the copied version is cut up into individual pages. By the time the user
> gets to the print preview, page numbers, headers, table of contents,
> footnotes, etc. have all been put in place. Fragmentation would be great to
> have, but for now I would already sleep much better if we would have a more
> solid selection/caret-moving base to build upon. 
>
>
>>
>>> Semantic HTML WYSIWYG editor for a blogging platform: The editor needs to
>>> able to add both semantic and visual annotation to the document as it will
>>> be published as a blog.  Headings are to be marked up with h1. h2, etc...
>>> and each acronyms, abbreviations, and so forth are marked up with respective
>>> HTML elements.  However, the editor also supports visual annotations such as
>>> bolding, italicizing, and enlarging text, each of which will be interpreted
>>> by the editor to respective underlying semantics in HTML.
>>
>> Yes, and in order to keep things consistent he may want to disallow
>> certain types of styling. A few years ago it was common to see people with
>> Joomla sites who just pasted the text into the editor after copying it from
>> a word processor. Each blog post therefore ended up having very different
>> styling.
>>
>>
>> Could you elaborate more on what kind of inline styling you're thinking
>> of?  And how and why you want to allow/restrict certain styles?  You're
>> providing us of really important information here, and I really appreciate
>> if you could give us more information here :)
>
>
> For example a blog may decide not to allow any inline-css styling. And to
> emphasize words they may only want to allow bold and italics, but not
> underline and not a combination of italics and bold on the same word.
>
> Of course visually this may be achievable using a lot of !important
> statements in a general css file for the page. But the contents will turn
> messy and if users copy  from a social media site to a word processor to a
> blog, and from there to another blog and then into their html-based email
> and then into another blog... things will end in disaster for certain at
> some point.
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org

[editing] Conference Call July 11th 8am San Francisco Time

[Ben Peters]

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 the recent goals and use cases to the explainer document 
between now and then. I will send an agenda 24 hours before the call.

Ben

[1] https://www.w3.org/Guide/1998/08/teleconference-calendar#s_6399

[clipboard] Clipboard API Mandatory Data Types

[Ben Peters]

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 haven't been around the group long enough to know all
the history, can someone help me clear these up?

text/uri-list :
This seems like a Windows specific data type. Does Mac or Linux have a
"OS clipboard format description" for this?

text/css, application/javascript, application/json :
What is the use case here? Why would there be code on the clipboard in
it's own format instead of just text/plain that happened to be code?

Separately, do we want to apply this to Drag and Drop as well?

Thanks!
Ben

[1] http://www.w3.org/TR/clipboard-apis/#mandatory-data-types-1

RE: [editing] Leading with ContentEditable=Minimal

[Ben Peters]

> -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 to take a step back and make sure we all agree on the problem, goals, and 
use cases, as Ryosuke has been pushing for. We have several different proposed 
solutions. Does it make sense to very clearly state all of this before we press 
on too quickly? I'm working on a draft now, and would like input. The list 
below takes a stab at it, but I'm sure there are others we should add and maybe 
some we don't need?

Problems:
* ContentEditable is too complex and buggy to be usable as-is
* ContentEditable does not easily enable the wide range of editing scenarios
* There are many ways to indicate user intentions and no clean way to 
understand them all
* Accessibility tools have difficulty understanding what actions are available
* Frameworks and sites may have difficulty understanding what is implemented, 
what should show up on toolbars and menus, and what needs to be polyfilled in 
editing scenarios

Goals:
* Make it easy to disable browser behavior in editing scenarios
* Make it easy to implement custom behavior with appropriate APIs
* Allow overwrite of behavior for a user intention from all actions that 
indicate that intention
* Enumerate available actions in a given context before and after javascript 
adds/modifies behavior

Use Cases:
* Create a js framework that enables a WYSIWYG editor and works the same in all 
browsers with little browser-specific code
* Use a js framework to insert a customized editor into an email client
* Use a js framework to insert a customized editor into a blog
* Use a js framework to insert a customized editor into a wiki
* Create a document editor that uses an HTML editor as a frontend but a 
different document model as a backend
* Empower complex editors to be accessible by enabling users to understand 
available behaviors with little accessibility-specific work from the framework 
or site

RE: [editing] Changing Default Intentions

[Ben Peters]

On Fri, Jun 20, 2014 at 8:28 PM, Ryosuke Niwa  wrote:
> This means execCommand is available for other uses. Since it's a legacy API 
> that doesn't have the best shape, perhaps it is best to tie it to the legacy 
> behavior. So the image [1] now shows that execCommand (lower right) would 
> cause the browser to actually perform the command, not fire a CommandEvent. 
> In effect, execCommand('bold') is the default behavior for CommandEvent type 
> bold in contentEditable="true". In contentEditable="minimal" or equivalent, 
> CommandEvent type bold has no default. If a site wishes to use the built-in 
> bold, they can call execCommand('bold') in the CommandEvent, thereby 
> restoring contentEditable="true" behavior for that specific command.
>
>
> execCommand not triggering command event seems like a promising approach.  I 
> think we really need a concrete list of use cases here though.  It's hard to 
> design & evaluate proposals without having a list of concrete use cases 
> against which we're evaluating proposals.

Agreed. Better use cases and goals is my next project. Expect an update soon.

RE: Editing with native UI (was: [editing] CommandQuery Object and Event)

[Ben Peters]

> 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
> >  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
> >> and implementing our own logic. So the easiest solution to the
> >> problem with irrelevant native UI is to not display it at all.
> >
> > You may not need native UI working at all in your app, but that
> > doesn't mean all other developers don't want it at all.  Furthermore,
> > enabled-ness of items in desktop browser's edit menu should reflect
> > the current state of the editor; otherwise, it would degrade the user
> > experience.
> >
> > Furthermore, we shouldn't design our API only for existing platforms.
> > We need to make it so that new, completely different paradigm of UIs
> > and devices could be built using new API we design.
> >
> > Another important use case for browsers to know the state of the
> > editor is for accessibility.  AT may, for example, want to enumerate
> > the list of commands available on the page for the user.
> 
> All of these are good points, but the fact remains that if a browser 
> unilaterally
> decides to exposes a new editing behaviour that I as author don't know
> about, it could very easily break my script.
> 
> Also, if the browser includes a "bold" command by default and I don't
> support bolding and therefore cancel the event, the user who has been
> relying on the native UI is getting the worst possible experience:
> native controls that do nothing at all.

This doesn't seem like an insurmountable problem. We can provide a way for 
sites to indicate that they support certain commands and not others, similar to 
queryCommandEnabled(), which has a return value that could be modified by 
javascript (perhaps by an event, say QueryCommandEvent). Then the browser could 
choose not to show buttons for commands that are disabled.

> Conversely, if I support something that the native UI does not expose (say,
> superscripting) it makes for a weird UI in which some things are exposed and
> others aren't.

Good point.

> There is an option that:
> 
>• Can be styled in the page according to author wishes.
>• Can interact with native controls.
>• Can integrate with accessibility.
> 
> It relies on using all bits of new stuff in HTML: commands, contextMenu, and
> friends. I would *strongly* suggest that contentEditable=minimal would
> *only* have native UI based on things specified with this and not anything
> else by default. Native UI atop custom editing is really a solution for 
> breakage.
> 
> We can also make it smart and able to tap into higher-level intention events
> such as knowing the platform's localised shortcut for a given action.
> 
> --
> Robin Berjon - http://berjon.com/ - @robinberjon

[editing] Recurring Call (was: Best Time for Recurring Call)

[Ben Peters]

This call has now been reserved [3] for Friday at 8am San Francisco Time. It 
will not be used every week, but only as needed. In order to allow maximum 
participation, please make a request on this list 1 week prior to the call time 
whenever a call would be valuable. Thanks!

Ben

[3] https://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 for future 
> calls,
> though it will likely not be used every week. If you are interested in
> participating, please fill out the Doodle poll below to indicate what times
> work best for you. The poll contains Pacific Daylight Times 8-10am and 5-6pm
> (converter available [2]), Monday-Friday. Ignore the specific dates because
> the call will be used as-needed for any given week, with at least 48 hours
> advance notice (typically 7 days). This poll 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=1&lid=5391959,5128581,2950159,1850
> 147&h=2950159

RE: [editing] Leading with ContentEditable=Minimal

[Ben Peters]

On Tue, Jun 17, 2014 at 4:50 PM, Olivier F  wrote:
> On Tue, Jun 17, 2014 at 1:44 PM, Julie Parent  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
>> they can show multiple cursors for collaborators and control selections
>> entirely the way they want.
>
> OK, I can see that. 
>
> Would commandEvents=true fire cursor movement intents? Or is that strictly a
> byproduct of setting cursor=true? I can imagine pages that use
> commandEvents=true would want those events too.
>
> Maybe setting cursor=true only draws the cursor when the Element is focused
> and moves it around according to default behavior without firing events. But
> if the page wants to control that behavior they set commandEvents=true and
> cursor=true to intercept and prevent default cursor movements?
>  

A cursor is just a type of selection. It happens to not show up in non-editable 
content, but if it's there, it will fire Selection events just like any other 
selection. So commandEvents=true is not needed here.

RE: [editing] Leading with ContentEditable=Minimal

[Ben Peters]

On Tue, Jun 17, 2014 at 8:47 AM, Piotr Koszuliński  
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 events and rich command events.
>
> Examples:
> * user intent events - insert character (typing), move caret left, delete a
> letter, delete a word, insert paragraph break (enter/return), insert line
> break (shift+enter/return), etc. Additionally there are clipboard, undo and
> drag and drop events separated already, but they fall into this category.
> * rich command events - bold, indent, make numbered list, link, enable
> objects resizing, enable automatic quotes.
>
> At some point there were all included in the "command events" and in my
> opinion this started the confusion. User intent events are crucial for
> contentEditable=minimal, when rich command events may be useful for some
> better internationalization, but are not crucial (if browser does not try to
> do too much), because they usually are triggered by keystrokes.

Why does it matter if there are 'basic' events like typing and 'rich' events 
like bold? If you only care about the 'basic' ones, you can just respond to 
those and ignore the rest.

> 2. Commands versus command events. These are separate things again for me -
> cE=minimal needs events, but does not need commands and entire
> execCommand/queryCommandState/Value/etc combo. A link command event may be
> fired when browser thinks that user wants to make a link even if there's no
> default action bound to that event.

I agree that CE min would only have the events, not the default actions. I 
updated the explainer below with a more complete table in section 3.1. 
CE="true" would have default actions.

http://w3c.github.io/editing-explainer/commands-explainer.html 

RE: [editing] Leading with ContentEditable=Minimal

[Ben Peters]

On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent  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 "what
> does it do?" than contentEditable="minimal".  What does cursor="true" do? It
> turns on the ability for the user or developer to place a cursor, and
> default movement.  It has nothing to do with dom modification.  What does
> commandEvents="true" do? It enables dispatching commandEvents.  No
> ambiguity.  However, this does make me think again about using
> beforeinput/input events rather than adding new CommandEvents, since those
> would include drag/drop and clipboard as well?

The way I see it is that not editable at all would get clipboard and 
drag/drop events, like it does today. build an editor 
here would also get CommandEvents.

RE: [editing] Leading with ContentEditable=Minimal

[Ben Peters]

On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent  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?

> I think this leads us back to the question of what would 
> contentEditable='minimal' do exactly?  Enable collapsed selections and 
> default handling of cursor movement ... anything else? 

Yes we need to define this default functionality. What does everyone think 
about this?

> If this is all it would do, then perhaps what we really want is an explicit 
> API to enable cursors?

I think we should still think of this as a path to a full story that includes 
Intention events. Are you saying that ultimately we would have something like 
this?

minimally editable content

Like all other content, this would also get drag/drop, clipboard, and selection 
events. We would need 3 specs for this- Selection API, minimal editing 
(cursor-only editing?), and CommandEvent.

[editing] Leading with ContentEditable=Minimal

[Ben Peters]

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 
sense. I lean in the direction of the former, but there is another 
consideration- it will take more time to design and build Intention events in 
all cases, so why not work toward making contentEditable=minimal available, and 
then ship Intention events once we have a more complete story ready?

RE: [editing] CommandEvent and contentEditable=minimal Explainer

[Ben Peters]

On Fri, Jun 13, 2014 at 1:01 AM, Ryosuke Niwa  wrote:
>> On Jun 12, 2014, at 5:07 PM, Olivier F  wrote:
>>
>> I have been reading this and have a comment:
>> http://w3c.github.io/editing-explainer/commands-explainer.html
>>
>> "Issue 11: We may not need contentEditable=minimal. The same thing can be 
>> accomplished by listening for commands and calling preventDefault on all of 
>> them."
>>
>> I think we need contentEditable=minimal even if it is theoretically possible 
>> to listen to all commands and preventDefault on them.
>>
>> Listening to all events and preventing their defaults has the following 
>> implications:
>> - All CommandEvents and other things that can modify the state of the 
>> contents in our cE actually do fire events.
>> - We are actually able to enumerate all events that could potentially modify 
>> the state of our contentEditable.
>> - All of these events can be preventDefaulted.
>>
>> Given the transient nature of specs, implementations, and bugs I have a hard 
>> time believing that the theory that we can just listen to everything and 
>> prevent defaults has merit in practice. 
>>
>> One can easily imagine that some features provided by the UA won't fire 
>> events. Or, no need to imagine: just look at "undo" called from context menu.

The goal of Commands is to allow sites to get a CommandEvent with type "undo" 
for just this scenario.

>> Imagine as well a situation where a UA creates a new way to paste content, 
>> and to prevent confusion with "paste" they decide to create a new 
>> ua-prefixed event "uaMagicPaste". Now our end-users have a  way of pasting 
>> content into our editor's DOM without any intervention at all on our end, 
>> resulting in breakage and bugs.

This is a good point. Registering for and calling preventDefault() on 
CommandEvent and BeforeSelectionChangeEvent will catch all new events in those 
categories, but ClipboardEvents must be listened to individually (Cut, Copy, 
Paste). We should consider whether we disallow new ClipboardEvent types or 
allow a generic ClipboardEvent listener, which would catch uaMagicPaste. I'll 
add a note to the Explainer for this.

>> In practice, if we are left with the burden of listening to all events and 
>> preventing defaults we are left in very much the same situation we're trying 
>> to get away from.
>>
>>
>I don't have a strong opinion either way.  However, can't you just whitelist 
>the list of commands you allow and cancel everything else instead for this 
>specific case?  I guess you're concerned that it'll make things worse in some 
>cases (e.g. new builtin browser features maybe disabled)?
>- R. Niwa

Ryosuke's idea here is the same as mine. Listen for CommandEvent, 
BeforeSelectionChangeEvent, and ClipboardEvent (if that becomes possible), and 
preventDefault() on them. That will block all current and future functionality 
that is provided by contentEditable.

[editing] Best Time for Recurring Call

[Ben Peters]

Hello Web Apps,

Our recent call [1] regarding HTML Editing (contentEditable, CommandEvent) was 
quite valuable. It seems valuable to have a time reserved for future calls, 
though it will likely not be used every week. If you are interested in 
participating, please fill out the Doodle poll below to indicate what times 
work best for you. The poll contains Pacific Daylight Times 8-10am and 5-6pm 
(converter available [2]), Monday-Friday. Ignore the specific dates because the 
call will be used as-needed for any given week, with at least 48 hours advance 
notice (typically 7 days). This poll 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=1&lid=5391959,5128581,2950159,1850147&h=2950159

RE: [editing] CommandQuery Object and Event

[Ben Peters]

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 today since 
you can't respond to it, but once you have CommandEvents you'll be able to 
treat a bold button just like control+b by listening for a bold event. We are 
also working on coming up with a way (currently called CommandQuery Event [1]) 
to enable browsers to determine which commands are available, which would help 
browser UI display correctly and would also help accessibility tools tell users 
what they can do. Simply removing browser toolbars doesn't mean there are no 
other ways to interact with a page that users expect to work- take 
shake-to-undo in iOS for example.

[1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0791.html

On Mon, Jun 9, 2014 at 6:50 AM, Piotr Koszuliński  
wrote:
> I don't want to say that these options should never be added. I don't also
> want to say that they should be first standardised, then implemented (though
> that would be perfect of course) or that they should be now dropped
> (backward compatibility is a requirement I understand very well). My point
> is that we would need to take all this into account when thinking about
> fixing contenteditable=true. It must stop be surprising and unpredictable
> for developers. That I think should be our goal - to make it predictable and
> controllable.
>
> There are two paths to achieve this goal:
>
> 1. Make all what's already implemented controllable, or at least possible to
> disable.
> 2. Start from scratch (meaning contenteditable=minimal as an option, not as
> a concept).
>
> When the first option seems to be tempting I still believe it's not the
> right way. It will force us to think about all the crazy stuff like native
> toolbars, fonts, transformations, text direction, automatic substitutions,
> ability to add new options, setting icons, a11y, localisable labels for new
> options etc. All these things are complicated just by themselves and besides
> them we still need to fit input or intent events, commands, their states,
> etc. Even if we'll focus only on making all these controllable (without
> defining expected behaviour) then we'll have to solve problems like - should
> a command be executable if I disabled it? No? What if I want to remove that
> option from native context menu/toolbar but reuse the implementation?
>
> That's why I think that the second option is better. Contenteditable=minimal
> should not only be a concept - we need an option. Option which will allow
> us, while creating a spec, to forget about legacy features and not care
> about backward compatibility (which will be left in form of
> contenteditable=true). In a shorter period we'll be able to come out with a
> solution to at least part of the current problems and the solution should
> also be cleaner. Otherwise, I'm afraid that the new spec will end like the
> old one did.
>
> Simultaneously, contenteditable=true will still be usable. In use cases not
> satisfied by contenteditable=minimal developers will be able to use
> contenteditable=true. Moreover, there will be a possibility to "backport"
> features (like APIs and maybe command events) to contenteditable=true. But
> the primary goal should be to make contenteditable=minimal useful, not to
> enrich contenteditable=true.
>  
>
> --
> Piotrek Koszuliński
> CKEditor JavaScript Lead Developer

RE: CommandEvent for user intentions

[Ben Peters]

> 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 for selectionchange, and seems like the right place and
> >>> timing to work this in?
> > My current thought is that Selection events should be used for
> > selection, and CommandEvent for things that would be in a toolbar or
> > context menu. I think the design should make it easy to create and
> > style toolbars based on the available commands and their state.
> 
> Right. I agree with the architecture you described at the beginning of the
> thread, but I was a bit worried about your usage of a "select-all"
> command event as an example.

You're right, that was confusing. We have since updating our thoughts to use 
BeforeSelectionChange for this.

> There are many, many ways of affecting selection that vary across tools and
> locales, and representing all of them would IMHO be painful.
> 
> Do you ever need a select-all event? I would think that a selection change
> event that happens to give you a selection object containing everything
> might suffice? (Which sort of seems to be what you're saying here — hence
> checking where you stand.)

I think we may want to give both the user intent (select all) and the browsers 
interpretation of that intent (the range representing the expected selection).

[selection] extend() behavior when there is no range needs to be clarified

[Ben Peters]

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
> 
> Bug ID: 26005
>Summary: Selection.extend behavior when there is no range needs
> to be clarified
>Product: WebAppsWG
>Version: unspecified
>   Hardware: PC
> OS: Windows NT
> Status: NEW
>   Severity: normal
>   Priority: P2
>  Component: Selection API
>   Assignee: rn...@webkit.org
>   Reporter: benj...@microsoft.com
> QA Contact: public-webapps-bugzi...@w3.org
> CC: benj...@microsoft.com, public-webapps@w3.org
> 
> Today, the Selection API spec seems to say that if selection.rangeCount is 0,
> then selection.extend should throw an error and abort. This is true in 
> Firefox,
> but not Chrome. In Chrome, it appears that a new collapsed range is created
> at the position specified in selection.extend. Without an error, it's 
> possible a
> site might end up creating a selection when they think they're extending it.
> But errors in JS should be used sparingly. Not sure which of these makes
> more sense.
> 
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

RE: [editing] CommandQuery Object and Event

[Ben Peters]

> 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, would an attribute really help us save computation? 
Maybe we should be able to get the status of several commands at once with the 
event? Something like this (just thinking out loud here)?

Document.queryCommands('bold', 'italic', 'underline', 'undo')

> Also, we should talk with people working on Indie UI
> (http://www.w3.org/WAI/IndieUI/).  The problem we're solving here is very
> similar to the one they're trying to solve.

Absolutely! This has been in the back of my mind for a while. Do you know what 
would be the best way to involve them? Are some of them in both working groups?

[editing] CommandQuery Object and Event

[Ben Peters]

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, 
there are several ways to ask the browser if a given command is 
enabled/relevant. This includes queryCommandEnabled, queryCommandSupported, and 
QueryCommandValue. However, the site is not able to influence the return value 
of these events. In order to give more power to browsers, frameworks, and 
sites, it seems to make sense to allow these values to be modified. Therefore I 
propose a new method:

document.queryCommand()

which returns a new read-only object (called CommandQuery for now):

CommandQuery
{
Boolean isSupportedByUA;
Boolean isSupported;
Boolean isEnabled;
Object currentValue;
}

By default, this object will match the browser's support for this command in 
the current context. However, before it returns, a CommandQuery event will fire 
with a read/write CommandQuery object. If a framework or site wishes to 
indicate different values for the command state, it can do so in that event.

CommandQueryEvent: Event {
{
CommandQuery commandQuery;
}

In this way, a framework can enable commands that a browser does not natively 
support. Further, a browser could fire CommandQueryEvents to determine the 
correct toolbar buttons to display. Thoughts?

Ben

Editing Conference Call June 6th

[Ben Peters]

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 before the call. Sorry for 
the late notice- any future calls on this subject will have more advanced 
notice. ?Your participation is welcome and encouraged. Thanks!


Ben


[1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0582.html

RE: contentEditable=minimal

[Ben Peters]

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: 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
> >>>> haven't used them in anger and they aren't supported much.
> >>>
> >>> My thought is that we can use CommandEvent with type="insertText".
> >>> This would be the corollary to execComamnd("insertText"), and the
> >>> data would be the ñ that is about to be inserted.
> >>
> >> But if you only get one event you can't render the composition as it
> >> is carrying out.
> >
> > I believe Composition Events are very important for IME input, but we
> > should fire CommandEvent with Insert text for all text input,
> > including IME. Are you saying we should use Composition Events even
> > for non-IME input?
> 
> I am not using an IME, and yet I could not type in French on my keyboard
> without composition.
> 
> Obviously, if I switch to Kotoeri input, I'll get composition *and* an IME
> popup. But for regular French input (in a US keyboard) I need:
> 
>é -> Alt-E, E
>è -> Alt-`, E
>à -> Alt-`, A
>ô -> Alt-I, O
>ü -> Alt-U, U
>ñ -> Alt-˜, N (for the occasional Spanish)
>(and a bunch more)
> 
> Some older apps (you pretty much can't find them anymore) used to not
> display the composition as it was ongoing and only show the text after
> composition had terminated. That was survivable but annoying, and it only
> worked because composition in Latin-script languages is pretty trivial (except
> perhaps for all you Livonian speakers out there!), but I don't think it would 
> be
> viable for more complex compositions. And even in simple cases it would
> confuse users to be typing characters with no rendering feedback.
> 
> Without composition events you can't render the ongoing composition. See
> what's going on at:
> 
> 
> https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-
> L81
> 
> That is basically inserting text in a range that's decorated to be underlined 
> to
> show composition in progress. Composition updates
> *replace* the text in the range. And at the end the range is removed and
> text is inserted.
> 
> The above is for Mac, but I have distant memories of using something similar
> on Windows called the "US International Keyboard" where you could have
> apostrophes compose as accents, etc.. I don't recall how it was rendered
> though.
> 
> --
> Robin Berjon - http://berjon.com/ - @robinberjon

RE: contentEditable=minimal

[Ben Peters]

> 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 something capturing information more along those lines:
> 
> BeforeSelectionChange
> {
>oldRange:  [startNode, startOffset, endNode, endOffset] , newRange:
> [startNode, startOffset, endNode, endOffset] }
> 
> 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 contain
> something unselectable, isn't outside a given boundary, etc.).
> 
> The former requires getting a lot of details right in the spec, and those 
> would
> become hard to handle at the script level. On some platforms a triple click 
> (or
> some key binding) can select the whole line. This not only means that you
> need direction: "both" but also that the script needs a notion of line that it
> has no access to (unless the Selection API grants it). What makes up a "word"
> as a step also varies a lot (e.g.
> I tend to get confused by what Office apps think a word is as it doesn't match
> the platform's idea) and there can be interesting interactions with language
> (e.g. is "passive-aggressive" one word or two? What about "co-operation"?).
> 
> But maybe you have a use case for providing the information in that way that
> I am not thinking of?

This seems like it's getting pretty close to the browser just doing the 
selection. A browser would still have to figure out what the selection should 
look like in the version you suggest. Instead, maybe each site could decide 
what is thinks is a word ("passive" or "passive-agressive"). The line example 
is good, so maybe we should have a 'line' level selection just like the 'word' 
level?

> >> Not all of those are separate, though. Voice input is just an input
> >> (or beforeinput) that's more than one character long. There's nothing
> >> wrong with that. So is pasting (though you need cleaning up).
> >> Composition you need to handle, but I would really, really hope that
> >> the platform gives you a delete event with a range that matches what
> >> it is expected to delete rather than have you support all the
> >> modifiers (which you'll get wrong for the user as they are platform
> >> specific). As seen in the code gist I posted, given such a delete
> >> event the scripting is pretty simple.
> >
> > I agree, except that I don't know why we want paste to fire two
> > 'intention' events (paste and input). Seems like we should make it
> > clear that the intention is insert text (type, voice, whatever),
> > remove text (delete, including what text to remove), or paste (so you
> > can clean it up).
> 
> I don't think we want to fire both paste and input, but if my reading is 
> correct
> that is the case today (or expected to be — this isn't exactly an area of high
> interop).

Yes my understanding is that today you get both. I'm not arguing against that 
as the events stand today, but when we talk about 'Intention Events' as an 
abstract type with certain properties like commandName, I think you should only 
get one of those (paste or command or beforeinput), and I'm suggesting that it 
should be paste in this case.

Ben

RE: [editing] CommandEvent and contentEditable=minimal Explainer

[Ben Peters]

I don’t think we need to specify the default behavior. We can instead just say 
that all editing behaviors must fire Intention events that are cancellable. Any 
events that are already defined (like Clipboard) will continue to work, and 
others should fire CommandEvents as necessary.

We will likely need to have a list of well-known Command Events (like bold, 
undo, etc) just so we can have a shape for the related CommandData object, but 
we don’t need to specify the default behavior of those events.

From: Piotr Koszuliński [mailto:p.koszulin...@cksource.com]
Sent: Wednesday, May 28, 2014 2: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 
that the goal of contentEditable=minimal is to avoid the need to write a 
specification for contentEditable=true. Otherwise, developers may demand from 
browser vendors that they fix their contentEditable=true implementations and I 
don't think that anyone wants that. Why not forget about contentEditable=true, 
make it deprecated and create specification only for algorithms needed by 
contentEditable=minimal and all required command events?

On Wed, May 28, 2014 at 10:39 PM, Ben Peters 
mailto:ben.pet...@microsoft.com>> wrote:
Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.com<mailto:jpar...@gmail.com>]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.org<mailto: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.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, "minimal" is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable="true" is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable="minimal" be equivalent to:

// Let editRegion be 

var editRegion = document.getElementById("editRegion");
editRegion.addEventListener("command", handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable="minimal" on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters mailto:ben.pet...@microsoft.com>>
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: "public-webapps@w3.org<mailto:public-webapps@w3.org>" 
mailto:public-webapps@w3.org>>


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 is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm




--
Piotrek Koszuliński
CKEditor JavaScript Lead Developer

RE: [editing] CommandEvent and contentEditable=minimal Explainer

[Ben Peters]

Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.com]
Sent: 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.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, "minimal" is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable="true" is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable="minimal" be equivalent to:

// Let editRegion be 

var editRegion = document.getElementById("editRegion");
editRegion.addEventListener("command", handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable="minimal" on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters mailto:ben.pet...@microsoft.com>>
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: "public-webapps@w3.org<mailto:public-webapps@w3.org>" 
mailto:public-webapps@w3.org>>


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 is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm

RE: contentEditable=minimal

[Ben Peters]

> 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 should handle touch screens.
> 
> 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 way to do this would be BeforeSelectionChange having a commandType 
indicating select forward and select by word.

> > But we should definitely fire events whenever cursor or selection is
> > moved and enable the page to either cancel the movement, or adjust the
> > location before it takes effect.
> 
> Agreed. I also think that it is important that if the selection is allowed to 
> have
> anchors both inside and outside the editing area then the editing MUST NOT
> retain focus. Anything else would lead to really annoying cases.
> 
> Note: you keep saying things like "cursor or selection". Can we agree that
> they are the same thing? A caret on its own is a selection with a single
> collapsed range (and a direction).

Yes please:) Cursor and selection are the same thing.
 
> > I think there might be a lot of boiler plate needed to implement
> > plaintext editing. Not only are there normal "beforeinput" events to
> > take into account. There's also things like composition events,
> > backspace vs. delete, modifier+backspace/delete (deleting a
> > word/line), voice-to-text input (provides data word-by-word), pasting,
> > (bidi?), etc. It adds up pretty quickly.
> 
> Not all of those are separate, though. Voice input is just an input (or
> beforeinput) that's more than one character long. There's nothing wrong
> with that. So is pasting (though you need cleaning up). Composition you
> need to handle, but I would really, really hope that the platform gives
> you a delete event with a range that matches what it is expected to
> delete rather than have you support all the modifiers (which you'll get
> wrong for the user as they are platform specific). As seen in the code
> gist I posted, given such a delete event the scripting is pretty simple.

I agree, except that I don't know why we want paste to fire two 'intention' 
events (paste and input). Seems like we should make it clear that the intention 
is insert text (type, voice, whatever), remove text (delete, including what 
text to remove), or paste (so you can clean it up). 
 
-Ben

RE: contentEditable=minimal

[Ben Peters]

> -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 supported much.
> >
> > My thought is that we can use CommandEvent with type="insertText".
> > This would be the corollary to execComamnd("insertText"), and the data
> > would be the ñ that is about to be inserted.
> 
> But if you only get one event you can't render the composition as it is
> carrying out.
> 

I believe Composition Events are very important for IME input, but we should 
fire CommandEvent with Insert text for all text input, including IME. Are you 
saying we should use Composition Events even for non-IME input? 

RE: contentEditable=minimal

[Ben Peters]

> -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, 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 reason for the latter is that when
> >> selecting a line with multiple embedded directions (using a mouse),
> >> you want to have the visual selection be an unbroken line (as opposed
> >> to the crazy jumping around you get if you follow logical order).
> >
> > 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
> that this was presented along the lines of "we've had regular requests to
> support selecting text in geometric rather than logical orders".
> 
> If that turns out not to be the case and we can stick to single-range 
> selections,
> it would certainly make the Selection API simpler.
> 

I have also heard these requests from the bi-directional experts here at 
Microsoft. A single, unbroken selection is what we're told users want, and 
multi-selection makes this possible.

RE: contentEditable=minimal

[Ben Peters]

>>> 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
>>forbid browsers to bring up the virutal keyboard, which is a form of
>>"native UI". And the spellcheck UI that safari displays also doesn't
>>seem bad if spellchecking is enabled.
>>
>>And UI for cut/copy/past that android renders seems good to render
>>*somewhere* when there's selection.
>
>On iOS the contextual toolbar not only contains copy/cut options which are of 
>course ok, but it also contains bold, italic and lists buttons. That's 
>unacceptable and I assume this kind of native UI will not be implemented for 
>cE=minimal.

The goal of Command Event is to make this a non-issue. If sites respond to 
bold/italic/list commands they can handle this UI just fine. Are you concerned 
that a site may not use bold so the button would have no effect?

[editing] CommandEvent and contentEditable=minimal Explainer

[Ben Peters]

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 is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm

RE: contentEditable=minimal

[Ben Peters]

> 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 Alt-N the DOM is modified to
> include a U+02DC SMALL TILDE (note: *not* U+0303 COMBINING TILDE) and
> that character is underlined in the rendering to let me know that it is 
> awaiting
> a character to combine with. Interestingly, that information is not reflected 
> in
> the DOM — I don't even know how you can handle it. In fact, editors that try
> to take over too much from the platform (in this case, Substance for instance)
> completely fail to allow this sort of text entry.
> 
> At completely the other end of the spectrum (more or where developers
> find themselves today when they override as much as they can, out in the
> cold), all you get are two entirely independent keyboard events: one N with
> altKey set to true, and another N with altKey set to false.
> 
> Unless you know all platform conventions (plus the user's keyboard
> layout) or you manage to enforce your own, which isn't friendly to users, you
> can't do anything useful with that.
> 
> What I meant by having the browser handle text input, is that it needs to
> know the platform conventions so as to convey user intent to to the
> application correctly. When I hit Alt-N then N, the UA should relay something
> that looks like the following events (I'm deliberately not including
> keyup/down/etc. for simplicity):
> 
> compositionstart \u0303 (combining tilde) compositionupdate ñ
> compositionend ñ
> 
> (We might be able to do without the compositionupdate in this case, I'm
> including it because for more elaborate compositions it's needed.)
> 
> I believe that this provides the appropriate level of abstraction to address 
> the
> use case. Without the composition events (e.g. if you only send a text input
> event) the developer can't show the composition in progress to the user
> (which for complex compositions like Kotoeri is a non-starter); and with
> these events developers don't need to know about the platform's
> conventions for composition. Orthogonality is where it should be.
> 
> 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". This would 
be the corollary to execComamnd("insertText"), and the data would be the ñ that 
is about to be inserted.

RE: CommandEvent for user intentions

[Ben Peters]

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 
> a way that both are interoperable. Command events should be an extension to 
> cE=minimal making it possible to create advanced solutions on top of it. 
> Therefore, it may be beneficial to discuss both of them in one thread.
>
> But for now, here are some additional thoughts which I haven't included in 
> the email about cE=minimal.
>
> 1. It should be possible to modify selection and DOM in a command event 
> listener, but leave the action to the browser. Browser should perform the 
> action on the updated selection and DOM. Example - I want to transform "* " 
> to a list when user types additional character. So I would listen to keyboard 
> event, check if two previous characters are "* ", replace them with a list 
> and place selection inside . But I want browser to perform character 
> insertion so I don't have to handle undo manager, scrolling to show caret, 
> etc. There are of course other ways to achieve the same, but this seems to be 
> the cleanest.

Yes this is an important concept. In CommandEvent, you should be able to modify 
the behavior and then not call preventDefault. This will allow the browser to 
perform the action with new data.

> 2. It's not totally necessary, but it would be nice if command event would 
> also carry an information about its future result. For example command fired 
> for up-arrow key could carry a range with the proposed position of caret. So 
> if I don't agree with browser implementation, because for example it enters a 
> non-editable region, I can check that and handle this specific case by 
> myself. Since there's no easy JavaScript solution for handling up/down arrow 
> keys such information would allow us to focus only on these specific 
> behaviours we don't like.

Great idea! I'll include this in my draft Explainer doc, which is coming later 
today.

RE: CommandEvent for user intentions

[Ben Peters]

That is a great article! “A good WYSIWYG editor of arbitrary HTML is just as 
impossible as the halting problem is impossible... we have to treat it as an 
editor platform and API, rather than as a standalone component that tries to do 
everything itself.”

Let’s build a platform!

From: Julie Parent [mailto:jpar...@gmail.com]

Have you seen the recent post about the rich text editor that Medium uses?  It 
is a somewhat cheeky essay, including a mathematical proof, about how 
contentEditable is broken.  The conclusion is that in order to move forward, we 
need to treat contentEditable 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 
mailto:ben.pet...@microsoft.com>> wrote:
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.

RE: CommandEvent for user intentions

[Ben Peters]

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.

> I strongly agree that something like CommandEvents is necessary: a web 
> developer should be able to respond to the user’s intent, aka “selectAll”, 
> rather than enumerating, listening to, and responding to each and every 
> platform specific way that the intention to selectAll can be communicated.

> How encompassing do you envision CommandEvents?  Would it only cover well 
> known keyboard shortcuts and actions like those currently used by execCommand?

I see this as being more than just well-known keyboard shortcuts. I would like 
web developers to be able to extend it for their own purposes.

> What about taking this further and providing better events in two distinct 
> areas: those involving selections (intents like selectAll, but also selection 
> modifications like caret movement by keyboard or gestures, selection changes, 
> etc) and those involving input (including paste/drop/cut/formatting, but also 
> basic text insertion via keyboard/voice/etc).

This is a great idea! I'll include it in my spec. 

> 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 for selectionchange, and 
> seems like the right place and timing to work this in?

My current thought is that Selection events should be used for selection, and 
CommandEvent for things that would be in a toolbar or context menu. I think the 
design should make it easy to create and style toolbars based on the available 
commands and their state. Input events don't cover everything that would be in 
a toolbar, and they fire for things that already have events for user 
intentions (like Clipboard Events).

RE: [selection] Selection.setBaseAndExtent

[Ben Peters]

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 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] 
http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse

[selection] Selection.setBaseAndExtent

[Ben Peters]

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] 
http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse

contentEditable=minimal

[Ben Peters]

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]. We would like 
feedback on this concept from the broader community.

Problem
HTML uses the contentEditable='true' attribute to allow text input. The 
behavior of contentEditable varies widely from browser to browser and is very 
complex, resulting in many bugs and behavior differences between browsers. 
Editing frameworks like TinyMCE, goog.editor, and CKEditor are used in 
thousands of sites to overcome these issues. However, built-in browser editing 
varies so much that these frameworks and sites like Google Docs and Microsoft 
Office Online that have built custom solutions end up disable a large portion 
of the functionality of contentEditable. Ultimately this means that browsers 
support functionality that is largely disabled, and frameworks and sites have 
to work around the default behavior.

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'. The functionality provided by the browser under 
contentEditable='minimal' would be as follows:
* Caret drawing
* Events such as Keyboard , Clipboard, Drag and Drop
* Some keyboard input handling- caret movement, typing of characters including 
Input Method Editor input
* Selection drawing and manipulation according to the new Selection API spec

Frameworks and sites would then enable any formatting they desire using script.

- Ben

[1] http://oksoclap.com/p/extensible_content_editing
[2] https://github.com/w3c/editing-explainer/wiki/contentEditable=minimal 

[selection] [editing] Selection API Bugzilla is available

[Ben Peters]

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 them).

[1] 
https://www.w3.org/Bugs/Public/buglist.cgi?component=Selection%20API&list_id=35214&product=WebAppsWG&resolution=---
[2] http://rniwa.github.io/selection-api.html 
[3] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html 

RE: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value

[Ben Peters]

> Also on Mac, there is no  and  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 
 are not visible in developer APIs.

> It has a few implications but one of which is that we need to serialize some
> semantic elements such as "a" and "h1" when a part of content inside such an
> element is selected because we don't want to simply copy the content with
> blue text and underline for "a" for example.  User expects the pasted
> content to be a functional hyperlink if it looks like an anchor.
>
> Even elements such as "b" may need to be treated special because inside a
> contenteditable region where styleWithCSS is false, we don't want copying
> and pasting the content already in the contenteditable to introduce inline
> styles or a new style element.
>
> There are other problems with more exotic features of HTML and CSS.  Another
> problem we recently found is that when the copied content contains position:
> fixed or position: sticky, we need to convert them to position: absolute and
> wrap the whole copied content with a position: relative box in order to
> prevent the pasted content to populate the paste destination.
>
> In general, it is my opinion that copy algorithm should be spec'ed at the
> same time as paste algorithm in the HTML Editing API, and both of them are
> extremely challenging task.

I would say we should start by defining the shape of the html DataTransferItem 
rather than the way browsers should handle specific markup. So to be clearer on 
that, on copy, the DataTransferItem should have this shape:




List of styles that apply to the markup. Classes are named copiedStyle_uniqueID


Copied markup



Then on paste, the DataTransferItem should contain everything on the clipboard, 
possibly minus OS specific things like .

This way developers can generally count on being able to expect a full html 
page being available on paste, with hard styles (inline styles) in the markup, 
and theme styles (from the cascade) being available in the head. 
Implementations that don't have extra styling information in the head or inline 
the styles in the body don't break the model, they just don't allow the same 
level of control on paste.

RE: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value

[Ben Peters]

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 external source, it might make more 
sense to maintain destination styling instead. 
3- When copying from a wiki and pasting back into that same wiki, it makes 
sense to maintain any special formatting on that text (inline styles) but 
otherwise to use the theme (style sheets). 

There is one other scenario here, which is to maintain the html shape, but not 
any styles.
4- When seeking to maintain lists and tables, but format them with destination 
styles, it makes sense to remove style elements and style rules, but keep other 
html (  and  for instance ).


 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

>>> How hard do you think this is to implement?

>> Thanks for the code sample and thoughts! I'll run it by a few more 
>> developers to get deeper insight and get back to you.

>Great! Note that the code samples are just to get us started thinking about 
>the issues we'll have to tackle if we're going to do this - if some other 
>behaviour (say, 
>creating new class names and making up a new style sheet with 
>generated/computed styles) is easier to implement or seems to make more sense 
>by all means 
>suggest that other behaviour instead.

In order to support the 4 scenarios I mentioned above, we need to be able to 
distinguish inline css from style sheets. Your idea here about creating a new 
style sheet seems like a good way to go since it helps solve the selectors 
problem where css doesn't work the same once you remove the context by copying 
a section out, and it keeps the inline styles separate from the style sheets. 
We could include this styles in the head of the document or in a new text/css 
item.

On copy, we would take something like Chrome's algorithm to get relevant css 
for each element. For top-level elements, this would mean several rules by 
default to 'reset' the style, and anything other relevant styles. We would 
create a new class for each unique set of computed styles and give it a name 
that can be recognized and unique, maybe "copiedStyle_" where 
 is a guid or similar. We would also remove any inline style elements 
like Chrome/Firefox already do. So on copy you would get something like this on 
the clipboard:

Version:0.9
StartHTML:000157
EndHTML:03
StartFragment:01
EndFragment:02
SourceURL:http://en.wikipedia.org/wiki/Darth_vader



.copiedStyle_12345 {
color: black; background-image: none; font-weight: normal; margin: 0px 
0px 0.25em; overflow: hidden; padding: 0px; border-bottom-width: 1px; 
border-bottom-style: solid; border-bottom-color: rgb(170, 170, 170); font-size: 
1.8em; line-height: 1.3; font-family: 'Linux Libertine', Georgia, Times, serif; 
font-style: normal; font-variant: normal; letter-spacing: normal; orphans: 
auto; text-align: start; text-indent: 0px; text-transform: none; white-space: 
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; 
background-position: initial initial; background-repeat: initial initial;
}



Darth 
Vader



Then during copy, the text/html element would return all of this data (or the 
style would be in text/css instead). My devs believe having one text/html item 
(instead of text/css) would make it easier to get an element (by document.write 
for instance) that could be used with querySelector etc. Then javascript could 
handle scenarios 2-4 above easily by keeping or removing inline styles and 
elements, and 1 above could be done by calling querySelectorAll for each 
copiedStyle_* class and inlining those styles like Chrome does by default. 
Other style classes (like 'firstHeading' here) can be kept so that if you paste 
back into the same page, they apply again and you don't need to inline anything.

This means copy works like firefox + new classes to track styles that Chrome 
would currently inline. Paste works like Chrome (the text/html item returns all 
of the clipboard's html text). End to end, we enable the major scenarios we 
have identified of for copy/paste. 

Ultimately I believe the goal of this feature is just to enable functionality 
in an interoperable way. To make it easier to use, js frameworks could make a 
document object available (instead of plain text), or provide functions to 
accomplish 1-4 (and other paste types). Thoughts?

RE: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value

[Ben Peters]

>> 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 examples to make sure 
>we're in general agreement:

...

>How hard do you think this is to implement?

Thanks for the code sample and thoughts! I'll run it by a few more developers 
to get deeper insight and get back to you.

[clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value

[Ben Peters]

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 external source, it might make more sense 
to maintain destination styling instead. 
3- When copying from a wiki and pasting back into that same wiki, it makes 
sense to maintain any special formatting on that text (inline styles) but 
otherwise to use the theme (style sheets). 

So this is a complex problem to solve. From what I can tell, Firefox removes 
the document's head (and therefore style sheets) on copy, so 2 and 3 work, but 
1 doesn't. Chrome inlines a certain set of styles on copy, and removes the 
head, so 1 and 2 work, but 3 doesn't. IE maintains the head on copy, so all 3 
can work, only by using non-standard paste APIs that require the user to allow 
clipboard access. We have 3 execCommand args available- paste (for 1), 
ms-PasteTextOnly (for 2), and ms-PasteContentOnly (which maintains the shape of 
html markup but not styles, somewhat like 3).

In addition, the return value of getData('text/html') also varies. In Firefox, 
it returns only the data between  and . This again 
makes sense for 2 and 3 above. In Chrome, it returns everything in the 
clipboard item, which includes the head, body, and the  and 
, which means cleanup is required to actually put it in the DOM. 
IE doesn't support this at all yet, so whenever a developer wants to change the 
pasted text before it shows up in the DOM, they can't*.

We need a unified story.

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 and 
is available on paste via getData('text/css'). Another solution might be to 
build a document fragment during paste and make that available as a clipboard 
item that contains styles and is easier to insert into the DOM. Thoughts?

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 the focus is moving around, and 
it's generally ugly.

RE: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data

[Ben Peters]

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 referenced files into the clipboard. Then the page 
> uses msConvertUrl() rewrites references to the src attributes in the 
> text/html DataTransferItem to reference the blob URLs, right?

>Given that the drag data store is in "read only" mode at this point, it seems 
>weird to allow mutations at this point.

My understanding was that "read only" was intended to keep sites from changing 
the system clipboard outside of cut/copy events. We don’t change the system 
clipboard, only the pasted html. Sites could easily change it right after the 
paste happens, so we're saving them a step.

> In addition, from a security perspective, what stops a malicious website from 
> embedding something like  style="display:none"> in the markup?
 
We disallow this on copy by stripping such references.

RE: [Editing] Splitting Selection API Into a Separate Specification

[Ben Peters]

> 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.

RE: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data

[Ben Peters]

 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 final URLs back from the server.

>> This generally makes sense. If sites prefer to use local dataURI or 
>> blob, they can use the blob URL, and then upload the file later (like 
>> in an email scenario). This means they don't have to wait for them to 
>> be on the server before displaying them. If they want to upload them first 
>> and use the server's new URL for them, they would need to do what you're 
>> saying.

>Sounds good, but this requires standardising something similar to 
>msConvertURL(), right?

I don't believe so. Couldn't the site just get the HTML DataTransferItem (which 
contains the CIDs), replace the CIDs with Blobs or DataURIs, and then insert 
the HTML where the paste was going to happen? Personally I think msConvertURL 
is a convenient way to do this. But it's not the only way.

-Ben

RE: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data

[Ben Peters]

> 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..). However, one 
> can imagine a use case for example with a CANVAS app where the script wants 
> to copy the state of the CANVAS as an image inside HTML it places on the 
> clipboard - having the script create src="cid:n" type markup, append files, 
> and make the UA translate that to the platform's native clipboard 
> implementation's way of referencing one part on the clipboard from another 
> part..

I was thinking about images that aren't available cross-domain, like Facebook 
pictures. If you copy them, Facebook could use CID to place them on the 
clipboard since a Facebook URL wouldn’t be accessible to an email client that 
receives the pasted content.

> document.addEventListener('copy', function(e){
>   // So, you want to copy the current status of your game? No problem.
>   // Let's say this game generates a number of PNG graphics from CANVAS 
> tags
>   // and keeps them in memory in ArrayBuffers or something
>   
>   var html = 'player\'s medals:  src="cid:2">';
>   e.clipboardData.items.add(html, 'text/html');
>   e.clipboardData.items.add(new File(medals[0], 'medal.png', 
> {type:'image/png'}));
>   e.clipboardData.items.add(new File(medals[1], 'medal.png', 
> {type:'image/png'}));
>   e.preventDefault();
>
> }, false);

This seems like we're depending on add() working in a precise order, which 
seems vulnerable to code changes or other issues. Maybe add() should return the 
location in the list where the item was added, and then it can be used with CID 
more safely? I know this is part of HTML5 not ClipboardAPI though. Thoughts?

> 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 final URLs back from the server. A bit like this 
> (although some things could be more elegant, like the insertion of the data 
> which needs to take cursors and selections into account):

> http://jsfiddle.net/2Qqrp/

> Thinking about it, it may be considered somewhat wasteful (or exceedingly 
> slow - if for example the embedded data is a video) to do it this way - but 
> it quickly gets complex and/or confusing if we have a some "show this local 
> file until it's uploaded, then reference the online file instead" magic..?

This generally makes sense. If sites prefer to use local dataURI or blob, they 
can use the blob URL, and then upload the file later (like in an email 
scenario). This means they don't have to wait for them to be on the server 
before displaying them. If they want to upload them first and use the server's 
new URL for them, they would need to do what you're saying.

-Ben

RE: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data

[Ben Peters]

Hi Hallvord!

The IE11 API you mentioned is msConvertURL [1] (also on the IE blog [2]), and 
it was designed as a simple way for sites to choose DataURI or Blob for 
otherwise inaccessible images. We default to DataURI to be interoperable with 
Firefox’s current design of always doing DataURI for local images on the 
clipboard. With a little bit of code, blobs can be used instead. Our 
clipboardData.files implementation contains only images at the moment because 
we have only partial support of the current version of the Clipboard API spec. 
This means that with a quick ‘for’ loop over those images, javascript can 
choose to create blobs, manage the blob’s memory, and upload the blobs to a 
server. As you mention, it is not possible to tell which file/image corresponds 
to which  because it’s really designed as a simple approach for cases 
where a site wants to always use blob or dataURI for images that they couldn’t 
otherwise access.

We are considering doing the CID approach as well in the future. It is nice to 
have the additional control of seeing which  src you are changing, and it 
will likely work better for copy, not just paste like convertURL. We believe 
that convertURL does not block using the CIDs you have in the current spec. To 
better understand your approach and allow us to help move it forward, can you 
give us sample javascript that a site would use to set the DataTransferItems 
for HTML and the related images during copy? Second, can you provide the 
javascript for how a site would put them into the pasted markup during paste?

Regarding a couple other questions you ask:
* As far as I’ve seen, WebKit/Blink do not yet support images with local-system 
sources. They do support binary images on the clipboard using 
ClipboardData.items like 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://msdn.microsoft.com/en-us/library/ie/dn254951(v=vs.85).aspx 
[2] 
http://blogs.msdn.com/b/ie/archive/2013/10/24/enhanced-rich-editing-experiences-in-ie11.aspx
[3] http://strd6.com/2011/09/html5-javascript-pasting-image-data-in-chrome/

-Original Message-
From: Hallvord R. M. Steen [mailto:hst...@mozilla.com] 
Sent: Thursday, January 23, 2014 5:30 PM
To: public-webapps
Subject: [clipboard events] seeking implementor feedback on using CID: URI 
scheme for pasting embedded binary data

> Hi,
> pasting HTML that contains embeds (images, video) into a rich text editor is 
> a use case we should cover. It's currently handled in different ways - 

> * IE11 supports pasting images as either data: URLs or blobs [1] (and has a 
> non-standard method to fill in a gap in the blob approach). I don't 
> understand from this blog post how/if it supports referencing the binary 
> parts from the HTML. If for example you paste a snippet from a Word page that 
> contains two images, the DataTransferItemList is presumably populated with 
> two image files, which can be processed/uploaded using the blob method - but 
> how is the script processing the data supposed to know what IMG tag in the 
> pasted HTML each image file belongs to?

> * Pasting stuff as data: URLs seems like a hack, wasting memory and requiring 
> quite some extra processing if there is a lot of data.

> * Firefox apparently happily passes on file:/// URLs with local paths and all 
> [2], this is of course a bug.

> * Right now I'm not sure what WebKit/Blink - based implementations do. Test 
> results welcome!

> As the editor of the Clipboard Events spec, I'm proposing a somewhat 
> different take on this: "cid:"-URIs for embeds. See 
> http://dev.w3.org/2006/webapi/clipops/clipops.html (search for "cid:").

> The idea is that rather than embedding potentially very huge data: URLs or 
> reference local files in the embedded markup, we add a reference to the 
> DataTransferItemList, and use the index of this reference to construct a cid: 
> URI in the markup that clipboardEvent.getData('text/html') will see. The 
> script processing this data can then pull out the cid: URIs, do drag-and-drop 
> style file uploads for referenced clipboard parts, and update the data to 
> refer to the locations on the server eventually (maybe first using an 
> intermediate placeholder image or something like that.)

> AFAIK, outside of the used in HTML intended for E-mail, this would be the 
> first usage of CID: URIs in web platform specs. I'm looking for feedback 
> regarding whether this is implementable and a good solution. I haven't had 
> much (if any) feedback from implementors on this issue yet, so thank you all 
> in advance for your ideas and input.
-Hallvord

> [1] 
> http://blogs.msdn.com/b/ie/archive/2013/10/24/enhanced-rich-editing-experiences-in-ie11.aspx
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=665341