- From: <bugzilla@jessica.w3.org>
- Date: Mon, 27 May 2013 11:21:38 +0000
- To: public-css-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22176
Bug ID: 22176
Summary: Allow scrolls to elements to be positioned at an
offset of the viewport
Classification: Unclassified
Product: CSS
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: CSSOM View
Assignee: dave.null@w3.org
Reporter: simonp@opera.com
QA Contact: public-css-bugzilla@w3.org
http://lists.w3.org/Archives/Public/www-style/2013May/0361.html
[[
> Similarly, I've seen a lot of the social sites that support j/k style
> navigation between posts do this: plus.google.com and the tumblr feed I'm
> pretty sure do it.
This doesn't update the URL bar or the history, and wants to scroll an
element into view, so scrollIntoView() seems like the best fit here.
An issue though is that plus.google.com's j/k navigation wants to position
the post under the header, so a normal link doesn't work, and the current
scrollIntoView() doesn't work, either (the post would be positioned behind
the header).
We could make scrollIntoView() take an argument that supports positioning,
which has been proposed in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17152 but that proposal
seems suboptimal here where we want "under the header" rather than "X%
from the top of the viewport".
For pages that have a fixed header, I think it would be nice to be able to
offset navigations/scrolls to elements. For instance, we could introduce
something like
@viewport { scroll-top-offset: 100px; scroll-left-offset: 50px; }
which would cause both <a href="#foo"> links and scrollIntoView() to
scroll to that offset instead of the top of the viewport.
What do people think?
]]
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 27 May 2013 11:21:47 UTC