[SMF 2.1]Remixed Breadcrumb

[TwitchisMental]

Thanks for sharing that information Ant.

[Antechinus]

Also it looks like the article didn't bring up if the user would prefer to start at the end (where you are), or the default behavior starting where you come from. Would require JS to keep the scroll at the end by default I imagine.

The examples shown in the article seem to default to default to starting at the home end, and they seem to think that is fine. It would probably make sense for the majority of users too, since I assume right-handed users would naturally be more inclined to swipe left. I hold the phone in my left hand, and flicking my right forefinger left to swipe left just comes naturally. Swiping right is less intuitive for me.

[Antechinus]

Just had a thought about this scrolling breadcrumbs thing. It may be possible to improve it further by using scroll-snap.

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scroll_snap/Basic_concepts

This could be used to ensure that you always end up with the currently displayed link left-aligned (or right-aligned for RTL languages) instead of possibly being sort of half in and half out of the viewable area. It'll still get chopped if it's longer than the available width, but at least the text you see will start in a logical place. I'll play around with it and see what turns up.

[Antechinus]

I just got around to trying this on a theme I have been playing with, and I have to say it works really well. Code is minimal, and these days we're all used to scrolling lists of stuff sideways on our phones. The images folder on Android is a perfect example. If you have sub-folders inside it, you get a scrollable horizontal list of your sub-folder names above the content.

Anyway, the guts of it is this:

Code Select Expand

.nav-breadcrumbs {
    display: flex;
    padding: 0 6px 0 0;
    font-size: 1.2rem;
    line-height: 3.2rem;
    overflow-x: auto;
    overflow-y: clip;
    scroll-snap-type: x proximity;
    scrollbar-color: var(--bsf-dabac) var(--bsf-dabac);
    scrollbar-width: thin;
}
/*    ------------------  */
/*    Get cunning here.
/*    ------------------  */
.nav-breadcrumbs:hover {
    scrollbar-color: var(--bsf-libac) var(--bsf-dabac);
}
@media screen and (hover: none) {
    .nav-breadcrumbs {
        scrollbar-color: auto;
    }
}
/*    ------------------  */
.nav-breadcrumbs li {
    flex: none;
    overflow: hidden;
    max-height: 3.2rem;
    scroll-snap-align: start;
}
.nav-breadcrumbs a {
    position: relative;
    display: block;
    padding: 0 1.8rem 0 .6rem;
    color: var(--bsf-metex);
}
.nav-breadcrumbs a::after {
    position: absolute;
    top: -.7rem;
    right: .3rem;
    width: 0;
    height: 0;
    content: '';
    border-style: solid;
    border-width: 2.3rem 0 2.3rem 1.4rem;
    border-color: #0000 #0000 #0000 var(--bsf-mebac);
    filter: drop-shadow(.2rem 0 0 #000) drop-shadow(.1rem 0 0 var(--bsf-libor));
}
Some of that is eye candy, of course. The important bits are:

• Flex makes sense for the parent ul, IMO.
• overflow-x: auto; obviously gives you your scrolling. Auto is better than scroll, because it won't force a scrollbar on desktop when the width is more than adequate, but works the same as scroll on touchscreen.
• overflow-y: clip; is necessary to stop your linktree moving vertically if you have anything (like groovy absolute-positioned arrow pseudos) extending above and below the anchors.
• scroll-snap-type: x proximity; is my personal preference at this stage, but you can play with other options.
• scrollbar-color can be used to make a desktop scrollbar invisible by default, changing to visible on hover, and resetting to user agent default on touchscreen.
• scrollbar-width: thin; makes sense on desktop for this use case, IMO.
• scroll-snap-align: start; seems to be the sanest option for that attribute.

[Antechinus]

Hey, this horizontal scrolling thingy works brilliantly with page numbers too. They tend to get messy when you have a lot of them on a phone. especially if someone has selected a font size larger than default. If you just let the thing scroll sideways it works well up to 200% of default font size (ie: maximum Firefox/Android font size).

On 2.1 all you have to do is cancel changing .pagelinks from flex to block, stop it wrapping, and give it some overflow and max-width settings. Bloody thing just works. If you expand a stack of pages by clicking the "..." span, no problem. They just appear in a neat line where you expect them to. You can even set your button styling to sane-for-touchscreen size, and it still just works.

Code Select Expand

#main_content_section .pagelinks {
    display: flex;
    flex-wrap: nowrap;
    max-width: 100%;
    overflow-x: auto;
    overflow-y: clip;
}
.pagelinks a, .pagelinks > span {
min-width: 44px;
text-align: center;
}


[Antechinus]

I had a possible idea for a more sophisticated version of this concept. It goes like this...

1/ Restrict the width of the anchors to just under 100% of the visible ul width.
2/ Allow the anchors to break to 2 lines (allows 50+ characters @200% font size on a 360px phone).
3/ Make the pointers after each anchor into another, separate, anchor that links to the next anchor in the list. IOW, make it work like the usual "next/previous" links you seem on common slideshows.

The idea here is that usually, with standard font size and "normal" lengths of text in the anchors, it would all sit on one line. In the event that you have an unusually long string of text (a very long thread title, for example) it would be allowed to break to a second line so the text wasn't truncated. If the title is really long you can choose to let it keep wrapping, or you have a couple of other options.

One is to restrict the maximum height to 2 lines, then truncate the text with an ellipsis. Yes, you can do this with multi-line text. It requires some non-standard CSS syntax, but it works in Firefox and Blink/Webkit.

Code Select Expand

display: -webkit-box;
-webkit-box-orient: vertical;
-webkit-line-clamp: 2;
You could also get fancier, with the whole thing showing upon click/tap, and that then linking to wherever you want to go, but that's probably getting too messy to feel right in practice.

But, I think the idea of using scroll-snap-type: x mandatory; on the parent ul, and having a "next" and "previous" pointer, with the ability to display at least 50 characters within the viewport width, even with a large font size on a smallish phone, could be workable and a good thing all round. It would still work with a basic swipe left/right on a phone, and it would work if you clicked/tapped the pointers. I think this could make it more versatile on both desktop and touchscreen.

Styling the pointers and the text spans so they look good with one line of text or two is not hard. It requires a bit of trickery but it's quite doable.

I'm gonna play around with this.