0050926: [UX] Wrong "Configurable Layout" definition in several UI components which leads to content overflows the viewport in some cases

Anonymous | Login

Project:

News | My View | View Issues | Roadmap | Summary

View Revisions: Issue #50926		[ All Revisions ] [ Back to Issue ]
Summary	0050926: [UX] Wrong "Configurable Layout" definition in several UI components which leads to content overflows the viewport in some cases

Revision	2022-11-16 22:30 by dbaz
Description	Most of the UI components have a 'exotic' "Configurable Layout" definition. For example, the main layout. It has 4 components: * ButtonBar 1: its height should be dynamic based on its content * Ticket Lines: it should fullfill the remaining space * ButtonBar 2: its height is based on the height defined explicitly inside its component * obpos2MainPOSApp-content: its height is the full second (right) column Currently it is defined as a 12 row layout, with 1fr of height for each row, and then with rowspan the content is adjusted. In this particular example * ButtonBar 1: 1fr * Ticket Lines: 10 x 1fr (rowspan 10) * ButtonBar 2: 1fr On the one hand, there are elements (buttonbar 1 and 2) pushing beyond their assigned 1fr (or Xfr if there is rowspan) height, that cause problems which are difficult to prevent: https://stackoverflow.com/questions/52785750/prevent-grid-area-from-expanding-causing-whole-page-to-scroll [^] On the other hand, there is a second problem. If the relative height of the viewport is increased, if the height of the component is less than its asigned row span it generate an undesired behavior. For example: Current viewport relative height is 768px. That means that the available height for the main layout is 680px (substacting the 56px of the top status bar and the 32px of top/bottom margins). This entails that 1fr will be (if there are not elements pushing) 68px each one. The height of ButtonBar 2 is 112px, so we are fine. It enters in its assigned 1fr, and also will be pushing the other rows upwards. Now, if we increase this relative height to 1288px, the height for the main layout will be 1200px, so each 1fr of the 12 defined will be 120px. Since the height of ButtonBar 2 is 112px, there will be a 8px gap between the end of the receipt (the total and tax section) and this ButtonBar 2 Both problems lead to a structure of chained configurable layout that is difficult to maintain. Configurable layout should be revisited, and use only the needed number of rows on each case, and also, set the template-row property to "auto" in those rows where this is the expected behavior, and use 1fr for the row where there remaining space needs to be fulfilled. Another related point is that the current keymap implementation has elements that are outside the boundaries of the own keymap (buttons to move to next/previous page using carousel). This leads also to make the content overflows the viewport, depending on the margins surrounding the keymap itself. These component should be moved inside the boundaries of the keymap, to avoid this potential problem. Both problems ('exotic' Configurable Layouts configuration and components of the keymap outside its boundaries) should be fixed together, because fixing only problem make worst the other one, and the other way around.

Revision	2022-11-16 22:21 by dbaz
Description	Most of the UI components have a 'strange' "Configurable Layout" definition. For example, the main layout. It has 4 components: * ButtonBar 1: its height should be dynamic based on its content * Ticket Lines: it should fullfill the remaining space * ButtonBar 2: its height is based on the height defined explicitly inside its component * obpos2MainPOSApp-content: its height is the full second (right) column Currently it is defined as a 12 row layout, with 1fr of height for each row, and then with rowspan the content is adjusted. In this particular example * ButtonBar 1: 1fr * Ticket Lines: 10 x 1fr (rowspan 10) * ButtonBar 2: 1fr On the one hand, there are elements (buttonbar 1 and 2) pushing beyond their assigned 1fr (or Xfr if there is rowspan) height, that cause problems which are difficult to prevent: https://stackoverflow.com/questions/52785750/prevent-grid-area-from-expanding-causing-whole-page-to-scroll [^] On the other hand, there is a second problem. If the relative height of the viewport is increased, if the height of the component is less than its asigned row span it generate an undesired behavior. For example: Current viewport relative height is 768px. That means that the available height for the main layout is 680px (substacting the 56px of the top status bar and the 32px of top/bottom margins). This entails that 1fr will be (if there are not elements pushing) 68px each one. The height of ButtonBar 2 is 112px, so we are fine. It enters in its assigned 1fr, and also will be pushing the other rows upwards. Now, if we increase this relative height to 1288px, the height for the main layout will be 1200px, so each 1fr of the 12 defined will be 120px. Since the height of ButtonBar 2 is 112px, there will be a 8px gap between the end of the receipt (the total and tax section) and this ButtonBar 2 Both problems lead to a structure of chained configurable layout that is difficult to maintain. Configurable layout should be revisited, and use only the needed number of rows on each case, and also, set the template-row property to "auto" in those rows where this is the expected behavior, and use 1fr for the row where there remaining space needs to be fulfilled.