Some feedback for your questions and concerns:

• The flex box CSS module is pretty well supported at this point - 96.84% of browsers will render it correctly according to http://caniuse.com/#feat=flexbox. It may be worth testing the responsiveness in IE11. Microsoft offers some free tools for browser testing if you don't have a windows machine - https://developer.microsoft.com/en-us/microsoft-edge/tools/
• Over 99% of visitors to the matplotlib site are using modern chrome/firefox/safari/IE/edge/opera (analytics courtesy of @tacaswell). It's not worth ensuring that the site displays constantly in all exotic browsers, as long as all the content is visible and accessible to site visitors. Try adding 'display:inline-block;' or 'float:left;' to the .flex-item class. It may work as a fallback on the old/exotic browsers.
• I agree that jumping from 1x4 to 2x2 would be a nicer design, and theres a few ways to make this layout work - I think you may need to use media query. Still, I think that this intermediate breakpoint is a vast improvement over the current layout since it prevents page content from being blocked.

Hope this helps!

@doraf Thanks for the comments and remarks :).

WiP

To jump directly from 1x4 to 2x2, I was simply planning to do something like:

<p align="center">
  <div class="flex-container">
    <div class="flex-item">
      <a a href="users/screenshots.html">
        <img align="left", src="_static/membrane_frontpage.png", border="0", alt="screenshots"/>
      </a>
      <a a href="users/screenshots.html">
        <img align="right", src="_static/histogram_frontpage.png", border="0", alt="screenshots"/>
      </a>
    </div>
    <div class="flex-item">
      <a a href="users/screenshots.html">
        <img align="left", src="_static/contour_frontpage.png", border="0", alt="screenshots"/>
      </a>
      <a a href="users/screenshots.html">
        <img align="right", src="_static/surface3d_frontpage.png", border="0", alt="screenshots"/>
      </a>
    </div>
  </div>
</p>

which behaves as expected (at least with Firefox 38 ESR): a flex container with 2 flex items, each one with 2 images (of identical shape), the first left-aligned and the second right-aligned.

Tests with IE11 in a Windows 7 VM seem to be OK (subfigures are centered and they wrap). I will see if I have time (and space) to test another Windows VM with Edge.

I did some experiments with display: inline-block in the .flex-item class but did not notice any changes under all the browsers I have tested. Though, as it does not seem to harm, I think I will let it anyway.

I will update the PR tonight.

Exotic or old browsers

For the record, when I reload the page with Dillo, the CSS seems to be better taken into account the second time (!) and the subfigures somehow wraps when window width becomes too narrow. Though they are not centered, the overall feeling is then OK to me (on such kind of browser).

Being there, I have also tested with an old version of Konqueror (version 4.10.5, 2008…) that I have at work on CentOS 7, and I noticed a regression when using a flex-based layout: the subfigures wraps but the banner is left-anchored (the former unbreakable 4-in-1 banner was centered).

I think that this example is what we need. It scales images, displays 1x4 on wide windows, 2x2 on smaller ones and 4x1 on the smallest. And it does not use flexbox.

@Kojoley Thank you for the ressource address, it was (very) helpful (I did not know anything about CSS until yesterday…).

I managed to get something that is somehow responsive to the window width and does not use flexbox. I am not sure that we want to go down to the 4x1 layout: the main column cannot become narrower than ~ 500 pixels and each subfigure of the banner is 162 x139 pixels². Due to this very low resolution, I do not think it is neither wise to upscale the subfigure as in @Kojoley's link example.

Currently I implemented something in between:

• for large displays, layout is 1x4, all subfigures packed in the centered and possibly downscaled if the window become narrow;
• before it is downscaled “too much”, one switch to 2x2 layout, at 1:1 scale (however the subfigures would currently be downscaled if the column width was able to go below 500 px).
  The window limit used to trigger the layout switching is 1024 pixels, arbitrary based on a few trials.

See below for an overview of the proposed behavior:

• large window (width >> 1024 px): 1x4 layout, native scale subfigures
  
• less large window (width >= 1024 px + eps) : lower limit of the 1x4 layout, downscaled subfigures
  
• even narrower window (width <= 1024 px - eps) : upper limit of the 2x2 layout, native scale subfigures
  
• very narrow window (width << 1024 px) : always the 2x2 layout, and still native scale subfigures as the main column width is always > twice the width of a subfigure…
  

Disclaimer: I did not tested it yet with any browser but Firefox (47).

There are some useful resources for web developers who want to test the site against multiple browsers. Fast googling gave me this, this, and this. I hope it will help you.

I think that this time I got something rather OK. It has a simpler code than before and behave similarly¹ to my previous post with screenshots (and some CSS typos were corrected thanks to @Kojoley).

I rebased, squashing some of the intermediate commits that had been (totally) overwritten by my last commit and reordering them to get something logical.

I tested it as much as I could using free web services like the ones @Kojoley reported. The responsive layout seemed fine to me on all major recent (and major) browsers I was able to test:

• latest version of Opera, as well as IE 11 on Windows 8.1, IE 11 & 13 (the latter meaning Edge I guess) on Windows 10;
• Firefox 38 & 45-47 and Chrome 50 on Windows (again 8.1 and 10) and Linux.

Unfortunately I ran out of “free samples” before having tested it on any Apple OS and Safari version. However I gave it a try with a recent version of Epiphany on my computer (that is also using Webkit if I am correct) and everything was looking fine.

¹ : I reduced to 1000px (prev. 1024px) the window width value that switches from 1x4 to 2x2 layout. This way, people with a 1024x768 full screen will still be shown the 1x4 layout that present more information without having to scroll.

I don't totally understand the CI failure: AppVeyor seems to complain about visual_tests.py that I did not modify.

The error is not about visual_tests.py (actually I do not what is the purpose of the call, because it can be done locally with downloaded artifacts), but about some linkage:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:C:\Miniconda35-x64\envs\test-environment\Library\lib /LIBPATH:.\lib /LIBPATH:C:\Miniconda35-x64\envs\test-environment\libs /LIBPATH:C:\Miniconda35-x64\envs\test-environment\PCbuild\amd64 "/LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64"" "/LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB\amd64"" "/LIBPATH:"C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\ucrt\x64"" "/LIBPATH:"C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x64"" "/LIBPATH:"C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\um\x64"" /EXPORT:PyInit_ft2font build\temp.win-amd64-3.5\Release\src/ft2font.obj build\temp.win-amd64-3.5\Release\src/ft2font_wrapper.obj build\temp.win-amd64-3.5\Release\src/mplutils.obj build\freetype-2.6.1\objs\.libs\libfreetype.lib /OUT:build\lib.win-amd64-3.5\matplotlib\ft2font.cp35-win_amd64.pyd /IMPLIB:build\temp.win-amd64-3.5\Release\src\ft2font.cp35-win_amd64.lib
LINK : fatal error LNK1181: cannot open input file 'Files.obj'
error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\x86_amd64\\link.exe' failed with exit status 1181
Command exited with code 1

But anyway I think it is not your fault.

attn @JanSchulz

visual_tests.py (actually I do not what is the purpose of the call, because it can be done locally with downloaded artifacts),

Yes, that's true, it was just easier to do it on appveyor so that the downloaded artefacts already have the html file which you can use to visually compare the results.

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:C:\Miniconda35-x64\envs\test-environment\Library\lib /LIBPATH:.\lib /LIBPATH:C:\Miniconda35-x64\envs\test-environment\libs /LIBPATH:C:\Miniconda35-x64\envs\test-environment\PCbuild\amd64 "/LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64"" "/LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB\amd64"" "/LIBPATH:"C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\ucrt\x64"" "/LIBPATH:"C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x64"" "/LIBPATH:"C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\um\x64"" /EXPORT:PyInit_ft2font build\temp.win-amd64-3.5\Release\src/ft2font.obj build\temp.win-amd64-3.5\Release\src/ft2font_wrapper.obj build\temp.win-amd64-3.5\Release\src/mplutils.obj build\freetype-2.6.1\objs\.libs\libfreetype.lib /OUT:build\lib.win-amd64-3.5\matplotlib\ft2font.cp35-win_amd64.pyd /IMPLIB:build\temp.win-amd64-3.5\Release\src\ft2font.cp35-win_amd64.lib
LINK : fatal error LNK1181: cannot open input file 'Files.obj'

This looks like something got the quotes wrong: "/LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64""

I'm restarting the build to see if it is a fluke...

So, it builds now... No idea what is the problem here, but I saw that it happened in a few other builds. Sorry, but I've no clue :-/

@JanSchulz Thanks for taking care of the AppVeyor stuff.

Is the failure of test_invisible_Line_rendering something usual with Travis? It is new since the last run (the one with AppVeyor failing), as well as test_mathfont_dejavuserif_01 but this one is a bit flaky from what I understood, isn't it.

backported to v2.x as b3d33ef