- From: Frederico Caldeira Knabben <notifications@github.com>
- Date: Tue, 19 May 2015 02:48:52 -0700
- To: w3c/editing-explainer <editing-explainer@noreply.github.com>
- Message-ID: <w3c/editing-explainer/issues/48/103420051@github.com>
I see those specs as a separate part of the API browsers are supposed to provide for the scope of editing. The "HTML Editing APIs" idea seems to be bringing to specs the API we had on browsers for more than 10 years, without much changes or innovation. Still it is a very important work, because it aims to standardize the behavior of such API, including heuristics for several tricky cases to be faced during its implementation. This is important for those who care about that API. The work we've been doing here so far instead is all about those who don't care about that API. Well... maybe except for Selection, which IMHO should deserve its own spec and should not be limited to "editing hosts" (after all one can have selections in normal pages as well). I would not mix the efforts. cE should be an independent spec. If should be kept small and simple, so it will be ready at some point. execCommand and its siblings should be spec'ed independently. My advice is that, if you'll enter in the endeavour of taking those specs over, it'll severely delay the cE developments. Only if you think about taking it under the wings of this group but not working on it in the near future until cE is ready. Then in any case, ofc, both specs must be aligned, to (1) be sure that one is not entering on the field of the other one and (2) ensure that both play well together. --- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing-explainer/issues/48#issuecomment-103420051
Received on Tuesday, 19 May 2015 09:49:23 UTC