[Bug 12029] Define a process for "particularly exceptional circumstances"

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12029

--- Comment #4 from Sam Ruby <rubys@intertwingly.net> 2011-02-11 16:02:48 UTC ---
(In reply to comment #3)
> I don't think atob() and btoa() qualify as "new features".  They've been
> implemented interoperably for years by all browsers other than IE, and the spec
> merely codifies existing behavior.  They're extremely unlikely to be
> controversial, since the functions are very simple and the definitions given in
> the spec differ from how current browsers work only insofar as they standardize
> error handling.  Removing the definitions from the spec now will only delay
> interop on an existing feature.  In particular, I wrote thorough tests for the
> spec with the intent to submit them to the HTMLWG test repo, and now I have
> nowhere to submit them.

I intentionally used the word mundane as I did not think that the topic itself
is likely to be controversial; what I intended to focus on in this defect is
the process flaw in that apparently we (the chairs) weren't clear what the bar
is.

> So I would like to ask you (Sam) for clarification on whether, given the above,
> you think atob() and btoa() need to be removed from the spec.  If you do, then
> I'd like to ask that either you confer with Paul and Maciej and officially ask
> Ian to keep them removed, or that Ian re-add them, since the original e-mail
> clearly said that features would only have to be removed if the chairs (not
> just one chair) requested it.

I did not ask for Ian to remove it, and therefore will not ask him to re-add
it.

> Additionally, when this bug is officially handled, I'd like clarification
> specifically on whether full specification of editing commands
> <http://dev.w3.org/html5/spec/dnd.html#editing-apis> would count as a "new
> feature", since I'm now working on that.  It would be a lot of new spec text,
> but again, just standardizing an existing feature (where we have very little
> interop).  It's the sort of thing that would probably have to be tweaked a lot
> in response to implementer feedback, but I don't see it as likely to raise
> objections as long as it's just standardizing existing behavior.
> 
> If standardization of editing APIs is considered too large a change to make
> now, I'd like to hear plans on how and when this sort of thing can be
> considered again.  It should be obvious that we don't want a huge gap where no
> new features are added to HTML a la HTML 4.  The spec text can always be
> submitted at the WHATWG, but there would be no central place to submit tests
> (unless we want the WHATWG to fork the W3C's tests, which I'm not even sure the
> license would allow).

What goes into the spec is up to the Working Group to decide.  What I will say
is that if it is discussed with the working group, and nobody objects, then I
certainly wont.  Note: I am *not* suggesting that discussion ceases to occur
elsewhere.  All I am saying is that if you want something to appear in a W3C
spec, it probably is a good idea to actually discuss your ideas with the
associated Working Group.

At a barest minimum, I suggest that you open a bug on each of these topics.  At
a minimum, you will be guaranteed an editors response and the opportunity to
take issue with that response.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 11 February 2011 16:02:51 UTC