update charter #215
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,70 @@ | ||
|
|
||
| **Confidentiality:** Proceedings are [public](https://www.w3.org/2005/10/Process-20051014/comm.html#confidentiality-levels) | ||
|
|
||
| **Chairs(acting as delegates from the WebApps WG chairs):** Johannes Wilm (Invited Expert), Grisha Lyukshin (Microsoft) | ||
|
|
||
| **Meeting Schedules:** Teleconferences: On an as-needed basis. Preferably, a minimum of one status meeting per month. Face-to-face meetings: On an as-needed basis. Video Conferences: On an as-needed basis. | ||
|
|
||
| ### Abstract | ||
|
|
||
| Enabling rich editing experience on the web is currently a challenging task. Reasons are many. For example, lack of requirements in the behavior of the `contenteditable` attribute in HTML, currently, the only browser primitive providing rich editing surface to web developers. Also, lack of support for low level editing APIs that would allow web developers to build rich editing experiences without getting browsers interference in this process. | ||
|
|
||
| Editing Task Force sets out to explore limitations in existing browser primitives, provide use cases for new APIs and suggest solutions either by standardizing of existing behaviors or introducing new APIs. The goal is to facilitate the creation of fully-featured editing systems as well as small editors using JavaScript. | ||
|
|
||
| The Task Force (TF) is part of the [W3C WebApps Working Group](https://w3c.github.io/webappswg/). The TF works primarily within its editing community on [Github](https://github.com/w3c/editing) and will report the results of its activities back to [W3C WebApps Working Group](https://www.w3.org/2019/webapps/). | ||
|
|
||
| TF is leveraging the existing editing [GitHub](https://github.com/w3c/editing) repo with well-known locations and history of discussions on a variety of editing-related topics in order to “incubate” new editing-specific standards. | ||
|
|
||
| This charter is intended to reflect on the current direction of the TF group, so that there is common agreement. It may be altered at any point in order to reflect new priorities or work items. | ||
|
|
||
| ### 1. Scope | ||
|
|
||
| The scope of Editing TF covers multiple aspects of editing, which may include: | ||
|
|
||
| - Textual input and text manipulation | ||
| - Text editing related events | ||
| - Selection | ||
| - Clipboard | ||
| - Spellcheck and grammar checking | ||
| - Reusing or discarding parts of or entire pre-existing editing APIs to serve as primitives of editing systems | ||
| - Standardization of under-specified existing editing related features | ||
| - Highlighting parts of text ranges without inducing DOM mutations. | ||
|
|
||
| Experts who are contributing members of the task force will contribute to documents produced by the group, as described in the section on deliverables below. | ||
|
|
||
| ### 2. Deliverables | ||
|
|
||
| This Task Force will: | ||
|
|
||
| - ensure that browsers are developing APIs that meet the expectations of editing framework authors of varying skill and team sizes. | ||
| - allow a network of experts to share information about gaps and requirements for building editing frameworks on the web. | ||
|
|
||
| The specifications the Editing Taskforce is producing may be driven to the spec level directly by its members within the Web Applications Working Group, or be transferred to another, more appropriate working group after initial collection of requirements. Furthermore, the group defines its success as when it at the very least, produces a recommendation with well defined requirements that result in enhancing existing text editing related specification drafts or helps design new ones. | ||
|
|
||
| The TF is expected to work on the following efforts until the end of the charter but it is not meant to be an exhaustive list: | ||
|
|
||
| - [Async Clipboard API](https://bugs.chromium.org/p/chromium/issues/detail?id=931839) | ||
| - [ContentEditableDisabled](http://w3c.github.io/editing/contentEditableDisabled.html) - ability to disable system UI | ||
| - [EditContext API](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/EditContext/explainer.md) | ||
| - [Highlight API](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/highlight/explainer.md) | ||
| - Native Selection and Caret behaviors | ||
| - [SpellChecker API](https://github.com/w3c/editing/issues/166) | ||
| - [SIP Policy](https://github.com/whatwg/html/issues/4876) | ||
| - [Input Events](https://www.w3.org/TR/input-events-1/) | ||
| - [ContentEditable](https://w3c.github.io/contentEditable/) | ||
|
|
||
| Deliverables are expected to eventually be shipped as Recommendations by the Web Applications Working Group, CSS Working Group or any other group where a draft specification may fall into. | ||
|
|
||
| ### 3. Participation | ||
|
|
||
| This task force is designed to make participation relatively easy for people not currently involved in the standards process (typically, developers of editing tool libraries) who may not be amenable to signing up to a large in scope discussions that can be found in, for instance, the main Web Applications Working Group. | ||
|
There was a problem hiding this comment. @ylafon or @siusin This is also a bit problematic from an IPR perspective. We encourage folks to participate, but if we also want them to become members - or, at least, Invited Experts. As written, this seems at odds with the function of the W3C Working Groups (vs community groups, where we are much more liberal). There was a problem hiding this comment. @marcoscaceres This paragraph was part of the original taskforce charter back from when it was first set up. There was a problem hiding this comment. Understood, but a lot has changed since then. There was a problem hiding this comment. I believe the people who were previously not part of WebApps and who did join the task force did so as Invited Experts of the WG (not 100% sure this has been renewed through the various rechartering, but that was at least the intention initially). The more focused scope is relevant in terms of attention span, but certainly the IPR regime that applies has to be that of the WG as a whole. There was a problem hiding this comment. That is true. I and several others were made the Invited Expert of some WG, even though we had no clue about what that WG was about or working on and we would not show up to any of its meetings. There was a problem hiding this comment. @johanneswilm, as external folks engage with the work, encourage them to become Invited Experts (the IPR bot will yell at them regardless if they try to make any pull requests, but if you see someone making substantive suggestions in bug, it's important to get them to join the WG as Invited Experts). The Chairs would be really supportive of that. There was a problem hiding this comment. @marcoscaceres we wanted to remove any barriers in people's participation. I agree that it is fair for people to become Invited Experts if they are ready to commit significant time and effort into editing discussions. (by the way, how do people become Invited Experts?). That said, do people need to go through the process if they just wanted to dial-in or leave comments/open issues in github? There was a problem hiding this comment.
It's pretty easy: the Editor's nominate them to the Chairs/Team (team-webapps@w3.org). Then they just fill out a form. It's a quick process.
Generally no... but it depends on what kind of contribution they are making. If they are adding something that is significant/substantive ("let's add a feature X! it would work like this: ..." or "browser behavior should follow this model: ...") then yes, they MUST become an Invited Expert - what you need to be on the lookout for is for someone claiming "this was my idea!" (because they could have a patent on it). If they are just fixing typos, examples, etc. then the do not need to be an Invited Expert. If unsure, ask the Chairs - and be overly cautions. There was a problem hiding this comment. @marcoscaceres understood, thank you. We'll update the wording in a bit. There was a problem hiding this comment. wording has been updated. Let us know if it works for you. |
||
|
|
||
| **As per W3C IPR requirements, if a participant plans on making more than light editorial changes or propose new approaches and APIs, TF chairs will need to be notified and nominate you to become an [Invited Expert](https://www.w3.org/participate/invited-experts/).** | ||
|
|
||
| The group encourages questions, comments and all technical discussions on its public [mailing list](https://lists.w3.org/Archives/Public/public-editing-tf/) and [document repositories](https://github.com/w3c/editing). | ||
|
|
||
| Participants are reminded of the [W3C's Code of Ethical Conduct](https://www.w3.org/Consortium/cepc/). | ||
|
|
||
| ### 4. Decision Policy | ||
|
|
||
| The Editing Task force operates under the WebApps Working Group's [decision policy](https://www.w3.org/2019/05/webapps-charter.html#decisions) and adheres to the WebApps WG [working mode](https://www.w3.org/2019/05/webapps-charter.html#working-mode). | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,17 @@ | ||
| Editing Task Force | ||
| ================= | ||
|
|
||
| These are specifications and explainers developed by the Editing Task Force. | ||
|
|
||
| **Actively developed specs:** | ||
|
|
||
| * See the [Editing Taskforce Charter](CHARTER.md) | ||
|
|
||
|
|
||
| **These specs are incomplete and it is not expected that they will advance beyond draft status:** | ||
|
|
||
| * [Content Editable True](http://w3c.github.io/editing/contentEditableTrue.html) | ||
|
|
||
| * [execCommand](http://w3c.github.io/editing/execCommand.html) | ||
|
|
||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ylafon + @siusin, some of these are not in our charter, and given that "Task forces do not publish technical reports", how can we include these? Do we need to recharter the Web Apps WG?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If anything there is on TR and not in WebApps's charter, I guess that a rechartering (or at least a discussion about it) is appropriate. For those that are just EDs or explainers with no presence on TR, I'd consider these under incubation, which is an informal affair that can happen anywhere. They could be added to the charter now, but I don't think it's particularly urgent to do so until we try to publishing them as FPWD (if we're there already, then yes, they should be added).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally speaking, the preference is that incubations happen at the WICG - but it would be ok to incubate things in the WebApps WG as long as they appropriately marked as incubations (i.e., they be clearly labelled "unofficial" until such time that they are not). I sympathetic that everyone who needs to be part of the discussion is following the w3c/editing repo and associated mailing list, which is why I'm also supportive of incubating within WebApps.
Yes, that makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK, respec takes care of marking a spec as not being official as long as one marks it as an editor's draft and not a working draft beyond FPWD. That's really the distinction there is right? Either it's pre-FPWD in which case it's "unofficial" or it is post-FPWD in which case it starts being recognized by the W3C and then psot-rec when it really is soemthing with the W3C's stamp of approval on.
Or do we need to make a distinction between official and unoffical pre-FPWD editor's draft?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All we need to do is set
"specStatus": "unofficial"in the ReSpec config. Same thing we did withexecCommand.