Re: [editing] Leading with ContentEditable=Minimal

[Olivier F]

Oh right, of course. Thank-you.


On Tue, Jun 17, 2014 at 5:00 PM, Ben Peters 
wrote:

> On Tue, Jun 17, 2014 at 4:50 PM, Olivier F  wrote:
> > On Tue, Jun 17, 2014 at 1:44 PM, Julie Parent 
> 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.
>
>

RE: [editing] Leading with ContentEditable=Minimal

[Ben Peters]

On Tue, Jun 17, 2014 at 4:50 PM, Olivier F  wrote:
> On Tue, Jun 17, 2014 at 1:44 PM, Julie Parent  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.

RE: [editing] Leading with ContentEditable=Minimal

[Ben Peters]

On Tue, Jun 17, 2014 at 8:47 AM, Piotr Koszuliński  
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

[Olivier F]

On Tue, Jun 17, 2014 at 1:44 PM, Julie Parent  wrote:

>
> On Tue, Jun 17, 2014 at 12:22 PM, Olivier F  wrote:
>
>> On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent  wrote:
>>
>>>
>>> On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters 
>>> wrote:
>>>
 On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent 
 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?

>>>
>>> Agreed in general, but it would depend on how contentEditable='min' is
>>> actually defined.
>>>
>>> > 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?

 minimally editable content

 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.

>>>
>>> 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?
>>>
>>>
>> I really like cursor=true.
>>
>> I'm more confused about commandEvents=true as a separate attribute.
>>
>> - Do CommandEvents make any sense without a cursor? In particular, how
>> does end-user focus an area that has commandEvents=true if there is no
>> cursor?
>>
>
> 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?


>  They have to use a hidden focused contentEditable region in order to get
> all the events they need now, but it would be a much nicer solution for
> them to simply enable the events.
>

I'm hopeful that these kind of machinations will be a thing of the past if
we can create a good spec here...


>
>> - If commandEvents are just events with no default action, can they not
>> fire safely wherever cursor=true? If the page code does not listen for the
>> event and react, nothing happens. If the page wants to do anything with a
>> command event, it just needs to observe said event.
>>
>
> True, and perhaps that could simply things. Events aren't free for the
> browser though, so there is a cost of having them fire needlessly.
>

>
>>  I'm assuming here that text insert is a commandEvent and that the page
>> dev takes care of updating the DOM with inserted text (including partial
>> edits with composition events). I guess that part is still up for debate :)
>>
>> I am further assuming "CommandEvents" refers to low level intent events
>> like "deleteToBeginningOfLine" (although they could also eventually refer
>> to "boldSelection").
>>
>> I want to clarify that in my opinion cursor=true (or commandEvents=true)
>> should in no way imply that the UA should show a WYSIWIG editing UI (bold
>> buttons and context menu entries, etc...). My editor may be a code editor
>> where a "bold" command makes no sense whatsoever and having "bold" button
>> looks silly and confusing.
>>
>> I can imagine we would eventually create an API that allows page devs to
>> tell the UA that certain WYSIWYG controls should be shown, and control
>> their state, and they should fire commandEvents. Thi

Re: [editing] Leading with ContentEditable=Minimal

[Julie Parent]

On Tue, Jun 17, 2014 at 12:22 PM, Olivier F  wrote:

> On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent  wrote:
>
>>
>> On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters 
>> wrote:
>>
>>> On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent 
>>> 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?
>>>
>>
>> Agreed in general, but it would depend on how contentEditable='min' is
>> actually defined.
>>
>> > 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?
>>>
>>> minimally editable content
>>>
>>> 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.
>>>
>>
>> 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?
>>
>>
> I really like cursor=true.
>
> I'm more confused about commandEvents=true as a separate attribute.
>
> - Do CommandEvents make any sense without a cursor? In particular, how
> does end-user focus an area that has commandEvents=true if there is no
> cursor?
>

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.  They have to use a hidden focused
contentEditable region in order to get all the events they need now, but it
would be a much nicer solution for them to simply enable the events.


> - If commandEvents are just events with no default action, can they not
> fire safely wherever cursor=true? If the page code does not listen for the
> event and react, nothing happens. If the page wants to do anything with a
> command event, it just needs to observe said event.
>

True, and perhaps that could simply things. Events aren't free for the
browser though, so there is a cost of having them fire needlessly.


> I'm assuming here that text insert is a commandEvent and that the page dev
> takes care of updating the DOM with inserted text (including partial edits
> with composition events). I guess that part is still up for debate :)
>
> I am further assuming "CommandEvents" refers to low level intent events
> like "deleteToBeginningOfLine" (although they could also eventually refer
> to "boldSelection").
>
> I want to clarify that in my opinion cursor=true (or commandEvents=true)
> should in no way imply that the UA should show a WYSIWIG editing UI (bold
> buttons and context menu entries, etc...). My editor may be a code editor
> where a "bold" command makes no sense whatsoever and having "bold" button
> looks silly and confusing.
>
> I can imagine we would eventually create an API that allows page devs to
> tell the UA that certain WYSIWYG controls should be shown, and control
> their state, and they should fire commandEvents. This could be a nice
> additional building block for editor devs in the future. However the
> default should be don't show any UA-native WYSIWYG or text editing controls.
>

Re: [editing] Leading with ContentEditable=Minimal

[Olivier F]

On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent  wrote:

>
> On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters 
> wrote:
>
>> On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent  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?
>>
>
> Agreed in general, but it would depend on how contentEditable='min' is
> actually defined.
>
> > 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?
>>
>> minimally editable content
>>
>> 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.
>>
>
> 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?
>
>
I really like cursor=true.

I'm more confused about commandEvents=true as a separate attribute.

- Do CommandEvents make any sense without a cursor? In particular, how does
end-user focus an area that has commandEvents=true if there is no cursor?
- If commandEvents are just events with no default action, can they not
fire safely wherever cursor=true? If the page code does not listen for the
event and react, nothing happens. If the page wants to do anything with a
command event, it just needs to observe said event.

I'm assuming here that text insert is a commandEvent and that the page dev
takes care of updating the DOM with inserted text (including partial edits
with composition events). I guess that part is still up for debate :)

I am further assuming "CommandEvents" refers to low level intent events
like "deleteToBeginningOfLine" (although they could also eventually refer
to "boldSelection").

I want to clarify that in my opinion cursor=true (or commandEvents=true)
should in no way imply that the UA should show a WYSIWIG editing UI (bold
buttons and context menu entries, etc...). My editor may be a code editor
where a "bold" command makes no sense whatsoever and having "bold" button
looks silly and confusing.

I can imagine we would eventually create an API that allows page devs to
tell the UA that certain WYSIWYG controls should be shown, and control
their state, and they should fire commandEvents. This could be a nice
additional building block for editor devs in the future. However the
default should be don't show any UA-native WYSIWYG or text editing controls.

Re: [editing] CommandEvent and contentEditable=minimal Explainer

[Piotr Koszuliński]

On Tue, Jun 17, 2014 at 2:39 AM, Julie Parent  wrote:

> I certainly understand the concern that it would be impossible to properly
> catch and cancel all events.
>

I'm not concerned only about this. I'm concerned about the fact that
currently existing commands and editable-related features does not fit in a
simple command APIs.


>  But I think that is somewhat the point - it forces browser vendors to get
> these parts right.
>

The spec should guide engines' developers, because there's a single spec
and many engines. Even if all browser vendors will get these parts right,
they may choose different paths. And then, in general, this will be not
right and it will be a pain for developers.


>  All changes to an editable dom must fire an event before the
> modifications are made, and must be cancelable. Further, I'd say that if
> the number of events you would need to preventDefault on grows larger than
> selection, command, and maybe clipboard then that implies that we are not
> building the right APIs.
>
>
I don't think that number of events implies that we are building a bad API.
Dozen of well defined events is better than three that do too much in an
unclear way.

Besides that, as an editor author I'm not only interested in preventing
default action of features I don't want. I also want to hide them - remove
them from browser UI like context menus, menu bar, or other widgets like
special toolbar appearing over contenteditable on iOS. This makes the
situation which spec has to describe much more complex. That's why I think
it's better to focus on basics (
http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0918.html)
than on trying to make specification for every feature that was introduced
in any engine in any away.

-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer

Re: [editing] Leading with ContentEditable=Minimal

[Piotr Koszuliński]

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.

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.

3. Native UI. Again we have UI for basic interaction like the "paste"
option in context menu and UI for rich options like bold or
enabling/disabling auto quotes (see [1]). CE=minimal does not need rich
options in any form - commands or UI. I'm not sure yet what about basic
interaction like copy, cut, paste, spell checking, undo, redo, select all,
but they definitely belong to a separate group and may be considered
independently of the rich options.

Do we agree about these three topics? At least from the separation POV, not
necessarily about what cE=minimal needs.

[1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0867.html




On Mon, Jun 16, 2014 at 8:12 PM, Ben Peters 
wrote:

>  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?
>



-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter  | Facebook
 | Google+
 | LinkedIn

[TPAC2014] Registration Now Open for October 27-31 meeting week; deadline Oct 8

[Arthur Barstow]

Registration is now open for the October 27-31 Technical Plenary and all 
Working Group meeting week:


  

WebApps will meet on Monday and Tuesday (October 27 and 28). 
Registration for WebApps' meeting (as well as any other meetings and 
events that week) is mandatory. The group's meeting page including draft 
agenda is [Meeting].


TPAC will be at the Santa Clara Marriott hotel (just a few miles from 
SJC airport) and the hotel discount for meeting participants expires 
October 3.


The daily fee has increased to 75.00 USD.

The week's high-level schedule is [TPAC].

I'll create

-AB

[TPAC] 
[Meeting] 


On 6/6/14 1:49 PM, Ian Jacobs wrote:

Dear Advisory Committee Representatives, Chairs, AB, and TAG,

Registration for TPAC is now open:

   TPAC 2014
   27-31 October
   Santa Clara, California
   at the Santa Clara Marriott Hotel
   http://www.w3.org/2014/11/TPAC/

Chairs, please forward this information to participants in your
groups. We will seek additional information from Chairs closer to the
meeting regarding A/V needs and other requests.

We invite all TPAC participants to:

1) Register (see below).

2) Make your hotel reservation. W3C has arranged a discount room rate at the 
Santa Clara Marriott Hotel for the dates 24 October - 1 November.
 Please reserve by 3 October to benefit from the discount rate.

For more information about the venue and hotel:
http://www.w3.org/2014/11/TPAC/#venue

Please direct questions to w3t-tpregis...@w3.org.

Thank you,

Ian Jacobs, Head of W3C Communications

--
Registration
--

There is a daily registration fee. The per person, per day fee is:

  * 75 USD if registration and payment completed by 8 October 2014.
  * 150 USD otherwise.

As in the past, registration is a two-step process:

1) A WBS form for meeting and dietary information
  https://www.w3.org/2002/09/wbs/35125/TPAC2014/

2) A payment system
  https://www.w3.org/2014/11/tpac_reg

For more information about registration fees (including who is not
required to pay registration fees) and the payment system, see
   http://www.w3.org/2014/11/TPAC/#registration

--
Plenary Day 2014 (Unconference, W3C20)
--

Plenary Day 2014 consists of two parts:

1) Unconference breakouts for TPAC participants
https://www.w3.org/wiki/TPAC2014

We encourage you to propose breakout sessions in our wiki:
https://www.w3.org/wiki/TPAC2014/SessionIdeas

2) W3C20, a public Symposium and Gala Dinner at the occasion of W3C's
20th anniversary. TPAC attendees are invited to W3C20 and must
register to attend.

For more information about W3C20, see http://www.w3.org/20/

Mid-June we plan to open W3C20 registration to the general
public for a limited number of seats.

--
Advisory Committee Meeting / Group Meeting Overlap
--

This year we are building "unstructured time" into the middle of the day for 
two reasons:

* to avoid overlap between the AC meeting and Working Group meetings.

* in response to requests from some groups for sanctioned time to
   break into parallel task forces within their groups, for more
   cross-group interaction opportunities, and for hallway
   conversations.

The Working/Interest Group schedule for Monday, Tuesday, Thursday, and
Friday will thus be:

* 08:30-11:00: Traditional Group ftf meetings
* 11:00-15:00: Unstructured time (for those groups that so choose). This 
includes lunch.
* 15:00-18:00: Traditional Group ftf meetings

Encouraging all groups to schedule their unstructured time at the same
time creates more opportunities for interaction.

The AC meeting will take place during the 11:00-15:00 slot on Tuesday
and Thursday. AC Representatives who would also like unstructured time
within their Working Groups have the opportunity to use Monday and
Friday and thus avoid conflict with the AC meeting.

In late 2013 and early 2014 there was significant discussion on
w3c-ac-forum about this proposal, including some support and some
counter-proposals. We hope this arrangement will reduce AC/Group
overlap, and provide groups and AC Representatives sufficient
scheduling flexibility so that we can avoid extending TPAC to evenings
and weekends, or further shortening the AC meeting portion of the
week.

TPAC 2014 Meeting feedback will help us determine the 2015 structure.

--
Remote participation
--

Working and Interest Groups may request telephone access for remote
participants.

We do not yet have information on other W3C-provided remote
participation options during TPAC 2014. Assuming a positive
experience at AC 201