[Bug 22228] Clarification of timeout attribute late overrides
https://www.w3.org/Bugs/Public/show_bug.cgi?id=8 Ms2ger ms2...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ms2...@gmail.com Resolution|WORKSFORME |--- --- Comment #4 from Ms2ger ms2...@gmail.com --- This confused #servo too. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [charter] Addressable Ranges?
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 https://github.com/AFBarstow/WebApps/blob/master/charter.html (http://afbarstow.github.io/WebApps/charter.html) 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
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
[ 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] http://www.w3.org/2014/annotation/charter/ 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 https://github.com/AFBarstow/WebApps/blob/master/charter.html (http://afbarstow.github.io/WebApps/charter.html) 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
Re: [editing] Leading with ContentEditable=Minimal
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 ben.pet...@microsoft.com 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?
RE: [editing] Leading with ContentEditable=Minimal
On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com 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? div cursor=”true” commandEvents=”true”minimally editable content/div 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] CommandEvent and contentEditable=minimal Explainer
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 teleclim...@gmail.com wrote: On Fri, Jun 13, 2014 at 11:37 AM, Ben Peters ben.pet...@microsoft.com wrote: On Fri, Jun 13, 2014 at 1:01 AM, Ryosuke Niwa rn...@apple.com wrote: On Jun 12, 2014, at 5:07 PM, Olivier F teleclim...@gmail.com 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
On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote: On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com 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? div cursor=”true” commandEvents=”true”minimally editable content/div 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] Leading with ContentEditable=Minimal
On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com 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 divnot editable at all/div would get clipboard and drag/drop events, like it does today. div commandEvents=truebuild an editor here/div would also get CommandEvents.
