Move execCommand to WICG #184
Comments
|
@marcoscaceres what note are you referring to? |
|
I assume that this is the large, red warning at the beginning of http://w3c.github.io/editing/execCommand.html
Moving this into WICG sounds good. I assume that at some point this spec will graduate into a W3C Note once there is no longer a need to make edits/updates. |
|
@garykac thanks for clarification! My understating is WICG is the incubation pool where we bake ideas to see if there is an interest in implementing it by browser vendors and also to asses community interest. All of the modern browsers have support for execCommand and it is heavily used in the wild, so I am not sure what we gain from moving it to WCIG? The fact that the spec is an unofficial draft stage says about a need in discussion among interested parties to standardize the behavior, sooner or later. |
That’s kinda the point. Right now its impending the success criteria of the group: which is to produce W3C Recommendations. The draft clearly states that will never happen. Hence, moving it to the WICG allows incubation of a standardizable subset amongst interested parties. Once there is agreement on what could actually go to REC, we can take this back and take it through the W3C process. Make sense? Or am I missing something? |
|
I’m not in favor of publishing as a Note, fwiw. As has been pointed out above, this is an important specification and a Note could signal “end of life” - which is not what we as a community want. This is why this spec needs to live somewhere that it can become a living standard (either at the WICG, or possibly at WHATWG). It’s totally ok if it never gets to REC. But that’s incompatible with this particular W3C working group. |
|
I'm not certain that this feature can ever get to a point where a meaningful subset of it is standardized & interoperable across major browsers. I actually think we're going to see the end-of-life of this feature before that (I'm talking in terms of 20-30 year span of time). |
|
@rniwa, that's my understanding too. I'd like your opinion about what you think we should do. Could you live with it moving out to the WICG or elsewhere? One advantage that I see from moving it to the WICG is that all browser vendors are already there (same as WebApps WG) AND we can more easily involved more library maintainers to help document cross-browser quirks, etc. |
|
I think moving this to WICG would be fine since I don't think any major browser is seriously considering to re-implement their editing code based on the spec. e.g. some of the recent spec changes weren't even something we would want to adopt in WebKit because it would go against the platform convention in macOS / iOS. |
|
I beleive, there was some interest in reviving execComamnd spec over at Blink, few years ago but if that changed then we should adjust. Few people in Edge also wanted to standardize it but we will go with the consenus on this one. Edge is somewhat interoperable with the spec but there is still work that needs to be done. If there is a consensus on this to not getting involved with it then it is a pretty strong signal to "end-of-life" and we should kill it. |
|
So, speaking for Gecko, I spoke to our engineering director and we don't have any plans to work on this for in foreseeable future. |
|
@marcoscaceres said
I don't see why. The Working Group's goal, even more than "produce Recommendations" is "do useful work in its scope", and a bureaucratic shuffle merely to keep our specs -> Recs tally looking good reminds me more of a super-efficient fictional hospital (see Yes, Minister) than a functional approach to the work we try to do. It does make sense to end-of-lie the spec at some point. It makes little sense to me that we move it away before we reach that point - that seems to optimise for administrative nicety over the people doing the work. |
|
I would also think it is fine to move it to WICG and I agree with others here that I don't see this being standardized in browsers. That being said, I do think it's important we continue to be able to edit it because we continue to get requests that are linked to execCommand in some way. For example juts a few days ago, from Firefox we basically had a request to add a number of inputTypes to the beforeinput/input events spec that are only available through execCommand. There are clearly some parts of the browser world who have not given up on execCommand (and history has shown that sometimes they can be right in not giving up on some features that are believed to be dead), and I would prefer to keep such execCommand extras in an execCommand draft spec rather than add execCommand-related things into all the new specs we are writing. However if it is an organizational issue for the W3C that the Editing taskforce needs to only produce production level specs, maybe we can solve this by simply making all members of the editing taskforce also members of this newly created WICG so that we can then edit the execCommand drfat spec if need be without having to make a separate meeting or a second group for that?
If chaals is right that there is not such a hard requirement of producing specs (and we will not move any faster with the other specs because the execCommand spec is now stored somewhere else), then I agree that it doesn't make sense to move it just yet. |
Absolutely! Nothing procedurally would change. In fact, moving it to the WICG would open it up to a wider audience of developers. And, more importantly, it would lower the barrier of entry for those that want to contribute as they don't need to join the W3C and they don't need to become invited experts.
This is definitely not about "giving up". No one is arguing that the specification is not important and that it shouldn't be developed further - like you said, all browsers depend on it! On the contrary: this is about acknowledging that the specification won't become a W3C Recommendation, hence doesn't make sense to live in a working group tasked with producing Recommendations. This continues to be an important specification that documents core Web functionality. Moving it to the WICG doesn't diminish its importance - just like if a spec moves to the WHATWG, it doesn't diminish its importance. It just means the expectations are different.
Sure, that seems fine.
Point of clarification: there would not be a "newly created" anything. The repo merely just gets moved over to the WICG organization here on Github. Then people in the community who want to take part just sign the IPR commitment over there, and work continues as it always has. It takes about 10 minutes to move stuff over.
Yeah, I don't imagine anything would change - how the community continues to work is up to the community. See also how Custom Elements works: we are no longer doing that in WebApps, yet it's fundamental to many things we work on.
I respectfully disagree with Chaals - which is why I'm rewriting the charter for the new Web Apps WG to be more focused on trying to get specifications to Rec. Please understand, each spec adds overhead on the Chairs, W3C Staff, and the WG itself - so if a spec is not ever going to become a Rec, then my preference as Chair is that it's not an explicit deliverable of the working group. See also WebIDL, which we also removed from the Working Group - and it's arguably the most important and fundamental spec to all Web APIs. Thus, as with the aforementioned specs, work on the spec most definitely doesn't stop just because it's listed as a WG deliverable! It can just happen elsewhere. |
Ok, so then it will be harder to find. Right now we are occupying github.com/w3c/editing for editing-related work and github/w3c/input-events for the one spec that is sufficiently developed to go through the W3C process. Instead of moving execCommand out of github.com/w3c/editing where it can easily be found, can we not just say that the editing folder is shared by the editing taskforce that is connected to the webapps group and the WICG? We could add some explanation on the frontpage of github.com/w3c/editing saying that only some of these are related to the webapps working group and the other ones we are working on outside of the webapps working group. I understand that you may have some requirement about spec counts, etc. for the working group from somewhere up in the system. But it would be good if that could be handled in a way that affects the editing taskforce as little as possible.
Ok, so this is a change because you are changing the statutes to introduce this requirement? Or is there some other entity behind this requirement? If it's only you, I'd suggest you just drop the requirement as it doesn't fit with our reality. If some other entity is really behind this (finance department,. etc.) then I hope we can find a solution that is disrupting our work as little as possible. |
No, because then they still sit in the w3c organization - and we only really want working group specs in the W3C org. Plus we keep the WICG ones in one place, and eventually pass them back to the W3C if they are going to be on the Rec track. I understand your position, but let's be pragmatic here... the editing specs are not a rapidly evolving set of specifications. execCommand hasn't been updated in a year, according to the below. The other specs range between 2-3 years since they've been touched, so it's not like it's disturbing some rapid moving task force (or am I looking at the wrong thing here?):
Additionally, GitHub also provides us with the ability to move issues, so even for those it won't cause much (if any) disturbance.
You could say it's me and the W3C, in as far as I've been tasked to chair the group and make it more successful (we have a clearly defined success criteria: get specs to Rec). Part of that is evaluating the viability of various specs in becoming a web standard. As stated by the execCommand document itself, this has zero chance right now of becoming a W3C standard. When that changes, then it would be appropriate to have it be part of the working group.
We are doing a reality check on all specs - might require some reality adjustments :) But that's what I'm here for, to help you through that.
As, I said, I'm happy to help move things to make things as painless as possible. |
No, but had these requests related to it over the past year: #179 (there could be more). In at least two browsers (Firefox and Chrome) developers are actively working on execCommand in some way and even though you can find me mention that execCommand is not really expected to go anywhere, there are these developers busy trying to fix it in various ways.
Ok, in that case this sounds a bit like the new public management of hospitals that chaals is referring to. It sounds like the intention is to help advance those specs that are on track. And this I think is a great idea - it has taken way longer than what it should to get the "Input Events" to go through the system and I could have used some assistance in understanding when we needed tests, etc. when I asked for that. But instead we now spend even more time discussing execCommand and I'm sure that once the execCommand spec no longer is there, we will be pressured into adding execCommand-related things to the other specs. That doesn't really seem to be in line with the original intention. Can we maybe change the status from a draft spec to a draft note or something like that so that it doesn't show up in your count? Then you don't have to worry about it any more. But OK. If your mind is set and you not willing to make any changes to your plan, then I guess we'll live with it. Can we at least link to the new locations of the documents on github.com/w3c/editing ? Else this will really turn into chaals, me and others working on editing being turned into the personal assistant of anyone looking for the execCommand spec (and when not finding it in "editing" starting a new one). And then we only spend more time with no added benefits. |
|
I'd point out that developers from both Firefox and Chrome have said they're +1 on moving this to WICG. Doing do won't impede any progress on execCommand; it will simply own up to the status of execCommand (i.e., it's not narrowing down on a Recommendation any time soon). |
|
All of the 4 browsers we are currently dealing with represent really large organizations. Such large organizations at times mean that not everything is super well coordinated. I am not so sure all developers, project leads, spec writers, etc. in those browsers agree on everything about editing, for example.If we don't have the Editing taskforce be the one place where everything related to text editing is dealt with, there may be no such forum. A few years ago we had such a situation. When I had joined the editing taskforce I met a lot of browser people very enthusiastic about going beyond execCommand. On the JavaScript side the production ready editors with larger programming teams behind them there was little concern about moving away away from execCommand because in practice that's what the editors had been doing anyway and unless browser makers would invest a lot of resources into fixing it, it wouldn't be used going forward anyway. So we were all in agreement when it came to editing - or so we thought. Yet we had been getting requests from various to fix this and that about contenteditable and execCommand. We then had to explain that that spec was actually somewhere else and the editor had turned into a fulltime student and had stopped responding to emails. That caused a lot of confusion as people turned to us for things they needed to have standardized concerning editing - afterall we were the editing taskforce -- yet what they saw as the key technology was somehow not maintained. When Ben Peters left and I took the Input Events spec over, I therefore made sure to find out if we could also take on those draft specs concerned with contenteditable and execCommand - not because we were going to finish them, but so that we could have one place of discussion about text editing. This is when we suddenly found out that there was a whole different community of browser developers, also working on related things although slightly different (I believe it was clipboard stuff). Yet their view on execCommand and inputevents was just about the opposite of what we had. And while he that that the execCommand document was a dead document, I suddenly had requests from these browser devs to please add or change this or that because it was going to ship in the next version of browser X and one had followed the practice of using the spec draft to document the browser behavior and compromises one had agreed to in that field even though the spec had no official standing in the W3C. This is when we had a lot of very heated debates on whether Input events was reinventing the wheel or whether execCommand was dead. The good thing though was that now we had everything in just one forum. And we did negotiate a truth from that and both an immediate way forward (Input Events spec + contenteditable) yet keep execCommand around as something similar to an Irish border backstop just in case things didn't go as we had anticipated as some were - and probably still are - convinced that we will fail with creating something that can work entirely without execCommand. Right now everyone in this discussion (but not all browser devs filing issues with us) seem to agree that execCommand is not going anywhere. I am also part of the group that that thinks this. But I think we should look at our recent past and accept that something similar could happen again if text editing is being split up into different fora again with different groups of browser developers creating different, uncoordinated APIs, all of which are half-implemented and JS editors continue to have to build their editors on a mishmash of interfaces. I also think this situation is limited in time: We are dealing with a situation that really had gotten out of hand, but really it should not always be like that. Once we really have something that can fully replace execCommand in all browsers that works for JS editors, we may finally see that the question of possibly reviving execCommand will be much less interesting. Disclaimer: I am reporting on historic events purely from memory, so some of this may actually have occurred somewhat differently. Most of it is probably documented in the form of email messages and github posts if someone really wants to research it. |
While I'm totally fine with the spec moving to WICG, I'm adamantly against moving contenteditable / execCommand spec out of https://github.com/w3c/editing/. Such a move is counterproductive and creates an unwarranted cognitive load for everyone involved. I see no reason the spec can't be in https://github.com/w3c/editing/ given WICG is still a part of W3C. |
It's not my preference, but definitely not a blocker. Could live with it living here. |
|
Ok, and can we have meetings (F2F, phone call, etc.) in a way so that they automatically cover both a newly created editing WICG and the existing editing taskforce automatically so that we can make resolutions on specs in either one? For example now there is a request to add a bunch of input types to the input events spec. The issue I have with those event types is that they are only meant to be used in conjunction with execCommand. So I would like to be able to have just one single meting where we can decide to put them into either the input events or the execCommands spec without having to first dial up another group and have a meeting with them as well. Basically I am asking if we can continue as before with the structural changes of moving certain things to WICG being done entirely below the surface so that we don't even have to think about it? |
Sure! As I said, nothing about how the team works changes. The change is about using a different spec status (stylesheet) and allowing more participation.
Sure - it's literally just changing two properties in the ReSpec config. The thing that you do miss out on is that you won't benefit from automated IPR checks - because the IPR bot will be confused about which working/community group this is. So that's the only thing you need to do is make sure new participants sign the WICG IPR commitments. That's it :) |
|
Ok, so if the document stays where it is, and we can have meetings that cover all the specs, so that we don't end up with two distinct editing communities, I think my main concerns are addressed, unless there are some legal aspects that I am unaware of (such as, for example, that if @LJWatson or @chaals are helping scribe an editing taskforce meeting they suddenly have to stop doing that because we are talking about something that is WICG for 15 minutes). If there is nothing like that, it probably doesn't make much of a difference to our work. I don't understand the point of doing it, but I am not a lawyer. |
It's exactly the same as with the WG. People who are not members can't make normative contributions to the spec without being members. Taking minutes, fixing typos, adding examples, other administrivia would not be substantive. But a new feature, or massive changes to the API, etc. would be.
Literally just a coat of paint:
Sorry I've failed to explain the benefits clearly enough. |
|
Closing in favor or #185 |
Given the note at the front of this spec, I'd like for us to move this specification to the WICG. Incubation work can continue there.
cc @LJWatson
The text was updated successfully, but these errors were encountered: