Sotera/DatawakeDepot

Depot: Need to address colspan fix that was reverted for previous QPR

bmcdougald opened this issue · 1 comments

The search filter needs to be fixed to span consistently on the following pages (at least):
Extractors
Users
Teams
Domains

Instead of setting colspan=80 to ensure it is always as wide as our tables, perhaps the simpler solution is to simply set them to something like colspan=3 on all pages, as that is plenty of room for a user to type a search term in.

There are only a couple options it seems to address this, each has pros and cons.

  1. set colspan for appropriate column count of table - Pros: accurate to what's displayed; Cons: hardcoding this value leaves us open to this problem reoccurring when more columns are added or deleted in the future forcing us to adjust the colspan value.
  2. set colspan="100%" - Pros: technically this isn't a percentage but accomplishes the same as setting colspan to 100 columns. % just reminds you what you are trying to accomplish here. This works in all modern browsers reportedly, but is a hack and fails if column count exceeds 100 (not a problem for us), would not be affected by column additions or deletions in the future; Cons: On some of the tables there is a refresh button also occupying the table header with a colspan of 1 itself. With 100 + 1 colspan, the refresh button forms an extra column the table doesn't require. This looks awkward as well and shouldn't be used where the refresh button is also in the th, but could be avoided if the button was moved elsewhere.
  3. set colspan for "adequate space" with a value of perhaps 2 or 3 - Pros: Gives plenty of room for text searches to be typed, would not be affected by column additions or deletions in the future.; Cons: It still doesn't have a consistent look since the table columns are all different sizes, even though you'd span 3 columns...those 3 columns may constitute different overall widths from page to page.

The solution I chose, for now was option 1. To simply set the colspan appropriately on each page to reflect the table being generated. This solves the problem of consistent appearance for now, but leaves us open to fixing this piece-meal again in the future if the table changes again.