Feature table cell stretched

[vmcj]

This is a partial fix for: #1273, this solution seems to work in firefox but does not work in Edge (chromium based).

Given that most major contest do install firefox I think merging this is still acceptable.

I've now kept the border to show which element is stretched but that will be removed when merging.

I've now implemented a solution with 2 browserhacks. In the end we can set 1 and override the shared properties in the browserhack after it. The browserhack for firefox looks depricated but according to https://sass-lang.com/documentation/breaking-changes/moz-document/ this specific behaviour is kept (so reasonable safe to use).

[thijskh]

It does not seem to work for me, in my FF 99 on MacOS I still see the gaps between the cells:

[vmcj]

@thijskh can you take a look again?

I've now done 2 browser hacks to make it easier to change something between either a gecko engine (firefox only at this point?) and something chromium based (Chrome, Edge, Safari & Opera(?)).

If this does work for you I can see if I can deduplicate and fix the margin/padding etc. but I prefer to first be sure that this fixes the original issue.

[thijskh]

It's not beautiful but seems to do the trick.

I don't understand the comments about diffs.

[vmcj]

It's not beautiful but seems to do the trick.

Ok, than I'll deduplicate the shared parts and squash everything to one commit.

I don't understand the comments about diffs.

They were placeholders to make sure that the differences between commits would point at the right parts instead of git showing differences between unrelated parts.
If there was a better way to steer the algorithm I would like to learn that.

[nickygerritsen]

They were placeholders to make sure that the differences between commits would point at the right parts instead of git showing differences between unrelated parts. If there was a better way to steer the algorithm I would like to learn that.

I still don't really understand the issue but I assume we get rid of the comments before squashing?

[vmcj]

They were placeholders to make sure that the differences between commits would point at the right parts instead of git showing differences between unrelated parts. If there was a better way to steer the algorithm I would like to learn that.

I still don't really understand the issue but I assume we get rid of the comments before squashing?

Yes,

[vmcj]

Its now 1 commit, and the commit message should explain most (if not all) of the questions.

@nickygerritsen / @thijskh I think the browserhack should be stable enough to merge this, can you take a look again? I would prefer to have this in main before the next prelim to test that everything works.

[nickygerritsen]

If it works I'm fine with the plan

[thijskh]

I'm not convinced it's an improvement just yet. The scoreboard cells look off, as do the claim buttons.

[vmcj]

I'm not convinced it's an improvement just yet. The scoreboard cells look off, as do the claim buttons.

I can reproduce this. I've now tested this with W10/Edge and there all looks correct. W10/FF also looks correct but I'll test with another OS/FF some more.

[vmcj]

I think this is now fixed without the browserhack by combining the stuff needed for Firefox & Edge. I've fixed the issue @thijskh found by putting this in a class as most of our tables come from the macro.

One annoying thing is the claim button on the submissions_list page which I now needed to move by cheating with the padding of some columns. As we only have this for that one table I think it is fine but an alternative would be to remove the button or put it in another span.