Re: [w3c/editing] Move execCommand to WICG (#184)

> 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.

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.   

> 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.

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. 

> 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.

Sure, that seems fine. 

> 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

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.    

> 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?

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. 

> 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.

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/184#issuecomment-437726963