BGDIINF_SB-2748: Add selection feedback in topics.#397
Conversation
a9bacb6 to
38eaf94
Compare
ltshb
left a comment
There was a problem hiding this comment.
As discussed it doesn't work now
38eaf94 to
6be725f
Compare
6be725f to
00fe212
Compare
|
buttons looks squashed, the padding on top/bottom could be increased or reduce the padding/margin on left/right to have kind of square button that don't look squashed. |
|
@ltshb This is because the width is adaptive (i.e. margins between the buttons are of fixed size and the width of buttons and number of columns adapt to fill the available space. On the two screenshots you see the two extremes (largest button width just before a new row is created and smallest button width just after a new row is created). If you prefer I could make the button width fixed and instead have the margin that is adaptive. But as you can see on screenshot for "Informations foncières", having a variable button width has the advantage that long titles can still fit on only one line if there is enough space. Fixing the button width would force these titles to always be on multiple lines, wich I don't really like. So I would prefer is leave to button width adaptive and maybe just increase a tiny bit the top and bottom paddings. What do you think? |
|
I see your point about having the title on line. Looking at the old viewer it seems that the width is fixed but large enough to have all title on one line. In your current version depending on the screen width you might have very wide button which looks very ugly and a lots of white spaces. |
|
Another idea would be to use the outline buttons to have less big fat red buttons. |
|
I don't really like like the outline button as when you hover over it, it changes its color, and thats confusing, as its already selected. So for now I kept the primary-button.
|
|
Some words don't break correctly. However this was already the case before. I think that this could be fixed by changing the translation (e.g. in the example above to "Grundstück­information"), so that the browser knows how to correctly split the word into two lines.) However, the translations are also used by the old viewer, so I'm not sure if I can do that safely. |
35eaff8 to
0f3fdff
Compare
- Modal takes 100% width on mobile (also impacts other dialogs) - Topic buttons can have a smaller width on mobile - Topic buttons have a max height to improve appearance.
0f3fdff to
8c2d1d8
Compare
src/utils/ModalWithBackdrop.vue
Outdated
| // For phone we set the width and height fixed to 100% of the view. | ||
| // dvh takes into account the user interface in mobile browsers (with vh part of the modal is | ||
| // not visible if ui is shown). Is recognized by browsers from 2022 or newer. If the browser | ||
| // is older, 90vh will normally be used, which is a bit less clean but good enough. |
There was a problem hiding this comment.
Although this is a good idea for the topic use case where the window take anyway the whole screen, this doesn't fit well with all use cases. For the Delete and Share use case of the drawing the modal is smaller and it doesn't make sense to have it as a banner in the middle.
So I would either left it as before or only make it fullscreen when it make sense. When making it fullscreen the rounded corner needs to be removed though.
- Modal is centered with Flexbox instead of using top left 50% and transform translate. This fixes the automatic width sizing for when fluid property is activated, as before it would only ever take 50% of the screen (or min-width). - When not fluid, the modal is of fixed size (compared to before were only a min-width was defined) - When not fluid, we only define max widths and max heights. - Border radius is removed on non-fluid modals in phone mode, because in this case the width is always 100vw.
74d3f49 to
07845cf
Compare
Test link