repository names

Hey again,

I was asked to keep the historic editing apis document (
http://w3c.github.io/editing-explainer/historic-editing-apis.html ) in a
separate repository. I have not done this yet, because I would like to make
sure we use the right repository names, as the current situation is rather
complex (see below).

I am not sure it makes sense to divide the repositories like this, but if
we do, I think we should rename the repositories "historic-editing-api" and
"editing-task-force", but I'm also open for other names. If it's just one,
I would call that one "editing-taskforce".

Is anyone opposed to making this change? I have investigated, and it
shouldn't be a problem to keep all the repository redirects in place ot the
new location.

Also, what do you think about 1 or 2 repository solutions? Ideally, the W3C
wants each spec in an individual repository, but they don't want to
dedicate ten different repositories to this task force either.

-----------------------------------------------------------------------------------------
With the move executed, there will be two repositories:

A) "editing-apis" -- which I would rename to "historic-editing-api". It
holds one document that is not a spec but just an overview of the research
done on how various editing and selection commands worked two years ago.

The history of repo A is just the history of the mercurial repository and
some new commits that transform the editing-document to use respec for
formatting and that make sure that it is not mistaken for a normative spec.

B) "editing-explainer" -- which I would rename to "editing-taskforce". It
holds all specs that are still developed, it also holds the task force
charter and two "explainer" documents, one of which is called the
"editing-explainer".

The history of repo B contains BOTH the history of the mercurial repository
AND the previous editing-explainer repo. From the mercurial repository the
same editing-document has been transformed to use respec for formatting,
the parts about selections has been removed and the rest has been
transformed into an early version of an execCommand specification.


I think it's important to develop Aryeh's document further in these two
directions. When he wrote it, it seems to have been as a research of
current behavior with a an aim of standardizing the behavior of selections
and execCommand. It is important to keep the historic overview of editing
apis and to improve it as browser behavior changes, bugs get fixed, etc. .
At the same time, we now no longer are sure that we will keep all parts of
the existing editing apis, so our efforts go beyond standardizing the
existing behavior. We need to be able to create new functions, or to decide
we want to deprecate execCommand entirely or create an equivalent function
with a new name as a replacement. Until now this was always very vague,
with some suggesting we should count on execCommand being there, but
possibly not relying on the existence an editing host at all while others
suggested we add a warning saying that execCommand may not be present for
cE=typing..

That's why we need clarity and the execCommand specification needs to
develop independently of the historic overview of what is available
already.

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org