Fix Ctr+F search on the new website?

[Leif Andersen]

Hey all,

I noticed that Ctr+F based searching is kind of uncomfortable on the new website. Namely, if I am searching for a word that is located below one of the images, it gets highlighted like you would expect, but the image doesn't actually disappear. Thus I need to play whack-a-mole to find the highlighted text myself.

Instead, would it be possible to have the image disappear when the relevant text is highlighted?

Thoughts?

Thanks.

~Leif Andersen

[Dupéron Georges]

Screenshots for the CSS posted above.

[Dupéron Georges]

[CC'ing the dev list]

Good catch!

I looked this up a bit, unfortunately it seems that there is no reliable way to detect when the browser's search feature is started, let alone know where the results are and which one is currently highlighted.

None of the options available is entirely satisfactory:
* Use JavaScript to detect when Ctrl+F, "/" and similar search keys are pressed, shortly followed by a loss of focus as described in [1]. When this happens, force all the boxes to be visible. As said in [1], this won't work when the search function is invoked via the menu, or with non-standard search keys
* Use display:none instead of or in addition to opacity:0. This will make the text non-searchable, which kinda solves the "invisible text found" issue, but is not really what we want. It would also most likely prevent the text from being read by screen readers, which is bad on the accessibility side.
* Change the design to always show the text, at least with a 30% opacity or something (like is done for the source code boxes).
* Use the CSS below to make the text's color a transparent one, instead of having the whole box transparent. It seems that both Chromium and Firefox highlight text with the color rgba(0,0,0,0), see the attached screenshots. It doesn't show up the whole text where the match was found, but at least it's very clear where one should put the mouse to see the full text, instead of playing whack-a-mole

.feature > .inner a {
    color:rgba(0,0,0,0);
    transition: color 0.3s ease, background 0.3s ease;
}

.feature > .inner {
    opacity: 1; /* was 0 */
    color:rgba(0,0,0,0);
    background:rgba(255,255,255,0);
    transition: color 0.3s ease, background 0.3s ease;
}

.feature:hover > .inner a {
    color:rgb(6, 121, 167);
    transition: color 0.3s ease;
}

.feature:hover > .inner {
    color:black;
    background:rgba(255,255,255,1);
    transition: color 0.3s ease, background 0.3s ease;
}

It might however be unwise to rely on that behaviour. An alternative would be to use opaque white text (and transition it to opaque black on hover), and in the non-hovered state put the image *on top* of the white text (so that the text doesn't leave white artefacts on the picture), using an empty :after pseudo-element or a :before + a z-index. Aligning the :before or :after element properly turns out to be a pain, though (especially since the title line does need the image as a "real" background, and only the "main" part of the box need the image atop the white text when unhovered, but below the text when hovered).

[1] http://stackoverflow.com/a/6680403/324969