Website Maintenance 30 July 2020

[CBurkhart]

The box containing the user generated message is sometimes too small (especially for friend keys).

If I'm not mistaken this was also newly added to the friends page, and if so it is greatly appreciated!

[euler]

Yeah, I don't know why the user generated message wasn't already on the friends page. I noticed as I was working through the scripts.

The problem with the friend key is occurring because the long string is not wrapping. The obvious answer is make the box bigger, but it's a universal hover box with a fixed size. Any bigger and it would look out of place. And in theory someone could always find a string longer than the size of the box. I'd already tried multiple options, but couldn't decide what worked best. Anyway, I've just modified it now by setting the pre attribute of the hover box to "break-word". It's not perfect, but it probably looks better.

[euler]

And, here is, I am afraid, another problem with a layout issue; problem 720
The example permutations for N=4 are all listed in one line, unnaturally followed by \vdots. Originally each permutation occupied one line.
I guess this would be the last find from me for now.

Thank you again!

Recently we've shifted to MathJax 3 and it seems that one of the ports from version 2 that hasn't been implemented yet in version 3 is the newline code: \\. As a work around, and it shouldn't be a problem once version 3.1 comes out, which should fix it, is to place the section of mathematics between \displaylines{ }. I've done that and it should be displaying properly now.

If you do spot anything else, then please let me know.

[euler]

Thanks for reporting the issue with the persistent sign in; it's affecting me too. I am looking into it, but at the moment I am unable to consistently identify why it is happening.

I think I may have discovered the issue. If you were previously signed in, then you may need to sign out and sign in again, but I hope the change I've made should ensure that the persistent sign in functions as expected.

[forarslys]

This is a rather tiny issue and I am not sure if this is reproducible in every environment, though, an image of the problem 716 is sticking out of the statement box and so is the portrait of Leonhard Euler in the page after solving a problem.

At least, the former one only occurs with the Dark theme, presumably caused by an inconsistent parameter with default theme for the css class "dark_img".
As for the latter one, I did not think of opening the source file at the time when I solved a problem, so I cannot look into it...

For your information, I am using Google Chrome 83.0.4103.61 on Ubuntu 20.04.1 LTS.

[euler]

I like everything to be just right, so I'm grateful to you for reporting these issues.

I've fixed the issue with problem 716. In the main style sheet the maximum width was set to 100%, so if the image is larger than the container, then it will never be larger. Resizing the window scales the image accordingly. Because the images are created with white backgrounds in mind, it doesn't matter what happens at the boundary of most of the images used in problems. That is, you can have a small which region or the image can stop abruptly. But if you're using the dark theme, then it can look a little straight. So for the dark theme I use that dark_img class to create a small buffer zone of white around every image on the problem page and then a grey border to transition it to the dark background. Problem 716 has an image that is larger than the container, which means on the default style sheet that won't be a problem, but with the dark theme, the extra padding of 10px pushes it outside. I've added an override for the dark theme to limit the maximum size of images to 95% of the container just on the problem page and that seems to fix the problem.

However, I've not been able to reproduce the same problem with the Euler portrait myself, using Chrome version 84.0.4147.105 on Windows 10. We'll have to keep an eye on that one, but at the moment I can't see anything in the style sheets that might cause it to happen.

[RagnarGrootKoerkamp]

Not sure how it was before, but I think it'd be a bit nicer if the problem numbers on the progress page were vertically centred. A simple `line-height: 21px` on the `.problems_solved_grid a` element seems to do the trick. (This also needs a `line-height: initial` on the tooltip.) This also increases the clickable area to the full cell (excluding padding) instead of just the text in it.

There also seems to be a redundant empty `<a href=...></a>` tag at the start of each table cell, but maybe there's a reason for it.

[euler]

Thank you, RagnarGrootKoerkamp. That's a keen eye you've got there. Thank you for the helpful tips too. I've made the changes you suggested and tidied up a couple of sloppy insertions, but I couldn't find an empty anchor tag. The only anchor tag in each cell makes it a clickable direct link to the particular problem.

[RagnarGrootKoerkamp]

Sweet!

but I couldn't find an empty anchor tag

Seems like you already cleaned up what I was referring to as part of

tidied up a couple of sloppy insertions

[JohnsSmyth]

The highlight of my row does not cover my name in the eulerians, levels and awards pages. I have not set my location or language, so it might also happen there. This does not occur in the fastest solvers page.

[euler]

I traced the issue to a peculiar change I'd made to one of the classes, so now it's got me wondering why I made that change. It's possible this might have an unintended consequence elsewhere. Anyway, the row highlight in the tables should be working again now, but you may need to hard refresh your cache (Ctrl + F5).

[pjt33]

Just as an impression without actual timing data, the wait for the green tick seems higher than usual today. I don't know whether this is related to the maintenance, but I thought I'd mention it.

[euler]

The server might have been under unusual load, but I've just tested it several times and it didn't seem to be slow right now. The scripts have quite a lot to do when a problem is solved, but we'll keep an eye on it. Thanks for taking the time to report it.

[forarslys]

However, I've not been able to reproduce the same problem with the Euler portrait myself, using Chrome version 84.0.4147.105 on Windows 10. We'll have to keep an eye on that one, but at the moment I can't see anything in the style sheets that might cause it to happen.

I noticed that the portrait stays in the box if the browser width is smaller than certain value. Will resizing the browser wide enough reproduce the problem in your environment?

[euler]

I am only able to reproduce the problem if I change the zoom level of my browser. But I've added "display: flow-root" to the parent division and that should fix the problem caused by the floating image extending outside of its container.

[forarslys]

It is now fixed!
Thank you for taking your time to deal with the issue only dependently reproducible.