UI Consistency across browsers

[joelbrock]

Table cells size differently btwn Chrome/Safari and FF browsers.

Here is what it looks like in FF, and what i imagine it ought to look like:

This is what it looks like in Chrome (also very similar in Safari):

[gohanman]

This is honestly the most tempted I've ever been to tag an issue "won't fix". The page doesn't specify how wide any of the columns are supposed to be*. That's intentional. The entire point of using a fluid layout/design is to let the browser engine decide how best to render the page at various screen sizes. This is going to happen over and over again. Adding a bunch of explicit sizing everywhere Chrome decides to do something dumb is time consuming and makes pages objectively worse in terms of handling variable screen size.

• The price column actually has a size specified. Chrome is apparently just ignoring that for the sake of being extra annoying.

[gohanman]

Even with the input size forced narrowing, Chrome still manages to make ridiculous column size decisions...

[gohanman]

This works for the particular case called out: 1a1840d

I still don't know how much time I want to sink into this. Member Types and Tenders have similar problems where Firefox picks sane column widths for the content and Chrome does not.

[joelbrock]

.table {
table-layout: fixed;
}

Not a real fix, as it clobbers the field sizes that are defined, but this improves things in Chrome anyway,

I'm also fine telling users that for the "optimal" Fannie experience they need to use the FireFox web browser. But i dont love that.

[gohanman]

I actually tried using table-layout fixed. It makes Chrome substantially worse in my testing. If the content doesn't fit the text just spills out into the next column. So, for example, a long item description runs over the right table cell edge and over the top of the size column.

That actually makes sense at least. That directive tells the browser not to pay attention to content when sizing cells. It's expected that content won't fit well in that case.

[gohanman]

It dawned on me there's a pattern here. Chrome's odd behavior seems to be largely with the input groups where a $ or % is attached to the text box. I adjusted Tenders and Member Type (c9761ca) and updated the Bootstrap documentation with information about the specific issue.
https://github.com/CORE-POS/IS4C/wiki/Tips-for-Bootstrap#browser-specific-issues