Oops, my bad. I didn't mean to include window.atob() in the W3C copy. Will take care of that.

Re [3], not sure what you mean. You specifically said to open a new bug on the topic [6], and the policy [2] states that a "UA behavior bug" is likely to be fine, so I fixed it. I'm happy to revert it in the W3C copy if you think that's the right thing to do (in fact I mentioned on IRC that I expected that would happen). Let me know what I should do there.

I haven't looked at [5] yet, so I doubt it has resulted in any change to the spec, so presumably there's nothing for me to do there either.

[6] http://lists.w3.org/Archives/Public/public-html/2011Jan/0415.html

Checked in as WHATWG revision r5867.
Check-in comment: remove window.atob/btoa from the W3C draft
http://html5.org/tools/web-apps-tracker?from=5866&to=5867

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.

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.


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

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

Sam, your vague responses are infuriatingly unhelpful and not effective group leadership nor conducive to efficient use of the working group members' time.

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

I'm going to assume this is Sam-speak for "atob() and btoa() are not examples of things that fall into the category of things that the enhanced change control e-mail applies to, despite it having been listed as an example of such in comment 0", and will re-add this feature.

It would be lovely if in the future you could be clearer about what you actually want. Thanks.

Checked in as WHATWG revision r5874.
Check-in comment: revert 5867, which was apparently based on a miscommunication
http://html5.org/tools/web-apps-tracker?from=5873&to=5874

(In reply to comment #5)
> Sam, your vague responses are infuriatingly unhelpful and not effective group
> leadership nor conducive to efficient use of the working group members' time.

You want me to be clear?  Fine.  I got an email from somebody asking me the origin of this feature.  After investigating, I found that it was added to the W3C draft well after after the cut-off, and furthermore to date I have found absolutely no evidence that there was any discussion in the W3 working group about this feature.
 
> > I did not ask for Ian to remove it, and therefore will not ask him to re-add
> > it.
> 
> I'm going to assume this is Sam-speak for "atob() and btoa() are not examples
> of things that fall into the category of things that the enhanced change
> control e-mail applies to, despite it having been listed as an example of such
> in comment 0", and will re-add this feature.

I did not say anything remotely like that.  The chairs are still discussing this, and may very well come to a different conclusion.
 
> It would be lovely if in the future you could be clearer about what you
> actually want. Thanks.

What I want: features added to the W3C draft to be discussed by the W3C WG.  Given that we have bugzilla notification routed to public-html, this can be as simple as requesting that any new feature be recorded in bugzilla.

That isn't how our charter works. It specifically says "We expect that typically, an editor makes an initial proposal". That's all that happened here. I made a proposal to the W3C HTML working group, as per the group's charter.

To address this bug, I propose language something like the following, to be added in a new "Last Call" section of the decision policy document. This is just a rough take, it probably needs to be cleaned up to be generic to any WG draft.

-------

As we move through W3C maturity levels, the process requires gradually locking down the spec. In particular:

* If substantial technical changes are made after a Last Call Working Draft, then the Working Group cannot proceed to Candidate Recommendation and must publish another LCWD. While it is not entirely clear what kinds of changes are substantial enough, it seems like feature additions, or for that matter feature removals, probably are.

* During Candidate Recommendation, if anything beyond very minor technical changes are made, other than dropping features marked "at risk", then the WG cannot proceed to Proposed Recommendation and must return to Working Draft status.

Given these rules, it seems wise to be careful about anything that is even arguably a feature addition - even arguably ambiguous cases such as documenting longstanding de facto standard features.

Thus, the Chairs propose that during the current pre-LC period, and during Last Call, feature additions or removals should only be done with sufficient prior notice to the group, in the form of a bug. We are not making bug filing mandatory for editorial changes or even technical changes that correct an error. We're also not trying to put any constraint on the WHATWG HTML draft. From the W3C HTML WG point of view, it is reasonable to add a feature to WHATWG HTML but then not propose it for inclusion in W3C HTML5 at all, if it is not ready to go through a stabilization cycle. It is also ok to put such features in other drafts. However, in order to fulfill process requirements, we can't have features freely added to the W3C draft without sufficient advance notice.

(In reply to comment #9)

Generally +1

> Thus, the Chairs propose that during the current pre-LC period, and during Last
> Call, feature additions or removals should only be done with sufficient prior
> notice to the group, in the form of a bug. 

If we can trust people to operate in good faith, I am OK with us not elaborating on this further, as long as it is widely understood that the following proposal does not constitute "sufficient prior notice":

http://krijnhoetmer.nl/irc-logs/whatwg/20110211#l-1532

> We are not making bug filing
> mandatory for editorial changes or even technical changes that correct an
> error.

I'd like the bar a little higher than that: I suggest that any change that affects an approved test case requires sufficient prior notice to the group.

(In reply to comment #9)
> * If substantial technical changes are made after a Last Call Working Draft,
> then the Working Group cannot proceed to Candidate Recommendation and must
> publish another LCWD. While it is not entirely clear what kinds of changes are
> substantial enough, it seems like feature additions, or for that matter feature
> removals, probably are.
> . . .
> Thus, the Chairs propose that during the current pre-LC period, and during Last
> Call, feature additions or removals should only be done with sufficient prior
> notice to the group, in the form of a bug.

Why is there any constraint on the pre-LC period?  Per W3C process, we're still a WD and can change freely now, no?

> We are not making bug filing
> mandatory for editorial changes or even technical changes that correct an
> error. We're also not trying to put any constraint on the WHATWG HTML draft.
> From the W3C HTML WG point of view, it is reasonable to add a feature to WHATWG
> HTML but then not propose it for inclusion in W3C HTML5 at all, if it is not
> ready to go through a stabilization cycle. It is also ok to put such features
> in other drafts. However, in order to fulfill process requirements, we can't
> have features freely added to the W3C draft without sufficient advance notice.

If the motivation is to conform to process requirements, I don't see how prior notice is relevant.  If the change is substantial, then we can't proceed to CR, and if it's not, we can -- regardless of whether there was prior notice given.

Furthermore, there appears to be no process limitation on changes right now, pre-LC.  And once we've made at least one substantial technical change during LC (as is almost certain to happen), we have to go back to WD anyway, so further substantial technical changes impose no additional process requirement that I can see, as long as they're not disputed.


To fulfill process requirements, it seems to me that it would be sufficient to do something more like:

1) During WD, substantial technical changes are allowed, but if such a change is disputed by anyone, it should be removed and punted to a future HTML version so that we don't get bogged down in an unlimited stream of new issues.

2) During LC or CR, no substantial technical changes are allowed without group approval, unless the group has already approved at least one substantial technical change (necessitating a return to WD), in which case see (1).

Would these be insufficient to satisfy W3C process requirements?  If so, why?  If not, clearly there's some reason for your proposal beyond just satisfying W3C process requirements, and I would be interested in hearing it.

(In reply to comment #10)
> > Thus, the Chairs propose that during the current pre-LC period, and during Last
> > Call, feature additions or removals should only be done with sufficient prior
> > notice to the group, in the form of a bug. 
> 
> If we can trust people to operate in good faith, I am OK with us not
> elaborating on this further, as long as it is widely understood that the
> following proposal does not constitute "sufficient prior notice":
> 
> http://krijnhoetmer.nl/irc-logs/whatwg/20110211#l-1532

Why not?  Automatic notice is still notice.  Or do you object to it not being meaningfully "prior"?  If so, I think you should clearly state some time period, e.g.: no substantial technical changes except in response to a bug that's been open on the issue in the W3C tracker for at least 48 hours.  (Practically speaking, I don't see why it matters, since the change can easily be reverted after the fact.)

> > We are not making bug filing
> > mandatory for editorial changes or even technical changes that correct an
> > error.
> 
> I'd like the bar a little higher than that: I suggest that any change that
> affects an approved test case requires sufficient prior notice to the group.

I don't know why you think that raises the bar, since virtually no normative statement in the spec has an approved test outside of canvas.  When we do have a comprehensive test suite, on the other hand, even minor bug fixes are going to affect approved test cases.

Resolved along the lines of comment #9 here:

http://dev.w3.org/cvsweb/html5/decision-policy/decision-policy-v2.html.diff?r1=1.27&r2=1.28&f=h

I did *not* add a requirement about any change that affects an approved test case. "particularly exceptional circumstances" applied to feature additions, so I addressed that. If anyone believes we should tighten the requirements on any change that affects a test case, then I suggest filing a follow-up bug.