Bug 17180 - ER: Scrolling to fragment identifiers
Summary: ER: Scrolling to fragment identifiers
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Enhancement
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2008-02-05 05:09 PST by Nicholas Shanks
Modified: 2022-12-30 18:40 PST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicholas Shanks 2008-02-05 05:09:02 PST
I would like to suggest a couple of related enhancements to fragment identifiers:

1) Don't scroll so that the element containing the identifier is at the top of the screen, but so that the fragment is about 10% or 25% of the way down the view port. This is where people naturally look, they don't look a few pixels under the tab bar. You can make this an option for web browsers, rather than the default.

2) Highlight the fragment element by dimming the rest of the page for a few seconds. If you dim the page, then fade back to normal a few seconds later (similar to Safari's ‘find’ function), the user's attention will be drawn to the relevant elements. Obviously this feature would only work for code like <div id="content">content goes here</div> and not empty elements like <a name="page-top"></a>

These two features, combined, will vastly improve the user experience of navigating pages with fragment identifiers in the URL.
Comment 1 Alexey Proskuryakov 2009-03-17 06:20:11 PDT
<rdar://problem/6689638>
Comment 2 Ahmad Saleem 2022-12-30 15:44:50 PST
@ap - Is it something we need to track or this RADAR has been closed? Thanks!
Comment 3 Alexey Proskuryakov 2022-12-30 18:40:54 PST
These still seem like good ideas, and in fact this is how new "text fragment" identifiers work (except that they go to the center of the screen, not 10% or 25%). So keeping old behavior for regular fragment scrolling is also inconsistent.