Re: Canvas 2D API specification update

On Oct 21, 2009, at 3:07 PM, Dailey, David P. wrote:

> Hostility? Hmmm... I didn't see that here. Can you direct us to  
> specific referents?

This is why I said "past attitude". I'd like to know what the current  
attitude is.

(Some of the past material I am referring to include Chris Wilson's  
strong advocacy to remove all of canvas from the spec and indeed from  
the HTML Working Group entirely; his statements that it might not be  
possible to implement on top of GDI; and his raising of vague patent  
concerns.)

I don't want to go digging through the archives and the Web for  
smoking guns, I'd just like to understand Microsoft's current intent.  
If the goal is to edit a spec that every browser but IE implements,  
then as one of Apple's representatives I am not comfortable with that.  
If Microsoft is interested in coming into the canvas-implementing  
fold, then I am much more positively disposed.

Regards,
Maciej

>
> cheers
> David
>
> ________________________________
>
> From: public-html-request@w3.org on behalf of Maciej Stachowiak
> Sent: Wed 10/21/2009 6:04 PM
> To: Eliot Graff
> Cc: public-html@w3.org; Adrian Bateman; Frank Olivier; Doug Schepers
> Subject: Re: Canvas 2D API specification update
>
>
>
>
> Is Microsoft considering a Canvas implementation in IE? I must admit
> to having some discomfort with the spec being edited by the one
> implementor that has *not* implemented Canvas so far. Good future
> stewardship of the API requires having a stake in its success, and
> Microsoft's past attitude towards Canvas has been one of hostility at
> worst and indifference at best. It seems to me that this creates the
> potential for significant conflict of interest.
>
> Regards,
> Maciej
>
> On Oct 21, 2009, at 12:58 PM, Eliot Graff wrote:
>
>> In his mail describing why he created a separate Canvas 2D API
>> specification, Doug Schepers wrote [1]:
>>
>>> There is a chance that currently Canvas could be a blocker on
>>> progress
>>> for the HTML5 spec, and at this point, Canvas is so widely
>>> implemented
>>> that I don't think it's at risk, so I hope this isn't disruptive.
>>> I am
>>> available to help with any editing that needs doing, but I hope that
>>> others will also work with this draft, and step into the editor  
>>> role.
>>
>> At Microsoft, we agree with the sentiments expressed by Doug, Maciej
>> [2], and others about creating a separate Canvas 2D API
>> specification. [3]  We are prepared to offer editorial resources to
>> aid in the completion of this separate specification. We have looked
>> over Doug's initial document, made some editorial enhancements, and
>> are prepared to follow through in taking feedback and maintaining
>> the specification.
>>
>> We believe that some sort of accessibility API functionality is
>> needed in the canvas element. However, the exact nature and depth of
>> that functionality presents a dilemma that may block progress on the
>> HTML5 spec. We also think that the Canvas 2D API may be a desirable
>> feature used in other technologies such as SVG.
>>
>> Starting with Doug Schepers' initial draft, we made changes to get
>> the document to adhere to the W3C PubRules [4], enhance readability,
>> and improve logical flow of the document. In addition, we foresee
>> adding sample code throughout the specification, where appropriate.
>> No normative changes have been made. As with all drafts, the Canvas
>> 2D API specification is still a work in progress. We would like to
>> solicit feedback about the changes that were made (see below TODO)
>> and about further changes that the working group would like to see.
>>
>> Our updated version is published at http://dev.w3.org/html5/canvas-api/canvas-2d-api.html
>> .
>>
>> [1] http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0002.html
>> [2] http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0007.html
>> [3] http://lists.w3.org/Archives/Public/public-html/2009Aug/0628.html
>> [3] http://www.w3.org/2005/07/pubrules
>>
>> Edits:
>> PubRules verified or applied throughout the specification, including
>> fixing broken links and applying accessibility requirements.
>> Addition of normative references to remove reliance upon links to
>> HTML5 specification
>> General language, formatting, and logical edits, such as:
>>      Alphabetizing attributes and methods within existing sections
>>      Editing sentences to make them easier to understand
>>      Breaking long sentences, noun stacks, etc. to enhance  
>> readability
>>      Reordering paragraphs to create more seamless flow within  
>> sections
>>
>>
>>
>>
>
>
>
>
>

Received on Wednesday, 21 October 2009 22:25:40 UTC