This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Canvas drawing elements are associated with elements in fallback content to support accessibility. These elements may be keyboard accessible and they are designed to provide semantics to platform accessibility API in the user agent. Also, these elements must have associated bounds within the canvas drawing space. Native (in-browser) assistive technologies may wish to zoom these elements into view such that when coupled with the built in magnification features of today's browsers an in browser magnifier would be able to use this function to assist in zooming to the location of an entire drawing object that does not have focus.
Is there something wrong with the existing scrollIntoView method defined by CSSOM View? http://dev.w3.org/csswg/cssom-view/#dom-element-scrollintoview
Aryeh, Thanks for the question. This is dependent on these two bugs having a change proposal written which I have not submitted yet: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13181 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176 Where I plan to write a change proposal based on Jonas' post: http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0195.html Here we would be assigning drawing paths to elements. Do you think that the CSS layout will support bound drawing paths? If you think so then we may not need this. If you are sure that it will then I can close this. Rich
mass-move component to LC1
If we add the API that I proposed in http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0195.html then no more API would be needed. The normal scrollIntoView API from CSSOM View would be sufficient.
Do we want to address CSSOM further? It seems getBoundingClientRect / getClientRects would work as well, with Jonah's proposal. http://www.w3.org/TR/cssom-view/#the-getclientrects-and-getboundingclientrect-methods
(In reply to comment #5) > Do we want to address CSSOM further? It seems getBoundingClientRect / > getClientRects would work as well, with Jonah's proposal. > > http://www.w3.org/TR/cssom-view/#the-getclientrects-and-getboundingclientrect-methods I meant Jonas' proposal.
Jonas, so you believe the paths can be tied into the CSS layout engine? ... I don't know the lower layers of the browsers to answer this. ... If they can that is fantastic and yes I agree we would not need this added API.
Yes they can.
Alright, then this can be closed.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: Marking closed per reporter.
See thread.
(In reply to comment #10) > Status: Did Not Understand Request > Change Description: no spec change > Rationale: Marking closed per reporter. The request is similar to the WHATWG proposed method scrollPathIntoView(): http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-scrollpathintoview scrollPathIntoView() works with the current path. scrollIntoView(element) would work with an element present in the Canvas subtree. This is already covered by CSSOM, we simply need to improve UA handling of DOM elements in the Canvas subtree. That work will likely move forward as development of Web Components (and the shadow tree) moves forward.