Skip to content
This repository has been archived by the owner on Nov 15, 2021. It is now read-only.

added agenda proposal #71

Merged
merged 1 commit into from Sep 14, 2016
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
51 changes: 50 additions & 1 deletion meetings/16-09-22TPAC-3.md
Expand Up @@ -24,7 +24,56 @@ This meeting will take place on 22 September 2016 as part of [TPAC 2016](https:/

## Agenda

* TBD
Input Events
======

* Should we have an inputType for the spellchecker specifically? Previously we deicded to use a more general inputType for all possible spell- and grammarchechers which is now called insertNonText, but given that there are only spell checkers currently, it may be transport more information to use a new inputType like: "insertFromSpellcheck" [1]

* Canceling last beforeinput event within compositions: Chrome teams's investigation found that browser could be made to remember dom structure before composition, but that this wouldn't hjelp much for cases where JS wants to handle insertion itself, because the revert would happen AFTER a beforeinput triggered piece of JS that calls event.preventDefault(). The problem with this is that it will require a dom-aware diffing mechanism on the JS side and may still include a fair amount of guesswork on the JS side [2]

Proposed solution: Add a method to this beforeinput event to revert the dom changes caused by the composition so that the DOM changes can be reverted before JS handling of composition insert [3]. Other ideas?

* After the F2F in San Francisco, it was argued on the part of the Chrome team that the clipboard-related beforeinput events should only deal with dom-insertion and not with clipboard manipulation. These changes have been put inot the spec draft. In that connection it was also argued that possible the history-stack-related beforeinput event spossibly could be decoupled from the history stack. This would be somewhat different from the discussion at the F2F where the majority argued that the browser-internal history stack is unusable as soon as JS handles at least some types of editing operations. Is this something we need to reformulate in the spec, or does it not really matter, as undo/redo will have to be handled by JS anyway as long as JS preventDefaults some beforeinput events? [4]

* Define "static range potentially affected by event" [5]. While it's easy to intuitively understand what this means, it seems more difficult to define normatively what part of the DOM can be said to be "affected" [6]. Do we need a definition that makes sure that implementations don't differ, or is this not a realworld concern?

Event order
===

* Event order for drag/drop, history, clipboard: Should go into UI events spec? [7]

* When are the events triggered? Domenic Denicola and Anne van Kesteren declare "We don't want the timing of mutation events for any new events." Instead they favor tasks/microtasks [8]. How can this work for our events? Possibly three microtasks where the first one (beforeinput event) schedules the second one (DOM mutation) only if it has not been preventDefaulted?

* Anne van Kesteren proposes to move the prose about when the beforeinput/input events are fired into "n the specification that defines the action that causes the event to be dispatched. (UI events is rather bad in that it doesn't actually define actions, it just defines some events, some ordering between them, but nothing that amounts to a model.)" [9]


Other issues
======

* Format context menu on iOS/Safari, opt-in/out solution presentation of Apple's proposal. [10]

* IME on long-key press, proposal on how to handle it? Wrap each keypress into an IME operation on Mac? [11]

* Should contenteditable have break-word behavior by default? [12]

* Clickability of elements with user-select: none [13]

* Set virtual enter key text, presentation of Google's proposal. [14]

[1] https://github.com/w3c/input-events/issues/31
[2] https://github.com/w3c/input-events/issues/17#issuecomment-245739017
[3] https://github.com/w3c/input-events/issues/17#issuecomment-246102307
[4] https://github.com/w3c/input-events/issues/21
[5] https://github.com/w3c/input-events/issues/5
[6] https://github.com/w3c/input-events/issues/5#issuecomment-239940614
[7] https://github.com/w3c/input-events/issues/22
[8] https://github.com/w3c/input-events/issues/9
[9] https://github.com/w3c/input-events/issues/9#issuecomment-239772551
[10] https://github.com/w3c/editing/issues/141
[11] https://github.com/w3c/editing/issues/132
[12] https://github.com/w3c/editing/issues/145
[13] https://github.com/w3c/csswg-drafts/issues/319
[14] https://github.com/w3c/editing/issues/142

Please add your name, and agenda requests here by [editing a branch and making a Pull Request](https://github.com/w3c/WebPlatformWG/edit/gh-pages/meetings/16-09-22TPAC-3.md), or by mail to either the public-webapps mailing list or the chairs of the Web Platform group, which will result in it being posted here.

Expand Down