RE: [clipboard API] platform integration stuff - in spec or out of scope?
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 hst...@mozilla.commailto:hst...@mozilla.com wrote: On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene james.m.gre...@gmail.commailto: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?)
[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 a...@aryeh.namemailto: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?
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
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 art.bars...@gmail.com 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 (Кошмарчик) gary...@chromium.org wrote: [...] Thus, I wonder if a separate Input Event spec (that both D3E and Editing would refer to) would make more sense. I think so. I have started that spec at 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
On Mon, Dec 8, 2014 at 2:33 PM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: [...] Thus, I wonder if a separate Input Event spec (that both D3E and Editing would refer to) would make more sense. I think so. I have started that spec at http://w3c.github.io/editing-explainer/input-events.html.
RE: [editing] Responsive Input Terminology
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
[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=subjecthdr-1-query=Need+Agreement+on+Terminologyindex-grp=Public_FULLindex-type=ttype-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
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?
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
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 hst...@mozilla.com 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=WebAppsWGcomponent=Clipboard%20API%20and%20eventsresolution=--- 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
[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
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 brs (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 ben.pet...@microsoft.commailto: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
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 art.bars...@gmail.commailto: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
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: [editing] Suggested selection.extend can not select based on how the text currently displayed
Selection.extend is a separate API from Selection.modify. They are both listed
by Mozilla at
https://developer.mozilla.org/en-US/docs/Web/API/Selection?redirectlocale=en-USredirectslug=DOM%2FSelection
for reference. Thanks for the feedback!
Ben
From: e...@ictenablers.com [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)
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 p.koszulin...@cksource.com 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 f.knab...@cksource.com 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: User Intentions Explainer (was: List of Intentions)
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 johan...@fiduswriter.org wrote: On Mon, Sep 8, 2014 at 6:05 PM, Frederico Knabben f.knab...@cksource.com wrote: snip 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 span style= into a mix of font-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)
On Sat, Sep 6, 2014 at 1:54 AM, Johannes Wilm johan...@fiduswriter.org wrote: These both look quite good! On Example 3 on the commands explainer, I was wondering if it is the idea that custom actions only can be triggered by specific key presses, whereas for standard events are triggered by 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)
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 ben.pet...@microsoft.com 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?
On Tue, Aug 19, 2014 at 10:08 AM, Daniel Cheng dch...@chromium.org wrote: On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen hst...@mozilla.com wrote: Does anyone else have input for/against this? Conceptually, I guess RTF sort of covers the same use cases as HTML. That doesn't 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: [clipboard] Add RTF to the mandatory data types list?
From: Ben Peters On Tue, Aug 19, 2014 at 10:08 AM, Daniel Cheng dch...@chromium.org wrote: On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen hst...@mozilla.com wrote: Does anyone else have input for/against this? Conceptually, I guess RTF sort of covers the same use cases 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: User Intentions Explainer (was: List of Intentions)
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
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 james.m.gre...@gmail.commailto: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 ben.pet...@microsoft.commailto: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.orgmailto: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.orgmailto: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
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 ben.pet...@microsoft.commailto: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.commailto: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 james.m.gre...@gmail.commailto: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 ben.pet...@microsoft.commailto: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.orgmailto: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.orgmailto: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
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.orgmailto: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
?This API is already used on the web so we should probably keep it as-is. From: James M. Greene james.m.gre...@gmail.com Sent: Tuesday, August 5, 2014 4:58 PM To: Ben Peters Cc: Ryosuke Niwa; public-webapps Subject: RE: [selection] Selection.setBaseAndExtent 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 ben.pet...@microsoft.commailto: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.orgmailto: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.orgmailto: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)
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 jpar...@google.com This is a great list, and I agree it is the right starting point. On Mon, Jul 21, 2014 at 6:12 PM, Ben Peters ben.pet...@microsoft.com wrote: We now have a good list of use cases on the Explainer[1]. I believe the next step is to come up 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
-Original Message- From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Wed, Jul 23, 2014 at 12:17 AM, Ben Peters ben.pet...@microsoft.com wrote: [1] http://www.w3.org/TR/clipboard-apis/#semi-trusted-events The default action of a synthetic paste event 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?
RE: [clipboard] Semi-Trusted Events Alternative
-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.
[clipboard] Semi-Trusted Events Alternative
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
Summary: A few folks from the IndieUI TF came to the meeting today. We went over our goals and the possibility of working together on solving User Intentions for the web. Minutes are available at http://www.w3.org/2014/07/11-webapps-minutes.html Text version: conference code? BenjamP 9274 ArtB janina_ code is 9274 thanks! scribe 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 cyns http://www.w3.org/TR/indie-ui-events/#RequestEvents scribe ACTION: janina to forward URLs of IndieUI docs [recorded in http://www.w3.org/2014/07/11-webapps-minutes.html#action01] trackbot Error finding 'janina'. You can review and register nicknames at http://www.w3.org/2008/webapps/track/users. section 5 visualization cyns 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 ArtB Scribe: Janina ArtB 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]
window.find deprecated?
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] Conference Call July 11th 8am San Francisco Time
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
[editing] Visualizing the benefits of user intention information
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
[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
RE: [editing] Leading with ContentEditable=Minimal
-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
[clipboard] Clipboard API Mandatory Data Types
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 with native UI (was: [editing] CommandQuery Object and Event)
From: Robin Berjon [mailto:ro...@w3.org] On 06/06/2014 18:39 , Ryosuke Niwa wrote: On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński p.koszulin...@cksource.com wrote: 1. That we need any native UI related to cE at all. We don't. We can display our own toolbars, with our own buttons, with 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)
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=1lid=5391959,5128581,2950159,1850 147h=2950159
RE: [editing] Leading with ContentEditable=Minimal
On Tue, Jun 17, 2014 at 8:47 AM, Piotr Koszuliński p.koszulin...@cksource.com wrote: I think that first we need to clarify how we understand some terms/concepts, because I was confused many times and I'm afraid that I also haven't been understood correctly. 1. Separation of basic user intent 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
On Tue, Jun 17, 2014 at 4:50 PM, Olivier F teleclim...@gmail.com wrote: On Tue, Jun 17, 2014 at 1:44 PM, Julie Parent jpar...@google.com wrote: An app can have a cursor that isn't a native browser cursor. For example, Google Docs does not use native browser cursors and draws their own, so that 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.
[editing] Leading with ContentEditable=Minimal
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] Leading with ContentEditable=Minimal
On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote: If Intention events are (temporarily) moved out of scope, I don’t think I’d say they’re out of scope, just that they will likely not be ready as quickly as we could do contentEditable=’minimal’. Do you agree with that? 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? div cursor=”true” commandEvents=”true”minimally editable content/div 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.
RE: [editing] Leading with ContentEditable=Minimal
On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com wrote: Yes. I really like the idea of explicitly enabling what you want and of separating the concepts. Being able to turn on commandEvents independent of a cursor seems useful. An API like this leaves far fewer questions of 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 divnot editable at all/div would get clipboard and drag/drop events, like it does today. div commandEvents=truebuild an editor here/div would also get CommandEvents.
[editing] Best Time for Recurring Call
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=1lid=5391959,5128581,2950159,1850147h=2950159
RE: [editing] CommandQuery Object and Event
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 p.koszulin...@cksource.com 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
[selection] extend() behavior when there is no range needs to be clarified
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: CommandEvent for user intentions
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).
RE: [editing] CommandQuery Object and Event
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 Conference Call June 6th
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
[editing] CommandQuery Object and Event
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(commandName)
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
RE: contentEditable=minimal
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: contentEditable=minimal
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: [editing] CommandEvent and contentEditable=minimal Explainer
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 div contentEditable id='editRegion'
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 ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org
public-webapps@w3.orgmailto: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: [editing] CommandEvent and contentEditable=minimal Explainer
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
ben.pet...@microsoft.commailto: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.commailto:jpar...@gmail.com]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.orgmailto: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 div contentEditable id='editRegion'
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 ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org
public-webapps@w3.orgmailto: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: contentEditable=minimal
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?
RE: contentEditable=minimal
-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 ro...@w3.org wrote: Which brings me to think: when we discussed this at the Summit, there was some agreement (between all four of us :) that it was a good idea to support multi-range selections. These are useful not just for tables, but also for 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
-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
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: CommandEvent for user intentions
On Thu, May 22, 2014 at 4:02 AM, Piotr Koszuliński p.koszulin...@cksource.com wrote: I wrote a longer reply in the contentEditable=minimal thread, which touches some aspects of command events. Actually, before some stable point about cE=minimal is reached I feel that it may be hard to 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 li. 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: contentEditable=minimal
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.
[editing] CommandEvent and contentEditable=minimal Explainer
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: CommandEvent for user intentions
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: CommandEvent for user intentions
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 ben.pet...@microsoft.commailto: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: [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 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
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
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
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%20APIlist_id=35214product=WebAppsWGresolution=--- [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
Also on Mac, there is no !--StartFragment-- and !--EndFragment-- and the serialized markup copied into the clipboard (called pasteboard on Mac) needs to contain the precisely the markup that got copied by the user. Good point. Perhaps we should make sure any OS specific items like !--StartFragment-- 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: html head style List of styles that apply to the markup. Classes are named copiedStyle_uniqueID /style body Copied markup /body /html Then on paste, the DataTransferItem should contain everything on the clipboard, possibly minus OS specific things like !--StartFragment--. 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
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 ( li and table 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_randomid where
randomid 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
html
head
style
.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;
}
/style
/head
body
!--StartFragment--h1 id=firstHeading class=copiedStyle_12345
firstHeading lang=enspan dir=autoDarth
Vader/span/h1!--EndFragment--
/body
/html
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
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
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 startfragment and endfragment. 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 startfragment and
endfragment, 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: [Editing] Splitting Selection API Into a Separate Specification
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
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 img src=file:///etc/passwd style=display:none/img in the markup? We disallow this on copy by stripping such references.
RE: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
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
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 = 'divbplayer/b\'s medals: img src=cid:1img
src=cid:2/div';
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
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 img 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 img 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
