Display bug with aladin latest on mobile phone
Closed this issue · 12 comments
When opening this page on a mobile phone, the different widgets are not correctly displayed.
https://astro.unistra.fr/fr/2024/05/31/nouvelles-images-du-satellite-euclid/
The search bar goes off the screen.
This is due because the width of the div is too small for displaying all the ui elements and as aladin lite does not support media queries, I suggest you to remove some ui elements you do not want and also to move/resize manually the search bar. You can refer to the api documentation for that. For moving and changing the appearence of the search bar (e.g. resize) you can override the CSS class: aladin-location.
Ps: I will provide a css snippet that you can include in your project but probably you would need to do media queries to also keep the current behavior for big screen (desktop) users
@bmatthieu3 : we need to fix this. Aladin Lite UI should work fine on all devices.
@tboch I have a more balanced opinion on that and that is why I would like to open a discussion here for everyone.
I am not sure how good would it be to directly put media queries inside aladin lite because devices are always changing in there sizes and format. We still can reduce by default all the size of the ui but maybe some desktop / other device users will complain about how small it is (like it was on some ipad device before I increased the size by default). That is why for the moment there are documented css class names (see the link api doc) that user can override to adapt the ui elements as they wish. I think this is a good option for everyone.
I was not talking about media queries specifically.
Our mission is to deliver a working Aladin Lite UI on all devices out of the box. It's not easy but doable.
We are not going to ask each project to add a specific CSS.
I am emitting the media query idea as one solution to tackle the problem. Another one is changing the default behavior (default size etc...) but that will be done for every devices. If we change the default behaviour for all, then someone will be happy but another not (like that was the case for some ipad before I increased the text/icon size by default).
I was thinking of a solution like this one: https://jsbin.com/dajojimepo/edit?html,css,js,output
Set visibility priority on each item, and adjust visibility accordingly. This should work consistently across all devices.
Here would be a media query based pre-solution: https://jsbin.com/megijolezu/edit?html,output
With media queries there is no js which is something I like. A cons is that it is based on the size of the screen's device only and not the div's size (which I suppose is what we want ideally) like the javascript version you gave.
I am also quite concerned about completely hiding some item/ui/widgets elements because I see a conflict API case where the user disabled almost all ui (when instancing aladin lite) but want to only show one element determined 'less prioritized'. With that case and for small device, he would maybe never see it even if there would have been space to show that less prioritized element (essentially because it is the only element to show so why not showing it ?).
So maybe we would prefer reducing/simplifying some ui elements and move them instead of hiding them totally (i.e. find a way to plot all the elements for portrait iphones which is the a reasonably small device).
I am also quite concerned about completely hiding some item/ui/widgets elements because I see a conflict API case where the user disabled almost all ui (when instancing aladin lite) but want to only show one element determined 'less prioritized'. With that case and for small device, he would maybe never see it even if there would have been space to show that less prioritized element (essentially because it is the only element to show so why not showing it ?).
I don't think that would happen. If a UI item is disabled, it is not taken into account, as the corresponding DOM element is not instantiated. In my example, high priority are displayed first, and if space remains, lower priority will be displayed as well.
Ah yes I see indeed.
But how can we know if there is enough space if the user has the possibility to change the place of the elements (by overring their CSS classes). Here we would suppose the search bar is next to the frame and on the same line on the right there is the projection selector and the fullscreen button so we can tell if there is enough space by summing the width of that 4 elements and see if it is < width of the div. What if the user decide to put the projection selector on the bottom of the div ? => the space evaluator would not be the same because there is not 4 elements on the same line but only 3.
How about we put 3 "sticky" toolbars at the left, top and right of the view. And compute space availability for each of them?
Regarding media-query vs. javascript solutions: I don't have strong opinions, given that Aladin Lite needs JS to run. But indeed, it would be more accurate to base our solution on AL div size rather than on the screen size.
I do not see how it may solve the issue, maybe I misunderstood something.
I was referring about the fact that a user can decide to put the search bar on the middle of the aladin lite div if he wants to (by overriding the aladin-location class) and therefore that element does not belong anymore to any toolbar. That could lead to very strange behaviors that I do not accept where elements could hide without any particular reasons. I mean we cannot know where the user will put the ui elements.
And I think there are some users that do that of overriding the css classes to change the default position of the elements... I am concerned about them if we do some new default logic (independantly of whether it is js or media-query based solutions) that hide elements.
Edit: I think they still could add a display: block which would then override the media-query and make them always visible as expected. This is an argument for using media-query: user css can override css from media-query but the user css cannot override the css set by JS isn't it ? But for them that sure will be a breaking change :(
I will close that issue because in the new beta version some basic media queries do have been implemented. Do not hesitate to reopen it if that attempt is not satisfying.