| • Pablo-WMDE | |
| May 22 2018, 2:35 PM |
| F22479005: Bildschirmfoto von 2018-06-22 10-05-53.png | |
| Jun 22 2018, 8:12 AM |
| F22479007: Bildschirmfoto von 2018-06-22 10-09-07.png | |
| Jun 22 2018, 8:12 AM |
| F22479006: Bildschirmfoto von 2018-06-22 10-09-19.png | |
| Jun 22 2018, 8:12 AM |
| F22410292: Screenshot_20180620_170548.png | |
| Jun 20 2018, 3:08 PM |
| F22372892: can-remove-representation.png | |
| Jun 19 2018, 12:22 PM |
| F18473220: Bildschirmfoto vom 2018-05-22 16-32-44.png | |
| May 22 2018, 2:35 PM |
Adding many form representations, the individual representation widgets - rendered next to each other - overlap the form representation toolbar buttons (depending on screen width). The overlapped widgets' remove buttons are not usable.
This may or may not be a problem in CI, too, where the resolution seems to be at 800x600.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Representation widget: prevent bleed into buttons | mediawiki/extensions/WikibaseLexeme | master | +1 -0 |
This looks meh but my assumption is that people won't encounter this often because most Lexemes have one or two Lemmas.
Change 441034 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/WikibaseLexeme@master] Representation widget: prevent bleed into buttons
Change 441034 merged by Pablo Grass (WMDE):
[mediawiki/extensions/WikibaseLexeme@master] Representation widget: prevent bleed into buttons
Yay :)
One remaining issue: For me the "Lemma" in the second row still overlaps the input box of the first row. Is there anything we can do about that?
@Lydia_Pintscher This is a really interesting behavior because these boxes are configured to (and that's how it also works for me) float around each other - I have trouble to imaging a way how they could bleed into each other; same goes for the input fields/labels overlapping the (blue) border. Where did you observe this? *looking at that centralnotice banner* Which browser did you use, can you solve it be clearing the cache? Thanks
We looked at it together in person. Result: on beta, in Chromium. Reload didn't change anything.
This is mildly disturbing but interesting.
Lexeme header editing happens all within the page's h1 (T196228), hence a serif font is used (font-family: 'Linux Libertine','Georgia','Times',serif;) - depending on which one is actually installed this could yield different values for font-related dimension (em, ...). I'll look into that a bit.
@Lydia_Pintscher Does the same thing happen in production already? Becuase, if so, it's - strictly speaking - not part of this ticket.
Seem to be able to produce a similar effect by changing the base font size of the browser.
As this happens both on beta and production I do not consider this part of this ticket (also this ticket here is about form representations, not lexeme lemmas) - should go into a dedicated ticket => T197929