RE: User Intentions Explainer (was: List of Intentions)
Rich Schwerdtfeger Ben Peters ben.pet...@microsoft.com wrote on 09/19/2014 03:55:46 PM: From: Ben Peters ben.pet...@microsoft.com To: Piotr Koszuliński p.koszulin...@cksource.com, Frederico Knabben f.knab...@cksource.com Cc: Johannes Wilm johan...@fiduswriter.org, public-editing- t...@w3.org public-editing...@w3.org, Julie Parent jpar...@gmail.com, public-indie...@w3.org public-indie- u...@w3.org, public-webapps public-webapps@w3.org Date: 09/19/2014 03:56 PM Subject: RE: User Intentions Explainer (was: List of Intentions) I agree that we can divide this work, but so far I think we should do 2 first. Being able to remove browser functionality with a simple API is going to be far quicker to implement (in browsers) and provides immediate benefit. Solving Intentions will be a longer process, but is also important to really enable performance and extensible-web scenarios. On Tue, Sep 9, 2014 at 4:28 AM, Piotr Koszuliński p.koszulin...@cksource.com wrote: I'm not sure if I remember correctly, but I believe that after long discussions we left the question what should contenteditable=minimal be? unanswered. First the intention events lists should be created, so we can see what needs to be handled. And this is what Ben Peters is working on. Still we may also take in consideration that there are limited resources available for working on the specs. Therefore the whole work could be separated into two *independent* topics: 1. Intention events + execCommand. 2. contenteditable=“minimal” So, you want to modify contenteditable to minimum. What will that do to existing apps. that are built on it? We have a number of IBM web applications that use contenteditable as do many other companies. CKSource (Piotrek is the lead developer) has an open source product called ckeditor that IBM contributed accessibility support to and so it is now used by many large enterprises including Oracle. A migration strategy is needed for existing consumers of contenteditable. That's what I was proposing as well - to have the base (which consists mainly of fixed selection API and intention events) ready as soon as possible, so hopefully browser makers can start implementing it and then we, editor makers, can start using it. This part will already improve the current situation a lot, but it's itself pretty hard as we can see. Then, if anyone will be still interested, a specification for default browser's actions can be created. It's a huge task and there are a lot of controversial topics like the famous delete/backspace behaviour when merging blocks and that's why I would not recommend starting these discussions right now. On Tue, Sep 9, 2014 at 12:59 PM, Frederico Knabben f.knab...@cksource.com wrote: On Tuesday, 9 September 2014 at 11:13, Frederico Knabben wrote: I don’t think that browsers having time/will for it today is a good argumentation for not doing it. The specs have a critical and noble scope, of serving as reference for the future of the web. We’re talking about the future after all. Still we may also take in consideration that there are limited resources available for working on the specs. Therefore the whole work could be separated into two *independent* topics: 1. Intention events + execCommand. 2. contenteditable=“minimal” “1” should be concluded asap, because it is the foundation for the success of “2”. It is also compatible with the current contenteditable=“true”, so it should enable sites/frameworks to fix the current status of things. I have to agree with Piotrek, 1 is more important to get done first. It is very important for mobile and we have real problems with device specific support across devices. We could refine 1 after 2 is attempted. “2” is the ideal world. Something that would require much more energy to get done right. Still in the beginning, there should be an agreement on what’s in and what’s out. Following that, several specs can get started, each one defining the default behavior we want for each of the features we want “minimal” to have. The first ofc, would be “Selection” (and “Focus”!). Rich -- Piotrek Koszuliński CKEditor JavaScript Lead Developer -- CKSource - http://cksource.com -- Follow CKEditor on: Twitter | Facebook | Google+ | LinkedIn
Re: User Intentions Explainer (was: List of Intentions)
On Mon, Sep 22, 2014 at 3:46 PM, Richard Schwerdtfeger sch...@us.ibm.com wrote: So, you want to modify contenteditable to minimum. What will that do to existing apps. that are built on it? As has been mentioned before, the current (and broken) contenteditable will stay the way it is, to make sure that nothing breaks for anyone. contenteditable=minimal or some derivative thereof will come additionally. With time, when all the frameworks have switched and the usage of contenteditable is close to zero, I would imagine that browser makers would likely decide to remove the contenteditable code. As for Ben's comments -- I think the question he made was to the main general purpose editors that stand for most of the user created content on the web. CKeditor is certainly one of them. Others are TinyMCE and possibly Aloha. And then there are a number of editors created by the browser makers themselves -- everything from Gmail, Google Docs to Micrsoft's online Word processor. Ben was asking whether being able to add items to the right-click context menu would be something editor creators would like to do. The issue with this was at least in the past that one can only choose to entirely replace the context menu, or not at all. If one replaced it, the browser's spell checker was gone. If one didn't replace it, there was no way to add extra options. Has this changed at all? I see for example that CKeditor has chosen to replace the context menu, and so the spell checker is gone. Would users of CKeditor not like to have access to the spell checker? Have you received any feedback on that? And for those who currently write the specs -- what more information would you need to go ahead? -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Re: [selection-api] Moving toward First Public Working Draft
On 9/22/14 3:55 PM, Ryosuke Niwa wrote: I think the latest documentation is pretty complete except it’s missing one major feature: selection.modify [1]. There was a discussion that took place in WHATWG [2] and there was a disagreement on the use case and the purpose of this particular API among UA implementors. I can add that note to the specification for completeness before FPWD is published for the patent protection purposes. OK, please do. Shortly, I'll start the CfC for FPWD. -Thanks, ArtB [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=9514 [2] http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Mar/0297.html
CfC: publish FPWD of Selection API; deadline Sept 30
Ryosuke proposes WebApps publish a First Public Working Draft of Selection API and this is a Call for Consensus to do so, using the following Editor's Draft as the basis (draft FPWD is [1]): http://w3c.github.io/selection-api/ This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does _not_ necessarily mean there is consensus on the spec's contents. If you have any comments or concerns about this CfC, please reply to this e-mail by September 30 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. Ryosuke - the current title is Selection API Specification. Is the Specification part necessary? If not, perhaps it can be deleted. -Thanks, AB [1] http://w3c.github.io/selection-api/?specStatus=FPWD;edDraftURI=http://w3c.github.io/selection-api/;publishDate=2014-10-02
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
During this CfC, Jonas submitted some comments to this list starting with the following: http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0531.html Jonas - did Mounir's responses adequately address your comments or is there something you propose be done before LCWD is published? There were also comments by Anne on Github (see [1]) and as I understand it, those comments were addressed by Mounir. Anne - would you please confirm if your comments have been adequately addressed? -Thanks, ArtB [1] https://github.com/w3c/screen-orientation/commits/gh-pages On 9/11/14 5:19 PM, Arthur Barstow wrote: Mounir and Marcos would like to publish a LCWD of The Screen Orientation API and this is a Call for Consensus to do using the latest ED (not yet in the LCWD template) as the basis: https://w3c.github.io/screen-orientation/ The spec has three open Issues, all labeled Future + Enhancement and the Editors propose these Issues not be addressed for this first version of the spec: https://github.com/w3c/screen-orientation/issues This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document used by this group states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] If you have any comments or concerns about this CfC, please send them to public-webapps @ w3.org by September 18 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed review period is 4 weeks. Assuming this CfC passes, if there are any specific groups (e.g. script-coord, TAG, WAI, Privacy IG, Security IG, Mobile IG, etc.) or external SDOs we should explicitly ask to review the LCWD, please let us know. -Thanks, AB
[Editing] Tracking Issues in GitHub
In order to simplify and streamline communication on open issues for Editing and Intentions, I suggest we have more conversations on GitHub. To that end, I have opened Issues for the list of bugs in the spec, and removed them from the spec itself. If there are no objections, please check out our GitHub Issues page [1] to open new issues and comment on existing issues. Ben [1] https://github.com/w3c/editing-explainer/issues
