Navbar rework for mobile (repo page and more)

[CL-Jeremy]

This proof of concept serves as an idea for more thorough UX improvement on mobile. As I'm not really experienced in frontend feature development, there are many issues to which I lack the knowledge to work out a solution.

For example, I don't know how to keep the Author /part in Author / repo-name [etc.] separate in case of wrapping (currently implemented with display: flex), but leave the rest as one continuous line (currently when the repo name is too long, the labels would wrap to the next line even if there is space left in the previous line, since that has become effectively a block).

The idea does come from GitHub, though they use a drop-down menu for excessive navbar menu items. At least in the current Gitea theme, it's hard even to have a half-way good-looking design as it is now with new-menu.

If this concept gets adopted, it may be a good idea to also implement a similar strategy to the top bar, as there aren't many items there that will be used by the user on a daily basis. To my mind, having the avatar menu at all time in the top bar would make a lot more sense than the current design.

I do believe that out of the pending tasks for the next major release, the priority of mobile UX enhancements isn't really worth spending too much effort on as of right now. Still, I'd be very grateful if anybody picks up the idea and develops on that.

Testing on my iPhone SE. Would consider this progress as reasonably perceivable.

[CL-Jeremy]

The concept is to have the navbar scrollable (visual guidance could be added quite easily, I suppose – whether things like blurring is wanted is another question), and put the settings button somewhere else so the user could find it much more easily.

The dual-layer menu in the repo settings page is really inefficient due to high visual complexity, so removing that top layer. I think as the breadcrumb component is so eye-caching, the user would most probably find it familiar and naturally uses it to go back to repo home. A "back" button would be a waste of screen real estate, then.

[CL-Jeremy]

Developing on the idea from silverwind, I'm afraid I can't do much better than this without relying on JavaScript.

This fixes the bug on Safari (desktop and iOS) regarding gradients: cf. https://stackoverflow.com/questions/38391457/.

Display of repo name is more aligned to that with GitHub's mobile view. Labels are wrapped in-line properly. Alignment isn't perfect at all time, but I find it more or less visually acceptable.

Scrolling now works pretty smoothly on repo page. However there is a regression from last year's version at Gitea.com, that monochrome webkit scroll bars (box-shadow: none;), which is used for scrolling, becomes transparent now, as the code for this isn't seen any more while inspecting with my browser (comparing it to master at e. g. try.gitea.io). Haven't found the reason to that, as recompiling Fomantic did not solve it. Pinging @silverwind for that.

Sadly there isn't autofocus. There are two solutions without Javascript: nesting buttons with autofocus in tabs (anchors, which is against W3C convertions), or switch to button and forms completely and suffer from dirty URLs and breaks status bar indication - solution to the former is to use inline JavaScript, which is very, very old-fashioned and would mean that a mainly JavaScript-based approach, such as AJAX, would fit here. As not even GitHub has implemented this (uses a drop-down on repo page and leaves it as is on other pages like profiles and organizations), it's probably fine without it.

Worst case solution would be to (copy GItHub again and) modify new-menu for repo page and use a compact stackable UX. I personally don't see the need here.

[CL-Jeremy]

If anybody has an idea to fix the repo-buttons (watch, star, fork), feel free to drop it here. That'll be the next thing to do.

Also, the flex box in repo-title is almost the same as that on repo list views (profile, search, explore), so someone could pick up that.

[CL-Jeremy]

Trying to port this to arc-green and noticed I'm unable to just do var(--color-body)33 for 20% alpha...

I propose converting most accent colors to hue-saturation doublets so we could easily derive colors with functions everywhere, or at least HSL triplets so alpha could be applied...

[CL-Jeremy]

Well, radial-gradient does look a lot nicer for tabs than pure linear ones!

Was initially very concerned as every, single source seems to suggest that the at syntax is unavailable on Safari. Have I understood it wrong? It effectively displays the same as Chrome and Firefox on iOS 10 and OS X Yosemite, which are over 4 years old now.

Changes since last commit:

• Ported the navbar overscroll shades to arc-green, reworked on shadows (removed that extra one on repo settings, since that isn't used in this PR any more)
• Reworked on splitting and z-indexing up the divider on repo page, so no more broken lines on different devices
• Fixed explore page new-menu not correctly stacking on @mediaSm
• Other small fixes (alignment, scrollbar)

[CL-Jeremy]

Late summary due to PC issues.

Just noticed on my Firefox for Android that it uses linear gradient, so reverting back.

Scroll bars should work just fine on all platforms. Unfortunately, elements might not stretch fully at certain zoom levels (e. g. initial height 40px, set margin-bottom to -10px, and result might be 50px or 49.60px depending on the zoom level). I'm not able to put a scroll bar for WebKit-based browsers with transparent background over navbar elements, therefore leaving it below in a white background.

Some mistakes elsewhere were fixed as they created alignment problems with this PR.

As with the spacer in the repo thing: Firefox always needs it; Chrome never needs it (tested on Chrome 62 on OS X 10.9.5); Safari doesn't seem to need it any more as of 14 (an earlier Tech Preview, as well as all previous versions needed it, don't have a current iOS version for testing). If someone finds a more reliable/concise way than this please let me know...

[CL-Jeremy]

Screenshots (Android 5.1.1):

[codecov-io]

Codecov Report

Merging #14704 (e9cbb30) into master (487f2ee) will increase coverage by 0.04%.
The diff coverage is 40.67%.

@@            Coverage Diff             @@
##           master   #14704      +/-   ##
==========================================
+ Coverage   42.21%   42.25%   +0.04%     
==========================================
  Files         767      774       +7     
  Lines       81624    82994    +1370     
==========================================
+ Hits        34458    35072     +614     
- Misses      41531    42227     +696     
- Partials     5635     5695      +60     

Impacted Files	Coverage Δ
cmd/dump.go	0.93% <0.00%> (-0.01%)	⬇️
cmd/serv.go	2.61% <0.00%> (-0.02%)	⬇️
cmd/web.go	0.00% <0.00%> (ø)
cmd/web_graceful.go	0.00% <0.00%> (ø)
cmd/web_letsencrypt.go	0.00% <0.00%> (ø)
models/action.go	48.52% <0.00%> (-2.42%)	⬇️
models/migrations/migrations.go	2.59% <ø> (ø)
models/migrations/v130.go	0.00% <0.00%> (ø)
models/migrations/v166.go	0.00% <0.00%> (ø)
models/migrations/v172.go	0.00% <0.00%> (ø)
... and 190 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cc64704...e9cbb30. Read the comment docs.

[CL-Jeremy]

Adding examples from GitHub to reference my change from break-all; back to break-word; in order to minimize the chance that a line break in the middle of a repo or an owner name kicks in at all.

[CL-Jeremy]

Reverted last change in favor of this:

[CL-Jeremy]

No explicit scroll bar yet except pic. 3, where rounded corner has a glitch and blurring is not showing. Still better than nothing, though...

[zeripath]

Hi @CL-Jeremy sorry this never got merged - if you're able to resolve the conflicts quickly - we can move this back to 1.15 but otherwise I'm going to move this to the 1.16 milestone and we can take another look at this then.

[lunny]

Please resolve the conflicts.

[oilipheist]

Thoughts on keeping project name and breadcrumbs separate like gitlab? that way you could have larger project avatar while providing smaller text for navigation breadcrumbs.

Another side effect of separating it is that you now have a project wide accessible breadcrumb that helps you navigate issues, pull requests etc and pull everything together from a UX point of view.

[oilipheist]

and here is an example of what happens when you have an especially long breadcrumb …

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions.

[wxiaoguang]

This PR stales for so long time and can not be merged. The UI has changed a lot and a lot of problems has been resolved by some recent PRs separately.

Feel free to reopen it or pick it as a new one. 🙏