RE: Request to re-open issue 131

> We will provide a change proposal



The Decision Policy (V2) [1] clearly states that a request to reopen an issue MUST be accompanied by a Change Proposal:
The following are the steps to request reopening :
1. Submit a Reopen Request
A request to reopen an issue should be submitted to the public-html@w3.org<mailto:public-html@w3.org> mailing list. A request to reopen should identify the issue to be reopened, and should include the following:
*         Material new information relevant to the decision, for example of the type identified by the decision itself as relevant.
*         A revised Change Proposal incorporating the new information as rationale.
For reopening to be seriously considered, this new information and proposal must be likely to have been enough to materially change the decision, lacking refutation or additional new information,

Therefore the WG Chairs are NOT amenable to re-opening ISSUE-131 at this time.  We encourage you to follow the above procedure when you have a Change Proposal ready.



Please note as per the WG Decision Policy that any reopen request MUST be sent to public-html@w3.org<mailto:public-html@w3.org>.



/paulc

HTML WG co-chair



[1] http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#reopening



Paul Cotton, Microsoft Canada

17 Eleanor Drive, Ottawa, Ontario K2E 6A3

Tel: (425) 705-9596 Fax: (425) 936-7329



From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]

Sent: Tuesday, October 25, 2011 11:56 AM

To: Sam Ruby; Paul Cotton; mjs@apple.com; public-canvas-api@w3.org; public-html-a11y@w3.org

Cc: Frank Olivier; chuck@jumis.com; Cynthia Shelly

Subject: Request to re-open issue 131



Paul,



Per your request. I would like to request that the chairs reopen issue 131.



In the chair's decision on issue 131 (http://lists.w3.org/Archives/Public/public-html/2011Apr/0270.html)



- The chairs did not have adequate information as to the definition of a text Baseline property supplied in text metrics.

- The removal of canDrawCustom was not adopted even though it was possible for an author draw a custom focus ring without it matching the actual path provided to drawFocusRing.



 We would like to reopen this issue for the following reasons:



- We will provide a change proposal that includes the additional information needed to define the text baseline and because after discussions with developers, such as Tab Atkins, it was agreed it would be of tremendous value to have the text baseline to compute focus rings around text rendered on the canvas.

- I spoke with Maciej at the Apple campus after the decision and he felt it would be better for developers to have two separate API for drawing focus rings. One would be for drawing a focus ring that took on the standard platform drawing conventions for a focus ring and a separate custom focus ring that would allow an author to draw a custom focus ring but still drive magnification features in the browser.

- I would like to bring our spec. closer to WhatWg which attempted to separate out drawFocusRing into two methods for the reasons Maciej stated. Ian had made those changes to the WhatWG spec. after also speaking with Maciej.





http://lists.w3.org/Archives/Public/public-html-a11y/2011Jul/0123.html





Rich Schwerdtfeger