- From: CSS Meeting Bot <notifications@github.com>
- Date: Thu, 13 Jun 2024 08:57:54 -0700
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/issues/463/2166085701@github.com>
The Web Editing Working Group just discussed `normative spec changes do not always end up as issues filed with browsers`, and agreed to the following: * `RESOLVED: File issues on each repo to add a PR template if appropriate. For specs where it's not clear, ask the Editors. Contents of template include a checkbox for 2 implementers are interested, links to implementation bugs, and checkbox that there has been consensus in WG for the change. Start with a PR on EditContext spec, where all members of the group get a chance to review. Issues on other specs can reference that template.` <details><summary>The full IRC log of that discussion</summary> <dandclark> topic: normative spec changes do not always end up as issues filed with browsers<br> <dandclark> github: https://github.com/w3c/editing/issues/463<br> <dandclark> johanneswilm: There was a change in input-events we agreed on, but it didn't end up in Apple's bug tracker<br> <dandclark> ...: To fix this Marcos proposed PR template<br> <dandclark> ...: Discussion is longer than just what's in this issue<br> <dandclark> ...: Question is should we have a template, or change how we work on these specs?<br> <dandclark> sanketj_: Whenever we make normative changes, should we file implementation bug? I think that's reasonable<br> <dandclark> sanketj_: Could resolve on that.<br> <dandclark> johanneswilm: For those specifications which are implemented in browsers to a reasonable extend, we add such a template to ensure for each change there are bugs filed.<br> <dandclark> ...: What we should not do is add this to more experimental specs where it's not clear if they will be implemented. Maybe on the way but not implemented yet.<br> <dandclark> ...: Or may never be.<br> <dandclark> sanketj_: That's fair. Do you mean selection API spec specifically?<br> <dandclark> johanneswilm: As I understand it we should have a distinction. execCommand spec you can't rely on it being implemented.<br> <dandclark> ...: Many things would need to change for it to reflect actual implementations<br> <dandclark> ...: We can go spec by spec. For selection API, ryosuke is editor. Communication so far is it's not where there is consensus on every change.<br> <dandclark> johanneswilm: We should not tie Ryosuke or Simon's hands when it's not clear spec is implemented. When they get to stage where want consensus, two implementations, then we can have template<br> <dandclark> smaug: Who owns that spec<br> <dandclark> johanneswilm: Spec says webapps, our charter says we own it. So I assume it is here.<br> <dandclark> smaug: That one has been implemented in all browsers, so we should be filing bugs. That would have caught this recent issue.<br> <dandclark> sanketj_: +1 to what Olli is saying<br> <dandclark> sanketj_: Chromium will be working on that in the near future. Important to get impl bugs filed.<br> <dandclark> ...: And it will be useful to discuss in this WG<br> <dandclark> smaug: getComposedRange is broken, needs massive changes<br> <dandclark> johanneswilm: If that's the state it's at we should have those discussions here.<br> <dandclark> Wenson: Has there been movement on this spec?<br> <dandclark> smaug: It was just changed<br> <dandclark> anne: We'll take it back to Ryosuke<br> <smaug> https://github.com/w3c/selection-api/issues/170 was a recent change<br> <dandclark> johanneswilm: Can we agree on the principle of making distinction between specs that are ready that should have template, and potentially others like execCommand that are not there?<br> <dandclark> ...: Cannot force on all specs that all changes are implementable<br> <dandclark> anne: Having a whatwg style template is a good idea<br> <dandclark> ...: Want bugs and tests, potentially more things<br> <dandclark> sanketj_: Can always file bugs, even if they don't implement the spec<br> <dandclark> johanneswilm: But say with EditContext, only implemented in Chromium. What does the template include? A link to specific issue for Chromium, then a link to general issue for both Webkit, Gecko saying "implement EditContext"?<br> <dandclark> sanketj_: Yeah<br> <dandclark> sanketj_: At some point the other browsers will start implementing<br> <dandclark> sanketj_: Once one engine ships, it's much harder to make changes<br> <dandclark> ...: There's higher risk of breaking changes. E.g. with getComposedRanges<br> <dandclark> ...: if we wait for 2 implementers, might be too late<br> <dandclark> smaug: So need at least 2 implementers for any change<br> <dandclark> ...: Would like have no objections also, though I know that's not in charter<br> <dandclark> johanneswilm: I agree it makese sense for EditContext to have that now, but for several years it was microsoft internal thing<br> <dandclark> ...: Wanted to start getting more consensus as it started to ship.<br> <dandclark> ...: But to need that consensus from the start, may not be helpful.<br> <dandclark> smaug: Have proposal for the new specific case, any changes to the proposal need to get approval. Exactly the model EditContext has now<br> <dandclark> johanneswilm: Should we say we can add such a template to all repos that are implemented in various browsers? can take them one by one.<br> <dandclark> sanketj_: At what point do we start filing implementation bugs?<br> <dandclark> johanneswilm: There's a w3c procedure.<br> <dandclark> ...: There's incentive to start getting consenus, we all want these things to be implemented everywhere<br> <dandclark> ...: We can make this more formal with template<br> <dandclark> smaug: Even more important that impl bugs, is to have template saying these implementers are OK with this.<br> <dandclark> johanneswilm: And this is at the stage where things are no longer experimental?<br> <dandclark> smaug: EditContext isn't now<br> <dandclark> johanneswilm: But we can continue to have ideas that don't end up being real specification or aren't implemented<br> <dandclark> smaug: Yeah<br> <dandclark> sanketj_: So when an explainer gets accepted by WG, that's the starting point. Once one implementer has shipped, should start filing impl bugs. One master bug for implementing, and specific bugs for specific bugs on browsers that have implemented.<br> <dandclark> smaug: Need interest from two implementers, no objections<br> <dandclark> sanketj_: No objection has been a problem in the past. Can be reasons browser can't implement spec.<br> <dandclark> johanneswilm: Explainer was filed at very beginning. Another case, the UndoManager proposal explainer. Filed years ago. If they put resources on it, makes no sense for them to need consensus on every little PR.<br> <dandclark> ...: There are no code examples, need to go much further for it to be something to work with.<br> <dandclark> ...: The explainer stage is too early<br> <dandclark> smaug: I would expect explainer to be something you could roughly implement<br> <dandclark> johanneswilm: Explainers for UndoManager, EditContext were years away from being implementable<br> <dandclark> johanneswilm: For EditContext there was a big gap between the explainer and a more concrete spec and implementation. All of that first phase, it would have been too complex to have gone through this process every time.<br> <dandclark> johanneswilm: Can we just go through the specs now and decide? Don't need to make a principled decision about when to add for new proposals.<br> <dandclark> Wenson: Sounds to me like if there's intent to actually ship, that's the difference<br> <dandclark> sanketj_: Sounds reasonable<br> <dandclark> johanneswilm: Should our action be - file an issue with each of our repos to add such a template if appropriate. If not appropriate, maintainer of spec can say so.<br> <dandclark> sanketj_: What's the content of the template?<br> <dandclark> sanketj_: Someone tried to add one, is that what we should use?<br> <dandclark> ...: It was "at least 2 implementers, none object"<br> <dandclark> johanneswilm: Can't say that, have to follow charter.<br> <smaug> https://github.com/w3c/clipboard-apis/pull/215 is the one for clipboard<br> <smaug> Just some random example from WhatWG https://github.com/whatwg/html/pull/7934<br> <dandclark> Proposed resolution: File issues on each repo to add a PR template if appropriate. For specs where it's not clear, ask the Editors. Contents of template don't include "at least 2 implementers, none object", but do include links to implementation bugs, and checkbox that there has been consensus in WG for the change. Start with a PR on EditContext spec, where all members of the group get a chance to review. Issues on other specs can<br> <dandclark> reference that template.<br> <dandclark> Proposed resolution: File issues on each repo to add a PR template if appropriate. For specs where it's not clear, ask the Editors. Contents of template include a checkbox for 2 implementers are interested, links to implementation bugs, and checkbox that there has been consensus in WG for the change. Start with a PR on EditContext spec, where all members of the group get a chance to review. Issues on other specs can reference that<br> <dandclark> template.<br> <dandclark> RESOLVED: File issues on each repo to add a PR template if appropriate. For specs where it's not clear, ask the Editors. Contents of template include a checkbox for 2 implementers are interested, links to implementation bugs, and checkbox that there has been consensus in WG for the change. Start with a PR on EditContext spec, where all members of the group get a chance to review. Issues on other specs can reference that template.<br> <dandclark> Sanket or Dan to add the PR on the EditContext spec.<br> </details> -- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/463#issuecomment-2166085701 You are receiving this because you are subscribed to this thread. Message ID: <w3c/editing/issues/463/2166085701@github.com>
Received on Thursday, 13 June 2024 15:58:03 UTC