Closed
Bug 822344
Opened 12 years ago
Closed 12 years ago
Top Navigation & Footer
Categories
(Websites :: Firefox Flicks, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: bensternthal, Assigned: craigcook)
References
Details
Code top navigation and footer.
Reporter | ||
Comment 1•12 years ago
|
||
Curated QA Comments
Header observations:
- Navbar options do not highlight at each new section at the current time
- We want the link to the blog to open a new window
Footer observations:
- Remove Panavision until contract signed TBD; remove for R1
- Social icons should in new browser window
- About Firefox OS should open in new browser window
- Footer links are not current (i think this is ok, this will update as you finish pages)
Reporter | ||
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 3•12 years ago
|
||
Craig:
A couple items came in from the team during qa:
1. Speed of the scrolling when moving from the navbar to the Rules, Prizes, Judges sections of the landing page. There's some feedback about it being too fast and jarring. Can we slow it down?
2. There is a slight jump in the header when you first click a link to scroll.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 4•12 years ago
|
||
(In reply to Ben (:bensternthal) from comment #3)
> 1. Speed of the scrolling when moving from the navbar to the Rules, Prizes,
> Judges sections of the landing page. There's some feedback about it being
> too fast and jarring. Can we slow it down?
I've slowed it down when scrolling long distances. When scrolling less than 1200px it takes one second to cover the distance (from one section to the next, for example). For distances greater than 1200px (e.g. from the very top all the way to the Rules section) it takes 2.5 seconds. I wouldn't want to go much slower than that or it seems to drag, but this should at least feel smoother and less whiplashy for long scrolls. I'll have this and other tweaks in a PR shortly.
> 2. There is a slight jump in the header when you first click a link to
> scroll.
The jump is largely unavoidable, given the design constraints. The script checks every 100 milliseconds (every tenth of a second) to see if scrolling has occured, and if so, it sticks the navbar to the top of the window. If there's been no scrolling (i.e. we're at the very top of the page), the nav isn't sticky and just lives where it would normally.
I originally tried to make that bar *always* sticky with CSS alone and none of the scroll detection business, but then it messes with Tabzilla; the drawer opens and the navbar still sticks to the top instead of sliding down with the rest of the page. Also I'm not sure we need sticky nav on any page but the home page, so all of the sticky business is on the home alone and everywhere else it's just positioned static at the top. Hence the further need for a simple way to toggle between sticky and not sticky. We could make it sticky on all pages but it would still need the toggle because of Tabzilla.
The slight jump happens when you begin to scroll and for one tenth of a second the navbar scrolls up with the page before the script detects the scrolling and toggles the sticky. It's most noticeable when you scroll really fast and cover some distance in that first tenth of a second. The only way to improve it is to check for scrolling at even shorter intervals, but even at a single millisecond it still jumps ever so slightly, and doing a scroll check a thousand times a second is a bit much.
So sadly I think we'll have to live with the jump, and I've minimized it the best I can (unless someone has any other ideas).
Speed of Scrolling: Thanks Craig. Kristin, does this work better?
Sticky Nav Jump: live with it we shall. I also notice it on State of Mozilla so it must be a thing.
Thanks, Craig.
Assignee | ||
Comment 6•12 years ago
|
||
(In reply to alainez from comment #5)
> Speed of Scrolling: Thanks Craig. Kristin, does this work better?
>
> Sticky Nav Jump: live with it we shall. I also notice it on State of Mozilla
> so it must be a thing.
Indeed, I reused the same function from SoM so it behaves the same way. But now that I think about it, the SoM layout is different in that the navbar isn't at the very top of the window there like it is here. For SoM we had to allow the nav to scroll part of the way and then stick when it reach a certain, unspecified point. This it had to keep surveying the scroll along the way, checking every 100ms to determine if the sticking point had been reached yet. For Flicks we can do a simple check the very instant scrolling begins and if it isn't at 0 (the very top), the nav can stick.
tl;dr: I lied, I can totally avoid the jumping navbar. Consider it done.
Comment 7•12 years ago
|
||
It looks good to me- but ideally someone else would help confirm.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•