- From: Robin Berjon <robin@w3.org>
- Date: Fri, 06 Jun 2014 17:59:02 +0200
- To: WebApps WG <public-webapps@w3.org>
Hi all,
here are the minutes from the editing discussion:
http://www.w3.org/2014/06/06-webapps-minutes.html
And in text so the archives keep'em searchable:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Web Applications Working Group Teleconference
06 Jun 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/06/06-webapps-irc
Attendees
Present
BenjamP, PiotrekKoszulinski, Xiaoqian, jparent_,
[IPcaller], darobin, +1.425.614.aabb, adrianba,
Robin_Berjon
Regrets
Chair
darobin
Scribe
darobin
Contents
* [3]Topics
1. [4]Context
2. [5]Goals
3. [6]Invoking Commands
4. [7]cE=minimal
5. [8]beforeinput and beforeselectionchange
6. [9]Splitting up work
* [10]Summary of Action Items
__________________________________________________________
<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
[11]http://w3c.github.io/editing-explainer/commands-explainer.h
tml
[11] 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
[12]http://extensiblewebmanifesto.org/
[12] 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
[13]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
[14]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
[15]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
Summary of Action Items
[NEW] ACTION: Robin to ask rniwa how he wants to handle
Selection [recorded in
[16]http://www.w3.org/2014/06/06-webapps-minutes.html#action03]
[NEW] ACTION: Robin to create an Editing TF [recorded in
[17]http://www.w3.org/2014/06/06-webapps-minutes.html#action01]
[NEW] ACTION: Robin to figure out how we handle the chartering
business [recorded in
[18]http://www.w3.org/2014/06/06-webapps-minutes.html#action02]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [19]scribe.perl version
1.138 ([20]CVS log)
$Date: 2014-06-06 15:56:06 $
__________________________________________________________
[19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[20] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11
Check for newer version at [21]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Found Scribe: darobin
Inferring ScribeNick: darobin
Default Present: BenjamP, PiotrekKoszulinski, Xiaoqian, jparent_, [IPcal
ler], darobin, +1.425.614.aabb, adrianba
Present: BenjamP PiotrekKoszulinski Xiaoqian jparent_ [IPcaller] darobin
+1.425.614.aabb adrianba Robin_Berjon
Found Date: 06 Jun 2014
Guessing minutes URL: [22]http://www.w3.org/2014/06/06-webapps-minutes.h
tml
People with action items: robin
[22] http://www.w3.org/2014/06/06-webapps-minutes.html
[End of [23]scribe.perl diagnostic output]
[23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Friday, 6 June 2014 15:59:13 UTC