ISSUE-176 Change Proposal

Previous Topic Next Topic
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

ISSUE-176 Change Proposal

Shelley Powers
Per request from HTML WG co-chairs[1], I'd like to submit the following
Change Proposal for Issue 176: Revert the Edit that removed the Editing
API from the HTML5 specification.


Recently, the HTML5 editor, Ian Hickson, removed the entire section
known as the Editing API from the HTML5 specification. However, the
material was not incorporated into a new W3C Working Draft, and as the
situation now stands, there is no text defining the Editing API for all
user agents.

The Problem:

The Editing API section of the HTML5 specification has been in the
document for some years now, and has been at least partially implemented
by more than one user agent. To remove this section leaves this API
undocumented, which could lead to lack of interoperability between
implementations within the various user agents.

In addition, by having this text in the HTML5 specification, and
controlled by the HTML WG, the concepts covered in the specifications
fall under the patent agreements that members enter into when they join
W3C working groups. This is important to ensure that all relevant user
agents feel comfortable implementing the Editing API, and that all HTML
WG members are made aware of any potential patent claims related to this
material before implementing this section.

(Incidental to this Change Proposal, but possibly relevant: Recently,
the W3C issued a Call for Exclusion for the HTML5 specification, as it
is defined in the HTML5 Last Call document. This LC document does
include the Editing API[2].  Frankly, I'm not sure what it means from a
legal stand point to issue a Call for Exclusion on material that is
subsequently and unilaterally removed from the WG document by one member
company, only. Perhaps the W3C Legal department should comment on this?)

As noted in the bug that led to this issue, not every member
representing a major HTML5 user agent agrees with the move to remove the
text documenting the Editing API completely from the W3C[3].

It's not as if the material covered is outside of the scope of the HTML
WG. Point of fact, the HTML WG is specifically chartered to provide
documentation of an Editing API as part of its requirements for
determining success[4]. In effect, removing this section undermines the
HTML WG's effort to reach a successful conclusion.


There are two possible solutions to the concerns outlined in the Problem

The first is to revert this edit, returning the Editing API section to
the HTML5 specification. If the reason why the section was removed was
because there are problems with the section, those who have concerns
about this section can then submit bugs outlining their concerns, which
can then be addressed individually.

The second is to propose a new Working Draft specification to the HTML
WG that covers the Editing API. This would ensure that the Working
Group's charter requirements are still met (providing documentation of
the Editing API), and would have the added advantage of further
simplifying the HTML5 specification--a worthy goal. If the editor of
this new specification wishes to also address the technical concerns in
the Editing API at the same time, I expect the group would find this
acceptable. If any new technical concerns are introduced with the
modifications, they can then be addressed individually as bugs.

(As it stands now, there is no way to address _any_ concerns about the
Editing API section, because the section has been completely removed).

A third option has been floated, which is to form a group within the new
W3C Community effort to encompass the Editing API. However, I do not
find this to be a satisfactory solution to the concerns I listed
earlier. The reason why is that, from my understanding of the W3C
Community Group, it's complimentary to the Working Group efforts, not a
replacement for the Working Groups. The ultimate goal for work coming
out of the Community Groups (again, if I understand the purpose of this
new W3C entity correctly),  is moving any specifications that arise in
the Community Groups into Working Groups for formalization.

Such intermediate effort isn't necessary for the Editing API. The HTML
WG is already chartered to provide some form of a deliverable for an
Editing API. Work has been underway for some time in the group to
provide an Editing API. It seems to me that trying to put this into a
Community Group is really a backward step, and contravenes the intent of
these Community Groups.


Reverting the edit has little impact, and shouldn't take much time, as
this is more of a version control change.

Creating a new document does take time, but has an added advantage of
being able to address areas of concern with one single move. And it does
simplify the HTML5 specification.

Thank you for your consideration of my change proposal.

Shelley Powers


Reply | Threaded
Open this post in threaded view

Re: ISSUE-176 Change Proposal

Shelley Powers
Sam Ruby, HTML WG co-chair did respond in the HTML WG.

I replied back, but the response will be bounced by the W3C email
system. I've duplicated the answer here:

First, I want to thank you for taking the time to read the change
proposal, and providing feedback. I do appreciate both.

However, and with all due respect, I won't be changing the text.

The Change Proposal process was meant to cover specific issues related
to the technical decisions related to the specifications--or at least,
that seems to be the general theme. The removal of the entire Editing
API was not a technical decision, it was a political one. It was one
member company, Google, acting unilaterally to not only subsume
responsibility for the Editing API, but also undermine the integrity of
the HTML WG and the W3C.

If Apple and Microsoft are indifferent to Google's actions, I'm not
going to spend a great deal of my time arguing this issue. I figured,
it's more their problem than mine.

If the HTML WG isn't going to challenge actions that directly undermine
its own credibility, I'm certainly not going to spend a great deal of my
time fighting for the group's viability. Again, if you don't care, then
I shouldn't care, either.

If you want to reject this change proposal because it doesn't meet some
"template", please feel free to do. I could consider filing a Formal
Objection, but frankly, the only ones really being hurt by any of this
are your members who are acting in good faith, and the Working Group's
and W3C's own credibility.

I had said I would write a change proposal for Issue 176. I have now
done so.

Again, thank you for taking the time to respond.