Pagination styles for mobile version #94704
No reviewers
Labels
No Label
legacy project
Infrastructure: Blender Web Assets
legacy project
Infrastructure: Websites
Priority
High
Priority
Low
Priority
Normal
Status
Archived
Status
Resolved
Type
Design
Type
Report
Type
To Do
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: infrastructure/web-assets#94704
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "Francesco-Bellini/web-assets:fix-mobile-pagination"
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?
Edit
Please, checkout the update comment.
Hi again :)
Today i'm fighting for the mobile pagination rights.
While the pagination looks fine for desktop
seems like mobile is not so lucky...
cutting buttons on the left side, and overflowing to the right, causing the whole page to enlarge.
Proposal
All those buttons are simply too many for a mobile screen.
My proposal is (for mobile only) to split the
First
,Prev
,Next
,Last
buttons in a separate line (while of course, hiding the desktop ones).I'm realizing that hiding from web-assets the desktop pagination buttons, also affect other websites which use web-assets (if they use this same .pagination class).
While each website can point a different version, this can lead to future problems.
I'm not exactly sure which other websites uses this pagination style, but they should implement the same updates as the PR i made on extensions-website, to work properly after updating web-assets. I could try to extend the HTML implementation on those, if you could point me in the right repos that would need that. As long as the solution looks good to you, of course.
Edit:
Looking the websites using v2, i only found (note: quick and unlogged look):
For example, adding a unique class there, at the .pagination level, and use that here, with :not(), while hiding on mobile, could be one solution to exclude studio.blender.org custom pagination.
Or the opposite, adding the class in extensions-website and using it to hide the buttons here (instead of children of .pagination), which probably makes more sense and is more easy to maintain, enabling the mobile styling only where needed.
Thank you Francesco! I've assigned Márton to have a look at it.
Hi @Francesco-Bellini , Thank you for your proposal again! Addressing this issue is indeed useful, and the suggestions look good to me in general. I'll add some generic comments here, and some minor, specific change requests below to align better with the system.
order
CSS property per query etc.) let us know, otherwise looks ok as is.Thank you!
Hi @martonlente!
Sure! I didn't noticed that this repo had a reference page with examples. I will add it for sure!
This evening i'll be back on my linux system, and will work on that.
Also i will dig further... Maybe i will be able to do something requiring no (or less) html changes on the website side.
In case i couldn't find another solution, what do you think about the last part of my comment?
Do you agree it would be better to add a unique class, along with .pagination, in the extensions-website, so here, when i hide the desktop button, i can use that, instead of .pagination, so that studio.blender.org (and eventual other i missed) are not affected, if not explicitly implemented for it?
@ -1,4 +1,4 @@
.pagination
.pagination, .pagination-m
Web Assets styles are mobile-first by default. As such, it'd make sense to make mobile / small screen styling kick in by default, and adding additional styles for larger screens instead.
Here it's acceptable like this too. I suggest changing
pagination-m
topagination-xs
to reflect the project's naming scheme.Removed the
.pagination-m
class at all.@ -15,2 +15,4 @@
+padding(0, x)
.pagination
@media (max-width: 767px)
We shouldn't use explicit px values in media queries, but instead use media mixins bundled with the project. I think
+media-xs
would qualify here.@ -17,0 +21,4 @@
.pagination-m
display: none
+padding(1, y)
I'd suggest matching this with the existing
pagination
's vertical spacing setting to+padding(2, y)
, so that no utility classes are needed in projects when we implement this, if we want to keep the existing spacings.Or actually
+padding(2, bottom)
would be cleaner, aspagination
comes beforepagination-m
in the markup with bottom spacings already applied.See the new comment for details, because changing overall strategy, there was new requirements.
Thanks for looking out for this. Since the
v2
branch is in alpha yet, I think it's ok to come up with a solution for this that we find the best, even if it needs some (moderate) adjustments on the projects' level.4f8bb162ad
todbe6a20cee
I'm glad you asked me to try to find another solution, @martonlente, cause i did, and it's good to know!
I found a solution requiring no changes in the website side.
And updated the reference page as requested.
Updates
Changed the media query to
+media-xs
Removed the
pagination-m
classAdd
flex-wrap: wrap
to.pagination
Moved 1 unit of padding top from the
.pagination
to 1 unit of margin top in the.page-link
For wrapping reasons. No visible changes.
Used order, as suggested to reorder to end special buttons on small screens (while preserving relative order)
For small screen, used a
.pagination::before
in order to force a line between pages and special buttons (using order)This is because heavy paginations can have pages wrapping, and they must not mix with the line of the special buttons.
Created optional class
.pagination-inline
, which can be used dinamically on website side (based on context;number of total buttons), in order to force inline mode for small screens too.As mentioned in the last pagination example in the reference page.
I tought it was nice to have as a possibility, but if you don't see a use for it, i can remove it.
I'm guessing the pagination on studio.blender.org i've seen, could benefit by using a static
pagination-inline
class, since it has no pages, so has a short row, but should be tested to make sure.Updated reference page, adding 2 examples (see images next):
pagination-inline
Also in the reference page i added the
left
class to the first example, because the text was saing so, but the class wasn't there.I removed the box around pagination examples (as tables), in order to get the tipical width on small screens (like extensions-website) without having the extra padding from the box.
I tested both from local extensions-website as from reference-page.
Here the reference page with normal and small screens:
P.s. I was wrong about the worst possibile case. This heavy example is the actual worst possible case (at least, for extensions-website)... (being in a far central page in a ~15+ pages situation, which gives 2 "..." and 5 pages on each side of the active one, for a total of 17 buttons on the screen)
For any changes, let me know!
If you agree on the solution, i will close infrastructure/extensions-website#255, as this task doesn't need HTML changes anymore, and given the number of extensions in production, extensions-website seems like will never need to use
pagination-inline
optional implementation.P.s. I amended previous commit and rebased, but i've got a backup branch of the initial PR.
dbe6a20cee
to20ca35103c
20ca35103c
to0f1386a086
0f1386a086
to75258cfe2c
75258cfe2c
to4ec83f199e
@Francesco-Bellini thank you for the changes and the thorough description, they look very good! I also appreciate you managed the changes in a way that they don't require markup changes – that's nice!
Before merging, just let me add some minor change requests or comments below.
I think later we might want to simplify this, as these many buttons indeed seem to be a bit too much from a UX perspective. Though a similar component is currently used in Extensions, so I think it's good to have this polished example in Web Assets for now.
I'm not sure about the use case, but the naming and styles are nice and clean: I'm okay with this.
@ -1302,3 +1301,3 @@
</p>
<ul class="pagination">
<ul class="pagination left">
I suggest not to change the default aligment on the reference page.
Not related to the PR, but I'd prefer BEM-like naming, like
.pagination-left
instead of a generic nested.left
for the class selector.I changed this (unrelated example) only because it's description was saying:
Left aligned pagination example
But there wasn't no
left
class. So the example wasn't aligned as the description was saying.And using the class
left
is what the next example suggest.I can undo this, if i'm missing something here. I just tought it was forgotten...
Thank you for your attention to detail. I'd personally recommend undoing this, to keep the PR focused and the pagination example section more relaxed. If we really want to address this, I think it'd be better to change not the markup but the text by removing the
Left aligned pagination example.part, that isn't very useful here.The reference page is a work in progress, and maybe it's better to do another 'cleanup and improvement' pass on its layout and text in another pass.
Fear :)
I'll undo this.
@ -17,0 +22,4 @@
order: 2
.pagination:not(.pagination-inline)::before
order: 1
I'd prefer not to use the
:not
selector if possible, to make the base pagination styles work also if we remove the extra.pagination-inline
later, just in case.:not() here, is only making sure that when using
pagination-inline
class, this style does not kick in.Basically the class
pagination-inline
doesn't add nothing new.It just remove this styling when used (on purpose).
I made an example of using this class, in a new comment. Let me know :D
I see how you're thinking, and indeed it's correct and works well. But in a BEM-like convention that we try to apply in the framework it would rather look like this:
Even if it results in more code, it's cleaner to start with the base selector styles, and add extra styles for the extra modifiers / variants, that can be easily removed without touching the base selectors and styles, just in case. I hope this explains what I mean here, and suggest to use this instead. It also has a performance benefit (that's mostly theoretical in this case, of course).
I never say no to the "mostly theoretical" performance benefits!
And i'm not quite familiar with this BEM-like convention you're referring, but i'll check it out to better understand the basic concepts.
Thanks for the snippet! I'm going to update the PR this way 👍
@ -18,3 +30,4 @@
color: var(--color-text-secondary)
font-size: var(--fs-sm)
line-height: var(--lh-base)
order: 0
Are you sure this
order
rule is needed? Theorder
should default to0
, if not defined.Yes, I think you're right... I'll test it and eventually remove it.
I've add it on principle, to be honest, so i didn't tried without it.
I tested this and it's safe to remove
order: 0
, as elements are rendered like this by default.Thanks for checking this out!
Happy to remove it, then!
Yes, i agree it would be better to reduce the number of max buttons, by design on extensions-website... Because only the pages can raise up to 13 buttons...
For the
pagination-inline
class, here's a use-case:This is what would happend to the studio.blender.org/blog pagination, if we do nothing (after this PR):
I quickly replicated from devtools...
But as you can see here, the studio.blender.org/blog pagination, has no pages...
So, on first and last page, it's perfectly fine without wrapping the buttons, also on small screen.
My idea behind
pagination-inline
was simple:If the pagination is short enought, we can keep it inline.
For example, in studio.blender.org, we could check if the page is
1
or thelast
, and in that case, add the classpagination-inline
.Because those are the only 2 cases having exeeding space (because first and last pages only has 2 buttons).
While other cases like this:
would require to have a separate row.
Of course, if you are fine having the media query always kicking in, regardless the number of buttons, i can remove it.
I'm convinced, let's keep the new
pagination-inline
styles! 👍Thank you for all your work on this, I think we're almost there!
4ec83f199e
to85cc564669
There we go!
left
class in reference page:not(...)
as suggestedinfrastructure/extensions-website#255 closed.
@Francesco-Bellini your PR was merged to
main
, and will get deployed to projects with the next release.Thank you for the nice fixes! 👍
Thanks for the help @Francesco-Bellini ! Mobile rights need lots of love in Blender projects, it's always a struggle.
And thanks Márton for reviewing!
Thank you guys (@martonlente @pablovazquez)!
I enjoy working with you, and i have deep admiration for the Blender project as a whole. To me, it's #1 FOSS project out there.
That's why i'm very happy to help wherever i can.
Hope i'll meet you guys at the bcon!