RE: [editing] Leading with ContentEditable=Minimal

[Ben Peters]

On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent  wrote:
>
> 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?

The way I see it is that not editable at all would get clipboard and 
drag/drop events, like it does today. build an editor 
here would also get CommandEvents.

Re: [editing] Leading with ContentEditable=Minimal

[Julie Parent]

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?

Re: [editing] CommandEvent and contentEditable=minimal Explainer

[Julie Parent]

I certainly understand the concern that it would be impossible to properly
catch and cancel all events.  But I think that is somewhat the point - it
forces browser vendors to get these parts right.  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.


On Sun, Jun 15, 2014 at 11:49 AM, Piotr Koszuliński <
p.koszulin...@cksource.com> wrote:

>
> On Sun, Jun 15, 2014 at 5:15 AM, Olivier F  wrote:
>
>>
>> On Fri, Jun 13, 2014 at 11:37 AM, Ben Peters 
>> wrote:
>>
>>> On Fri, Jun 13, 2014 at 1:01 AM, Ryosuke Niwa  wrote:
>>> >> On Jun 12, 2014, at 5:07 PM, Olivier F  wrote:
>>>
>>> >> Imagine as well a situation where a UA creates a new way to paste
>>> content, and to prevent confusion with "paste" they decide to create a new
>>> ua-prefixed event "uaMagicPaste". Now our end-users have a  way of pasting
>>> content into our editor's DOM without any intervention at all on our end,
>>> resulting in breakage and bugs.
>>>
>>> This is a good point. Registering for and calling preventDefault() on
>>> CommandEvent and BeforeSelectionChangeEvent will catch all new events in
>>> those categories, but ClipboardEvents must be listened to individually
>>> (Cut, Copy, Paste). We should consider whether we disallow new
>>> ClipboardEvent types or allow a generic ClipboardEvent listener, which
>>> would catch uaMagicPaste. I'll add a note to the Explainer for this.
>>>
>>
>> Yes, we could add ClipboardEvents and funnel all clipboard events through
>> there, that would work.
>>
>> But I also noticed that Issue 3 was added: "Do we need DragEvents too".
>> And yes we do, good catch! It is totally possible to alter the DOM of a
>> contentEditable by dragging something on top of it.
>>
>> I guess we can add DragEvents, but to me this illustrates why the
>> practice of enumerating and capturing all current and future events to
>> preventDefault them is not the right approach.
>>
>> For enumerate+preventDefault to work, every possible event that could
>> change the cE's DOM has to fire correctly and cancel correctly. Every one.
>>
>> I can't help but to feel that there will always be something missing.
>> Something we didn't think of in the spec, something the UA forgot to
>> implement, some bug that prevents the event from being fully canceled, or
>> some brand new interaction paradigm with its own event Class. Just one of
>> these in effect in one major UA and editor devs all over are in pain.
>>
>> So long as enumerate+preventDefault is the only way for editor devs to
>> control their editors, I'm concerned that there will be a constant source
>> of difficulty trying to work around the "leaks" in the spec/ua/future, and
>> that the end-user experience will continue to suffer as a result.
>>
>>
> I've got very similar feelings about all this. For years features have
> been randomly added to contentEditable=true and structuring them now seems
> for me as undoable. As I commented in [1] and [2] there are features
> related to contentEditable that do not fit in the CommandEvent and
> CommandQuery proposals very well. We agree that undo, clipboard and drag
> and drop interfaces have to be separated from commands. Why not other? Why
> all other features have to be pushed into "commands" section?
>
> If the commands' related APIs (I do not include very useful low level user
> intent events into that) and commands themselves will lack precision, then
> the only use that a cross-browser editor could make of them will be to
> disable everything. And we'll need to hope that we haven't disabled too
> much (e.g. clipboard events) or too few things, because imprecise spec will
> not clarify this.
>
> Less is better. Give us stable platform and we'll build great solutions on
> top of that. Make the platform unpredictable and we'll be fighting it the
> rest of our days.
>
>
> [1]
> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0867.html
> [2]
> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0876.html
>
>
>
> --
> Piotrek Koszuliński
> CKEditor JavaScript Lead Developer
>

RE: [editing] Leading with ContentEditable=Minimal

[Ben Peters]

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?

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

Re: [editing] Leading with ContentEditable=Minimal

[Julie Parent]

If Intention events are (temporarily) moved out of scope, 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?  If this is all it would do, then perhaps what
we really want is an explicit API to enable cursors?


On Mon, Jun 16, 2014 at 11:12 AM, 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?
>

CfC: to add Robust Anchoring API to WebApps' charter; deadline June 23

[Arthur Barstow]

[ Was: Re: [charter] Addressable Ranges? ]

Doug proposes WebApps include a Robust Anchoring API in its charter and 
this is a CfC to do so. The specific proposed addition is below and it 
includes this API being a joint spec with the proposed Web Annotations 
WG (draft charter is [1]).


If you have any comments or concerns about this proposal, please send 
them by June 23 at the latest.


-Thanks, AB

[1] 


On 6/16/14 1:05 PM, Doug Schepers wrote:

Hi, Art–

Following on from the discussion at the AC, here is my suggested wording:

[[
Robust Anchoring API

Defines APIs for finding, addressing, and linking to a document 
selection based on a set of selectors, even when the document has 
changed. This may be a joint deliverable with the proposed Web 
Annotations WG.

]]

The timeline is for a FPWD in Q2-2015, with a Rec in Q4-2016; this 
needs some development, though I hope we can make good progress.


The group liaison could be:

[[
Web Annotations Working Group
This proposed group is interested in several of WebApps' 
specifications, as well as having a joint deliverable (Robust 
Anchoring API).

]]

We have resources to work on this deliverable, including an editor. 
This deliverable is being added for consideration by the AC during 
review; if not accepted by the AC, then the Web Annotations WG will 
work on it alone, but I'd rather it were developed under the eyes of 
the WebApps WG.


Any other details you need?

Regards-
-Doug

On 5/14/14 8:54 AM, Arthur Barstow wrote:

On 4/25/14 8:44 AM, Arthur Barstow wrote:

On 4/22/14 9:40 AM, Doug Schepers wrote:

Hi, Art–

There are different approaches that could be taken, but one concrete
implementation in JavaScript is from the Hypothes.is Annotator [1].

https://hypothes.is/blog/fuzzy-anchoring/


OK, so at this point, I think it would be helpful if you would please
provide a diff or a PR against

() so we can evaluate
your specific proposal.


Doug - are you going to provide a diff? Without a relatively firm
commitment from WebApps, my inclination is to not add this to the 
charter.


Philippe - what is the next step to get WebApps re-chartered (current
charter expires May 31)?

-Thanks, AB

[editing] Leading with ContentEditable=Minimal

[Ben Peters]

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?

Re: [charter] Addressable Ranges?

[Doug Schepers]

Hi, Art–

Following on from the discussion at the AC, here is my suggested wording:

[[
Robust Anchoring API

Defines APIs for finding, addressing, and linking to a document 
selection based on a set of selectors, even when the document has 
changed. This may be a joint deliverable with the proposed Web 
Annotations WG.

]]

The timeline is for a FPWD in Q2-2015, with a Rec in Q4-2016; this needs 
some development, though I hope we can make good progress.


The group liaison could be:

[[
Web Annotations Working Group
This proposed group is interested in several of WebApps' specifications, 
as well as having a joint deliverable (Robust Anchoring API).

]]

We have resources to work on this deliverable, including an editor. This 
deliverable is being added for consideration by the AC during review; if 
not accepted by the AC, then the Web Annotations WG will work on it 
alone, but I'd rather it were developed under the eyes of the WebApps WG.


Any other details you need?

Regards-
-Doug

On 5/14/14 8:54 AM, Arthur Barstow wrote:

On 4/25/14 8:44 AM, Arthur Barstow wrote:

On 4/22/14 9:40 AM, Doug Schepers wrote:

Hi, Art–

There are different approaches that could be taken, but one concrete
implementation in JavaScript is from the Hypothes.is Annotator [1].

https://hypothes.is/blog/fuzzy-anchoring/


OK, so at this point, I think it would be helpful if you would please
provide a diff or a PR against

() so we can evaluate
your specific proposal.


Doug - are you going to provide a diff? Without a relatively firm
commitment from WebApps, my inclination is to not add this to the charter.

Philippe - what is the next step to get WebApps re-chartered (current
charter expires May 31)?

-Thanks, AB

[Bug 22228] Clarification of timeout attribute late overrides

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=8

Ms2ger  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ms2...@gmail.com
 Resolution|WORKSFORME  |---

--- Comment #4 from Ms2ger  ---
This confused #servo too.

-- 
You are receiving this mail because:
You are on the CC list for the bug.