- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Sat, 09 Jan 2016 13:36:50 -0800
- To: Johannes Wilm <johannes@fiduswriter.org>
- Cc: "Gary Kačmarčík (Кошмарчик)" <garykac@google.com>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
> On Jan 9, 2016, at 4:29 AM, Johannes Wilm <johannes@fiduswriter.org> wrote: > > Another thing: > > For the things related to the specs of the editing taskforce, will you guys be turning the proposals you came up with into individual tickets on the spec or will you be submitting pull requests or some other way? > > > In particular, I am interested in these items: > > On Sat, Jan 9, 2016 at 2:32 AM, Gary Kačmarčík (Кошмарчик) <garykac@google.com> wrote: >> +public-webapps since these these notes are relevant for both groups >> >> >> >> This is a summary of my notes from the beforeinput/editing summit hosted by Microsoft on 7 Jan 2016. >> >> These notes focus on the UIEvent/beforeinput discussions, but some of the editing discussions are included here as well. >> >> >> >> Spec location >> >> ========== >> >> UIEvent spec will contain core description of beforeinput >> >> data, isComposing >> >> the data property should contain the text/plain version >> >> will define the event ordering >> >> Editing spec will contain partial interface that adds editing-specific stuff: >> >> editType (renamed to inputType) >> >> dataTransfer field (for handling rich data) >> >> > Here I will either need more information about how exactly you want to do the split and what goes into the dataTransfer field, or you could alternatively send in a PR which can then be discussed in the editing taskforce. I'm going to send out separate emails for each proposal we discussed. >> What about selection ranges for beforeinput? >> >> ========== >> >> We determined that this was not needed as an attribute on the InputEvent. >> >> If you need the range, you call a getTargetRanges() method and get a static snapshot of the current ranges >> >> Usually there will be only 1 range, but an array is returned to handle multirange. >> >> This avoids many problems associated with including targetRanges on the event, e,g: >> >> Should the range be live or static? >> >> Live ranges can be expensive to upkeep and they are often held onto longer than intended >> >> A lighter-weight StaticRange would need to be defined >> > > As I understood the concept of DumbRanges as we talked about them at TPAC, they would represent snapshots of current live ranges, correct? Please refrain from using the word "dumb" in this context. It's offensive for a lot of people. We discussed the idea of static range, which does not get updated via DOM mutations. > So the difference from the meeting at TPAC, where those static ranges were put to be directly on the event object, they will now be obtained through means of a method on the event object, right? This does not seem very controversial The idea is that we would like to produce an array of ranges at the time the method is called so that if one event listener modifies DOM, it can update the selection so that subsequent event listeners will be able to see a consistent state (because ranges are re-generated from the updated selection). > That still means we need to define how those static ranges are structured, or have you had progress on that? Yes, I'll send out a separate email for this as well. > If you do have a fully defined concept, it would be good to send in a PR so we have something to discuss about here. > >> >> How to handle multiple handlers for an event, when the first handler in chain modifies DOM or selection. >> >> What range should be sent to the 2nd handler? >> >> We need to send same event to each handler in the chain >> >> Therefore followup events will need to be sent an incorrect range. >> >> Ugh >> > > Did you find a solution for this problem? Yes. This is why we think using a method instead of a property is the way to go. - R. Niwa
Received on Saturday, 9 January 2016 21:37:20 UTC