(arguably) improved layouting of user profile page #403
No reviewers
Labels
No labels
a11y
Bug
Bug fix
Critical Priority
Documentation
Feature
Feature request
Held for next release cycle
High Priority
Low Priority
Medium Priority
Minor change
Translation/Locale
WIP
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma-fe#403
Loading…
Reference in a new issue
No description provided.
Delete branch "Riedler/akkoma-fe:user-profile-changes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Note that right-aligning the bio would make akkoma fall in line with most other fedi software (besides pleroma ofc), so formatting would transfer correctly. This will also probably make a lot of people unhappy so if you want me to make this an optional feature, I can 100% do that 😅
part of changes in DNS#1
i personally prefer centre alignment for the bio, so a toggle would be welcome ^^
Unrelated to an alignment toggle:
The commit message says it makes it left aligned but the actual change sets
text-align: startwhich afaik means it willbe aligned according to the base direction. Currently akkoma-fe does indeed always assume LTR though i have an unfinished branch to make user-generated content follow Unicode BiDi autodetection.Am i understanding correctly this will indeed follow base-direction after this change or is there something else in here enforcing left alignment i missed?
I must admit i like personally like stats (post, follow(ers|ing)) on their own line like before more but i guess i could get used to it if the new design is generally preferred by most and (at least for me) not worth the complexity of making this toggleable.
Apart from personal preference though it creates some issues in narrow/mobile layouts. “Posts per day” no gets squished int the user handle and “Followers” can slip beneath the “edit profile” button in localisations with a sufficiently long text.
I can make both toggleable - I've changed the underlaying layouting to be more malleable if needed, so this shouldn't really introduce much code complexity. Same for mobile layouts - I can simply move the stats down if mobile is detected.
as for text direction - uhhh… no idea, honestly. I have zero experience with rtl languages. I'll go test what it does with rtl stuff 🤷 we'll see.
there was an old PF for RtL but consider is "unsupported" for now and you'll be fine
i quite like the right-alignment so i'll probably use that personally
As long as you didn't hard-code directions anywhere things should be fine;
startshould adapt to the base direction.Digressing a bit for more details on the bidi situation:
Currently akkoma-fe always defaults to LTR base direction; i’m not sure why everyt documentation i found indicates “auto” ought to be the default for HTML5, but unless told otherwise it always ends up as LTR. In result LTR or mixed-content posts display subtly to utterly garbled in akkoma-fe.
Here’s a commit which explicitly marks all user-generated content to follow Unicode BiDi “auto” and prevent bidi user content from messing up non-user-generated adjacent elements: https://akkoma.dev/Oneric/akkoma-fe/commits/branch/bidi
Functionality is mostly complete, but it stalled because i wasn’t sure what to do with hashtags or advanced MFM and because using
<bidi>HTML elements instead of the CSSunicode-bidi: isolateproperty would be cleaner. (And i still don’t know why it even needs explicit opt-in into Unicode BiDi)The other even older bidi PR #258 also adjusted the whole layout to flip in RTL mode, but that’s way more work and not needed to display posts, bios, names, etc correctly
everything is optional and toggleable now. Here's the on/off states ↓
I hope I didn't miss any layouting oddities.
Did you intentionally omit this? I can still produce overlaps of the handle with the “post per day” counter and sometimes even the other users stats in mobile layout; try viewing e.g. remote profiles from a longish domain.
The way other elements detect mobile layout is via
.app-layout.-mobile #selector-for-element-to-adaptnope, I simply forgot 💀
I originally wanted to wait with that part until I figure out how mobile detection works in akkoma, but then, but then… I just didn't. idunno 🤷 happens ig
I'll look into that after the mobile thing - shouldn't be possible, so I must've overlooked something…
hmm well I'd prefer something detectable with js, so things can rely on the
.-compactclass always representing the actual state of the layout. I'll try to find out what sets the.-mobileclass and try to read from that if possible.both should be fixed now
I’m not sure about hiding the setting completely in "mobile" narrow-width layout since it means opening enough windows alongside your browser prevents changing the setting even if normally the browser is wide enough to not use the "mobile" layout. Maybe it’s better to adjust the setting text to clarify it only works if there’s enough horizontal space
Otherwise everything seems to work fine now at least in my testing, thanks!
…good point
2e83ccefdcand clarified that compact user info is only used with enough roomView command line instructions
Checkout
From your project repository, check out a new branch and test the changes.