#3545 closed defect (bug) (fixed)
WP15 Theme: Language switcher doesn't get fixed when scrolling
Reported by: | ChantalC | Owned by: | coreymckrill |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | General | Keywords: | wp15 theme |
Cc: |
Description
When you scroll down, the menu bar gets a fixed position. However the language switcher scrolls out of the screen.
Attachments (1)
Change History (13)
#2
in reply to:
↑ 1
@
7 years ago
Replying to Ian Dunn:
Which browser are you seeing that in?
Safari. In Chrome it also doesn't work nice.
#3
@
7 years ago
Hmmm, I can't reproduce it in either of those browsers, or Firefox. @coreymckrill, are you seeing it on your system?
#4
@
7 years ago
I can reproduce in Firefox and Chrome. When you scroll down the page past the site header, the navigation bar sticks to the top of the screen via some JS and CSS in the Twenty Seventeen parent theme. However, the language picker is not actually inside the navigation bar, and is added via the child theme, so it doesn't stick.
Some possible solutions:
- Move the language picker inside the nav bar, and then redo the CSS Grid styles to accommodate that.
- Recreate the JS and CSS from the parent theme to work with the additional language picker element.
- Let the picker disappear when scrolling down the page.
Thoughts, @melchoyce?
#5
follow-up:
↓ 6
@
7 years ago
Move the language picker inside the nav bar, and then redo the CSS Grid styles to accommodate that.
Recreate the JS and CSS from the parent theme to work with the additional language picker element.
What's the difference between these two options?
#6
in reply to:
↑ 5
@
7 years ago
Replying to Mel Choyce:
Move the language picker inside the nav bar, and then redo the CSS Grid styles to accommodate that.
Recreate the JS and CSS from the parent theme to work with the additional language picker element.
What's the difference between these two options?
The first one requires overriding the parent theme's template-parts/navigation/navigation-top.php so that it includes the language switcher template tag, plus a reworking of the CSS grid.
The second one leaves the language switcher template tag where it is in the child theme's header.php file, but would potentially require duplicating some of the parent theme's JS to add a new class to the switcher's container when the viewport scrolls down past the header.
#7
follow-up:
↓ 8
@
7 years ago
Thanks for the explanation :) Which one seems like less of a hassle to you?
#8
in reply to:
↑ 7
;
follow-up:
↓ 9
@
7 years ago
Replying to Mel Choyce:
Thanks for the explanation :) Which one seems like less of a hassle to you?
I mean, the least hassle would be letting the switcher disappear. Is that a viable option?
Of the other two, I already tried the first approach and got bogged down in weird CSS grid stuff, so I would probably try the second approach.
#9
in reply to:
↑ 8
@
7 years ago
Replying to coreymckrill:
Replying to Mel Choyce:
Thanks for the explanation :) Which one seems like less of a hassle to you?
I mean, the least hassle would be letting the switcher disappear. Is that a viable option?
I feel like as an English speaker, it's not effecting me, so I'd prefer to hear more from our non-English speaking community before making that kind of decision. Let's see if we can get some more input.
#10
@
7 years ago
I mean, the least hassle would be letting the switcher disappear. Is that a viable option?
My two cents as someone of a different mothertongue is that it's less about the switcher not being always available, and more that it disappears unexpectedly ("I thought there was a thingy to change the language?")
The first one requires overriding the parent theme's template-parts/navigation/navigation-top.php so that it includes the language switcher template tag, plus a reworking of the CSS grid.
I'm not familiar with this domain, but is the parent theme twentyseventeen
? Because, if so, changing it doesn't sound like the best idea. Or is the parent some other niche theme with less inertia that I may have missed?
Approach two seems viable. A drive-by suggestion, if you'd like to avoid duplicating the element-fixing logic from the parent, is to use something like MutationObserver
to react to changes to .navigation-top
's classes, synchronizing with the local switcher.
Which browser are you seeing that in?