W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: The Canvas 2D API split

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 11 Jan 2010 06:04:19 -0800
Cc: HTMLWG WG <public-html@w3.org>
Message-id: <4346F3FA-89D9-4C45-88C8-E7BC223AC38C@apple.com>
To: Shelley Powers <shelley.just@gmail.com>
Hi Shelley,

Thanks for your input.

On Jan 10, 2010, at 7:10 AM, Shelley Powers wrote:

> There was an original split of the Canvas 2D API[1], and an email list
> created, supposedly to maintain it[2]. The proposal was created before
> our change procedure was in place, so the item was left as a bug, and
> the issue was never cleanly resolved. It just went into some form of
> trackless limbo.
>
> Now, Ian has created a split[3], but there's no connection between it
> and the previous work, and nothing from the originators of the
> original split whether they're interesting in supporting one or the
> other[4].

It seems to me that neither Doug nor Eliot asked Ian's permission or  
approval before doing their split, and likewise Ian is not obligated  
to ask theirs. But ultimately, the Working Group will have to decide  
which of these Canvas 2D API drafts to proceed with.

>
> And the split document is confusing. In contains the line:
>
> "This specification is an HTML specification. All the conformance
> requirements, conformance classes, definitions, dependencies,
> terminology, and typographical conventions described in the core HTML5
> specification apply to this specification. [HTML5CORE]"
>
> Actually, it is not an HTML specification. A 2D API is not HTML. And
> the document references another document that has already been
> rejected by the group, based on the other splits and merges that
> happened this week.

See my comments on the Communication draft. If and when this document  
gets to FPWD, we will have a bug component for it, and run the bug/ 
issue process on the new spec in the usual way. We can even create a  
component ahead of time, if that would be helpful. Some suitable ways  
to object to such language in the 2D Context spec would be:

- File a bug when/if the 2D Context component is created in bugzilla,  
and follow up in the usual way.
- When/if the document is put forward for FPWD, raise a resolvable  
objection about this language (e.g. "I object to publication unless  
the claim that the specification is 'an HTML specification' is  
removed").


> There are now two separate proposed splits, neither of which is
> tracked, or part of an issue, and neither is there seemingly any path
> forward in this group to resolve what I perceive to be a disconnect
> between the original bug, and this week's activity.

One thing we now seem to have consensus on is removing the 2D Context  
API from the main spec. Or at least, no one has objected to this so  
far. That's great. I believe closing out the bug is the right way to  
reflect that.

What we now need to decide is what document, if any, we'll publish as  
a replacement. The proper way to decide that is to discuss things and  
then put forward one or more FPWD resolutions for API drafts. If we  
find that the authors of both documents want them published and cannot  
reconcile their differences, then we may resort to the issue process.  
But the issue process is only for actual controversies, and not to be  
used speculatively.

>
> What II'm proposing is that this bug be grandfathered into the current
> Change Proposal process, except that rather than muck about with the
> bug, we create an issue for the split. We ask Adrian Bateman, the
> originator of the original bug, and Doug Schepers and Eliot Graf if
> they concur with submitting their original document as a change
> proposal. We also submit Ian's as an alternative proposal, and we call
> for a discussion on both, as well as other proposals.

As stated before, we'll only resort to the heavyweight process if both  
editorial teams want to proceed with FPWD and the Working Group only  
wants to publish one of the two specs. In other words, only if there  
is an actual controversy, not speculatively.

> We could potentially end up with a merged document as consensus, but
> right now, we have two documents floating around, neither of which is
> a FPWD, and neither of which has an official path associated with it.
> And I'm not terribly sure that either is a document we can live with
> -- a split of this magnitude should be discussed, and a formal
> resolution given.

If anyone has a concrete objection to either document, then it would  
be appropriate to raise it. The purpose of the issue process is to  
resolve actual disputes where the parties feel so strongly that they  
want to escalate. It is not appropriate to use it as a fishing  
expedition to flush out objections.

> More importantly, we need to determine the proper home for the 2D API.
> I do not believe the HTML WG is it. I do believe that it should have
> its own working group, and had thought the effort to create the group
> was underway.

It is a previously recorded Working Group Decision that Canvas  
(including the 2D API) is in scope for the HTML Working Group. That  
doesn't mean we *have* to publish it, but it does mean that we have  
decided that the HTML Working Group is at least one suitable home. Per  
the W3C Process, that decision can only be revisited if there is new  
information.

That being said, I think our rough consensus (including Doug and  
Eliot) was to publish a Canvas API spec as an HTML WG work item for  
now, but consider moving it to a different group at some point in the  
future. I don't believe there was any concrete effort ongoing to  
create such a group, but in any case, it is a separate issue from  
doing the split or which standalone canvas API spec to use.

> Though I agree with splitting the 2D API out of the HTML document, I
> don't believe the split should be impulsive, and without review and
> careful consideration. Or that we allow this seeming disconnect
> between the past effort and this week's effort to continue.

I don't believe there was any review prior to Doug and Eliot's take at  
a split, but that's ok, because there has been plenty of opportunity  
for review since. And review of a concrete document is much more  
effective than review of an idea. We can apply that same principle to  
Ian's take at a split.

That's the end of my process comments as Chair.

--------------

For what it's worth, here's my own take (statements below are personal  
opinions and not with my chair hat on):

1) My understanding is that we had rough consensus that the Canvas API  
spec should be revised to include only the CanvasRenderingContext2D  
interface and related interfaces, but not the element. To date this  
work has not been done to Doug and Eliot's draft, but Ian's draft  
makes the split as agreed.

2) Doug and Elitot's draft has not been touched for over two months,  
since Eliot did his round of revisions. Prior to that, there was  
another 2 month gap after Doug's original check-in. It seems like  
Eliot and Doug may have a hard time getting this spec ready for Last  
Call in a timely manner, given their many other responsibilities.  
That's not to cast aspersions on them - I have also had the experience  
of signing up to edit a spec and then finding it a challenge to make  
the time.

3) Previously, Ian has said that he'll agree to split out  
CanvasRenderingContext2D if someone else does the work. Now he's  
showing willingness to do that work himself. I see this as a positive  
development.

4) There are a number editorial changes I would propose if and when  
Ian's draft gets to FPWD, to read better as a standalone spec. For  
example, the SotD section could use revision, and the "1 Conformance  
Requirements" section is missing the usual introductory material and  
instead jumps right into defining all the IDL interfaces. However, I  
am largely satisfied with the technical content.

Thus, overall, I see Ian's draft as more likely to deliver a  
standalone canvas API spec as a timely manner, and therefore I think  
it would be in the best interests of the WG to go with that draft.  
However, I think meeting technical requirements, and showing a track  
record of responsible editorship, is more important than who edits.  
Thus, if Doug and Eliot's draft is updated to meet requirements and  
shows a track record of timely editing, then I will not have a strong  
opinion either way. (Yes, this contradicts my previous concerns about  
Eliot's editorship, which after further discussion and consideration I  
have withdrawn.)


I would be interested to hear from Doug and Eliot on this issue.


Regards,
Maciej
Received on Monday, 11 January 2010 14:04:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:57 GMT