Closed shaunanoordin closed 2 years ago
Tagging @eatyourgreens and @mcbouslog , in case either of you can think of a quick solution for this. If not, I'll dive into this Monday. 👌
(I just spent 15 minutes bumbling around with the grid layout CSS and have only succeeded in breaking both page zoom and responsive layouts. 👀 )
The project Classify page seems ok, but I'd have to double check on an iPad. I'm looking at Davy Notebooks.
The dev classifier isn't used by volunteers so it isn't such a big deal if that's broken.
I think I see what you're referring to, if I use the Chrome Device Toolbar (needs confirmation with BrowserStack or actual device) and set it to iPad Mini the viewer width exceeds the view width:
We can set the minimum size of the left hand track to a size that’s more appropriate to a small viewport. At the moment, it’s adjusted for ~1200px.
At the moment, the minimum track size is 45.333rem
so I’d start by experimenting with smaller values. Max size is auto
, which should expand the track to fill available space.
I think the following changes works well, but there are prob a bunch of different ways to approach this:
@media (min-width: 801px) {
grid-template-columns: minmax(${subjectSize}, auto) minmax(1fr, ${taskSize});
}
@media screen and (max-width: 800px) {
If the subjectSize is 45.333rem
, which with 16px base font size equals ~725px, I think it makes sense to break on a width larger than 700px?
I don’t think 1fr
means anything on its own. What minimum size is it setting the task area to there? Is that code the same as minmax(auto, ${taskSize})
?
I’m trying to visualise a layout where the subject width is 725px, leaving 75px for the task, but that seems like the task wouldn’t be usable.
If the subjectSize is 45.333rem, which with 16px base font size equals ~725px, I think it makes sense to break on a width larger than 700px?
I could be wrong but I think the breakpoint should be the sum of the smallest subject and task width: 70.667rem
. We can adjust for smaller subjects, though.
My suggestions, and @mcbouslog's in https://github.com/zooniverse/front-end-monorepo/issues/3410#issuecomment-1178253756, both regress #3336. The subject shrinks to fill the available space as the task area grows, when the page is zoomed in.
https://user-images.githubusercontent.com/59547/177952638-0fa724e3-1577-4166-973e-7abcf8bc851d.mov
Remember that page zoom changes the effective viewport width, so a 1200px window, zoomed to 150%, will have a CSS viewport width of 800px.
This gives better results, but the task area can be quite squashed at small screen widths, or when zoomed in to ~130%. Min subject width of 45.333rem
, max task width of 25.333rem
and a breakpoint at 800px.
const subjectSize = 'minmax(45.333rem, auto)'
const taskSize = 'minmax(auto, 25.333rem)'
const ContainerGrid = styled.div`
display: grid;
grid-gap: 30px;
grid-template-areas: "viewer task";
position: relative;
@media (min-width: 801px) {
grid-template-columns: ${subjectSize} ${taskSize};
}
@media screen and (max-width: 800px) {
grid-template-columns: 100%;
grid-template-rows: auto auto;
grid-auto-flow: column;
grid-gap: 20px;
grid-template-areas: "viewer" "task";
}
`
UI Issue
Package:
lib-classifier
Follows: #3337 Noted on commit 9fedf9157926adfc3f599598f2124595718486bf (not deployed to production yet) with macOS + Chrome 103 / FF 102The Classifier is no longer responsive on "medium" viewport widths.
Expected: Task Area should always be visible in viewport, for medium widths. Subject image should shrink accordingly
Actual: Task Area is cut off at medium widths. Subject image does not shrink.
Steps to Reproduce
lib-classifier
Dev Notes
I've stepped into the TARDIS to figure out when this bug was introduced, and can confirm that this is a result of the changes to Classifier's DefaultLayout in #3337.
Status
Major UI issue, I think, but we have some time to take care of it.
This UI issue was noticed while I was giving @seanmiller26 a demo on QuickTalk on my localhost. As of 7 Jul 18:58 BST, this isn't out in the wild yet, so isn't an urgent problem yet, but should be fixed before the next deploy.