This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13391 - Add a ScrollElementIntoView function
Summary: Add a ScrollElementIntoView function
Status: CLOSED INVALID
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML Canvas 2D Context (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf, a11y_canvas
Depends on:
Blocks:
 
Reported: 2011-07-27 16:53 UTC by Rich Schwerdtfeger
Modified: 2011-09-22 16:33 UTC (History)
10 users (show)

See Also:


Attachments

Description Rich Schwerdtfeger 2011-07-27 16:53:14 UTC
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.
Comment 1 Aryeh Gregor 2011-07-27 22:06:30 UTC
Is there something wrong with the existing scrollIntoView method defined by CSSOM View?

http://dev.w3.org/csswg/cssom-view/#dom-element-scrollintoview
Comment 2 Rich Schwerdtfeger 2011-07-28 13:18:42 UTC
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
Comment 3 Michael[tm] Smith 2011-08-04 05:03:17 UTC
mass-move component to LC1
Comment 4 Jonas Sicking (Not reading bugmail) 2011-08-18 23:19:01 UTC
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.
Comment 5 Charles Pritchard 2011-08-18 23:58:38 UTC
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
Comment 6 Charles Pritchard 2011-08-19 00:00:28 UTC
(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.
Comment 7 Rich Schwerdtfeger 2011-08-19 13:08:07 UTC
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.
Comment 8 Jonas Sicking (Not reading bugmail) 2011-08-23 06:50:16 UTC
Yes they can.
Comment 9 Rich Schwerdtfeger 2011-08-23 14:08:08 UTC
Alright, then this can be closed.
Comment 10 Ian 'Hixie' Hickson 2011-09-21 17:24:17 UTC
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.
Comment 11 Rich Schwerdtfeger 2011-09-21 17:46:38 UTC
See thread.
Comment 12 Charles Pritchard 2011-09-22 16:33:03 UTC
(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.