makes the default width for FF columns wider

[dahlbyk]

To clarify, for performance reasons these columns have to be fixed width? We couldn't let them flex between min-width: $task-column-width and max-width: $milestone-column-width, for example?

[rauhryan]

To clarify, for performance reasons these columns have to be fixed width? We couldn't let them flex between min-width: $task-column-width and max-width: $milestone-column-width, for example?

I'm pretty sure max-width is redundant here.

The columns don't stretch past min-width at all

[dahlbyk]

I'm intrigued... it looks like width settings on .column are overriding the moz-specific settings on .task-column, i.e. the min-width you're setting here isn't actually respected.

I almost wonder if it would be worth generating some columns-N classes (for N = 2 through 10 or something) with width: (99 / N) (or, even better, add .columns-N to the div.board rather than each column) so that Firefox can use pretty-good widths by default, constrained by min-width and max-width?

[rauhryan]

To clarify, for performance reasons these columns have to be fixed width? We couldn't let them flex between min-width: $task-column-width and max-width: $milestone-column-width, for example? I'm pretty sure max-width is redundant here.

The columns don't stretch past min-width at all

Actually... If we don't make min-width and max-width the same, the columns will be different widths based on the largest card in the column

[dahlbyk]

Actually... If we don't make min-width and max-width the same, the columns will be different widths based on the largest card in the column

But not if you also specify width, I believe?

[rauhryan]

I'm intrigued... it looks like width settings on .column are overriding the moz-specific settings on .task-column, i.e. the min-width you're setting here isn't actually respected.

I almost wonder if it would be worth generating some columns-N classes (for N = 2 through 10 or something) with width: (99 / N) (or, even better, add .columns-N to the div.board rather than each column) so that Firefox can use pretty-good widths by default, constrained by min-width and max-width?

Could be interesting to take a look at.

Maybe...

columns-2 == width:50% columns-3 == width:33.333% columns-4 == width:25% columns-5 == width:20% ... columns-zomg-so-many == width: 280px

something like that. Once it get's over a certain number of columns, we just throw the hands up

[dahlbyk]

That's the idea. I don't think we want exactly 100/N, though - it was giving me a scroll bar.

columns-zomg-so-many == width: 280px

Would want to use min-width rather than max-width, but yes. And actually, as long as width == min-width is specified in the moz-specific selector, the generated selectors should have higher specificity - no need to add a special case for numbers larger than we support, the class would just do nothing.

[dahlbyk]

Reminder that we have https://huboard-rails-pr-380.herokuapp.com/huboard-testing/task-cols-2 through https://huboard-rails-pr-380.herokuapp.com/huboard-testing/task-cols-9 available for testing various column counts.

I'm seeing horizontal scroll bars on task-cols-6 and up:

[rauhryan]

whomp...

[discorick]

The "super squish" factor actually looks pretty good, maybe just have an overflow handling on the repo name?

[rauhryan]

The "super squish" factor actually looks pretty good, maybe just have an overflow handling on the repo name?

:shipit: & create an issue

I tried to mess with a max-width on it yesterday for a few hours and couldn't get it to truncate the text, so I'll need more time on it.

Don't think it's blocking

[discorick]

:shipit: & create an issue

Issue created ☝️