Web Applications Working Group Teleconference -- 06 Jun 2014

<trackbot> Date: 06 June 2014

<scribe> Scribe: darobin

you're a bit early on the call :)

<BenjamP> yes

adrianba: are you on the call too?

<adrianba> not yet

<adrianba> 6 more minutes ;)

<adrianba> you don't need to hear me slurp my coffee

FWIW I flagged myself as chair, but that's just formalism; no pretence to whatever

and if someone else desperately feels like scribing I won't stand in the way

<BenjamP> it's all you:) thanks!

<PiotrekKoszulinski> I guess ??P1 is me. Should I ask Zakim to change my name?

Robin: W3C

<BenjamP> Explainer is currently at http://w3c.github.io/editing-explainer/commands-explainer.html

BenjamP: from Microsoft, wrote the commands explainer

PiotrekKoszulinski: CKEditor

jparent_: Google, worked on text editro

xiaoqian: W3C

adrianba: Microsoft too

BenjamP: want to give some context, goals we have, then have a few topics of debate: invoking commands, using cE=minimal or have it as a concept, beforeinput vs commandevent, and command data context
... very open to other things

Robin: would like to list issues and get away with some sort of plan

BenjamP: anything else?

Context

BenjamP: cEmin is something that came up in a meeting earlier this year
... both MS and Google had thought of it
... looking for a way to minify cE to have few or no default handling, bold, enter, etc.
... in order to help sites figure out what users are trying to do Command,IntentionEvent were a way to figure out what users are trying to do
... finally I just recently sent something about query command that can enable overwriting of commands by frameworks
... and help browser determine UI
... that's farther-reaching and possibly out of scope for right now

Robin: this is in line with the Summit findings, and we'd like to have another Summit in Berlin in September, and have editing be discussed there

PiotrekKoszulinski: that would be great, we're based in Poland, other editors are also in Europe

Goals

BenjamP: let's make sure we agree on what we're trying to accomplish
... simplify all the different ways that input can be done for editing
... assist sites in disabling default input so that they can do exactly what they want to do for their context

Robin: we have to take i18n into account, which is difficult but part of input

BenjamP: definitely, especially keyboard, browsers can make that available to script

Invoking Commands

BenjamP: discuss using execCommand, since it takes string, it's extensible
... if we want to fire a command event for stuff we don't support we can just use any string
... perhaps more web friendly, notably with selection, which in turn can fire an event
... instead of having a generic method that takes a string, you have a specific method
... same as with Clipboard
... lots of discussion there
... how do we determine best way forward

adrianba: are we aligned with the notion of the extensible web manifesto in terms of adding the lowest-level primitives?
... I think it's what most of the people engaged in the conversation want
... especially since the people with experience doing editing tools seem to lean this way
... but I have heard from a few people both at MS and glazou who wanted more of a "better cE" that would make it easy to add input type=rich
... I'm guessing that's not what we're trying to do
... one way forward trying to figure out whether we have the most basic thing we can add, keep finding primitives

Robin: I think that's pretty representative of what I've heard
... it's possible to also improve cE, but that can be a separate project

BenjamP: my understanding is that cE is just one type of editor
... and since there are so many editors, so just one option doesn't cut it

http://extensiblewebmanifesto.org/

scribe: I agree with this goal, it has come up more than once, just having the enabling primitives and help make things simpler

BenjamP: for execCommand, the 2nd arg is almost never used, we can't just remove it, at least not at this point
... but my proposal is that we keep the first arg, and the 2nd can be (boolean or DOMObject)
... alternatively we could have another method

jparent_: I'm having a hard time figuring how this fits into just enabling primitives

BenjamP: sure, we are primarily enabling sites to understand what users wants to do
... so if a site wants to change what Ctrl-B does, the site can intercept that and replace that with their own
... without that, they can't use the same pipeline
... they can listen to bold and override

Robin: I am not convinced that we need something as high-level as bold

jparent_: I completely agree with that, it's already complicated
... could be strong, b, etc.

BenjamP: I think that's two things
... we shouldn't define bold
... we just give the user the fact that the user intends to bold
... notably cross language

Robin: I don't disagree that there are locale-dependent shortcuts but something like bold seems too high level to me
... I'd like to solve lower level like selection, newline, delete

BenjamP: how would we expose those?

Robin: so you could have multiple newline events (Enter vs newline), and delete would match platform convention to a range that would then be communicated to the script

BenjamP: interception of selection for special deletion

Robin: it would help to have some code

BenjamP: if we just give the selection I think we've lost the context of where the user was, we lose the intent

PiotrekKoszulinski: I think that Fx has an example, you can take the range from the Drop event — I'd like to have that on deletion events
... I think this is the best way to handle this
... the event has to carry the range before there's a change

Robin: if the selection hasn't changed when you get the deletion event, you can probably infer a lot

BenjamP: sounds like we want to solve a few lower-level problems before we figure out the APIs, which makes sense
... a smaller set of commands sounds like what everyone is interested in

[no disagreement]

BenjamP: also, the expected state carried in the command, current state is already availabel

cE=minimal

BenjamP: that was the original concept that started the discussion
... but then jparent_ pointed out that you can cancel intention events, and cancelling them all just gives you a minimal
... so we might not need the markup

jparent_: I don't think we need it
... minimal wants two things: get a cursor, and advanced events
... I don't need they need to be tied to editability

Robin: so we could reuse those events, e.g. for non text edition you could have deletion

jparent_: exactly, for things other than text

BenjamP: we have to be careful not to enable a new way to code websites
... if they become so powerful then everything that a user is trying to do might be handled that way
... we should have the kitchen sink

Robin: I think we can try to design this without cEmin, but if it becomes problematic we can backtrack

jparent_: I think these stay focused on editing

Robin: maybe the ability to receive intention events triggers on focus?

PiotrekKoszulinski: I don't know if a lot of those events make sense in a different context

Robin: I have a concern that if we expand these events beyond text editing we might be boiling the ocean

BenjamP: the ability to override keyboard events has value also in text, so it is useful there
... Sublime has lots of keyboard shortcuts
... but instead of the way it is today where you have to listen to keyboard events and handle them, we could have a mapping of keyboard events to commands
... so all you do in the keyboard handler is map to the command, and handle the command as you have always done

Robin: we can keep command events and the way they are bound into the platform orthogonal

beforeinput and beforeselectionchange

BenjamP: selection event would be the event for selection
... command event for menus and such
... text input is a special case
... beforeinput can help you determine how to handle things
... but today, input events fire for all sorts of things including paste events
... so I'm concerned that beforeinput might cause duplication

<Travis_> DOM3 folks added it (beforeinput) as a replacement for keypress (deprecated).

Robin: if we can simplify it one way or the other (paste/input separate, or input with indication that it's a paste) it's best
... having two events for the same content is madness

BenjamP: we could just have a commandevent with insert-text as its type
... we could just use that on the event side as well

Splitting up work

BenjamP: we definitely have some research, look at frameworks

Robin: if we can get people involved all the better
... we can have a mailing list

adrianba: that was definitely helpful with the media TF where we were trying to appeal to a specific audience

<adrianba> +1

<PiotrekKoszulinski> +1

<scribe> ACTION: Robin to create an Editing TF [recorded in http://www.w3.org/2014/06/06-webapps-minutes.html#action01]

<trackbot> Created ACTION-731 - Create an editing tf [on Robin Berjon - due 2014-06-13].

BenjamP: we need a normative spec
... as well as updates to the explainer
... without cE, we need Command Events

Robin: we need to define the binding with HTML too

BenjamP: we need an editor, and we need to figure out when we make them official

Robin: is editing already in the WebApps charter

<scribe> ACTION: Robin to figure out how we handle the chartering business [recorded in http://www.w3.org/2014/06/06-webapps-minutes.html#action02]

<trackbot> Created ACTION-732 - Figure out how we handle the chartering business [on Robin Berjon - due 2014-06-13].

BenjamP: update the explainer with this information, then write some specs
... and file bugs, improve work
... the current discussion is hard to track

Robin: we can reuse the Bz for the Editing API or the GH issues

BenjamP: GitHub it is!

Robin: BenjamP you're willing to edit?

BenjamP: yes

Robin: I'm happy to edit too
... we also need the Selection API

BenjamP: yes, rniwa said he didn't have much time not long ago

jparent_: my impression was that after WWDC he'd have more time

<scribe> ACTION: Robin to ask rniwa how he wants to handle Selection [recorded in http://www.w3.org/2014/06/06-webapps-minutes.html#action03]

<trackbot> Created ACTION-733 - Ask rniwa how he wants to handle selection [on Robin Berjon - due 2014-06-13].

Robin: I would encourage people to start using the tracker

BenjamP: other call?

Robin: we could say that Fri 8am PST is always the time, but we call it on an ad hoc basis

RESOLUTION: Fri 8am PST is always the time, but we call it on an ad hoc basis

- DRAFT -

Web Applications Working Group Teleconference

06 Jun 2014

Attendees

Contents