@Kghbln Thanks for the report. Oddly, in my browser the three that you say shouldn't be bold actually aren't bold (see screenshot below). What browser and OS are you using?

As an aside, I was considering whether we should remove all the bold text to standardise the tab; currently the search preferences tab is the only one that uses any bold anywhere... at least, in my browser! :-)

Obviously you are using a different and newer release of the software which has not yet been rolled out to the Wikipedias. The screenshot is a couple of minutes old and from "enwiki". So I guess that my suggestion has already been tackled. Still, I am on Linux Mint 17.3 with Ch 53 and Fx 49 showing the same behaviour. Yeah, probably the boldness could indeed go for consistency.

@Kghbln I just looked at Wikipedia now, and it looks basically the same as the other screenshot (see below). I tested in three browsers (Chrome, Firefox, Safari), so I'm guessing the difference we're seeing is due to our OS difference (OS X vs Linux Mint).

This is stange. I just started a virtual machine running Win 10 and I get the same bold text on IE 11, Edge 38 as well as Fx 49.

See the screen shot from IE:

The respective class sets "bold" so that is what I am getting:

.client-js #preferences legend {
    font-weight: bold;
}

It's a Monobook versus Vector issue. Kghbln is using Monobook, Deskana is using Vector.

In T149815#2767333, @Jay8g wrote:

It's a Monobook versus Vector issue. Kghbln is using Monobook, Deskana is using Vector.

Oops, thanks for helping out here. Yeah, in case on is reporting an interface issue one should mention the interface used. :( I am sorry for that confusion.

So this is a dupe to which task?

In T149815#2767604, @Kghbln wrote:

So this is a dupe to which task?

I don't think it's a duplicate; I closed because the problem isn't really with search but with the Monobook skin. An alternative to closing is to reopen the task, tag the MonoBook project, and remove Discovery related tags. Feel free to do that. :-)

I closed because the problem isn't really with search but with the Monobook skin.

Another tiny note. Just closing the task because it does not belong to "your department" is not the best idea. I still have the impression that you basically agreed on this being an issue. So for some people this approach may be pretty discouraging.

This is a CirrusSearch bug and not a MonoBook bug. CirrusSearch should not be generating <legend> elements here. It's not even valid HTML; <legend> must be the first child of <fieldset>, and there must not be more than one. There are no fieldsets here and there are three legends.

Here's the generated HTML for reference: (this is copied from the Vector rendering)

<fieldset id="mw-prefsection-searchoptions">
<legend>Search</legend>
<table class="mw-htmlform-nolabel" id="mw-htmlform-searchoptions"><tbody>

</tbody></table>

<fieldset id="mw-prefsection-searchoptions-completion">
<legend>Search completion</legend>
<table class="mw-htmlform-nolabel" id="mw-htmlform-completion"><tbody>
<tr class="mw-htmlform-field-CirrusSearch\HTMLCompletionProfileSettings"><td class="mw-label"><label for="mw-input-wpcirrussearch-pref-completion-profile"></label></td><td class="mw-input"><div><legend>Set the behavior for autocomplete (search-as-you-type) suggestions.</legend><strong>Completion suggester</strong><legend>The <a class="external text" href="https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:CirrusSearch/CompletionSuggester">completion suggester</a> is an algorithm for search suggestions with better typo correction and search relevance.</legend><div><div style="vertical-align:top; display:inline-block;"><input id="mw-input-wpcirrussearch-pref-completion-profile-fuzzy" checked="" type="radio" value="fuzzy" name="wpcirrussearch-pref-completion-profile"/></div><div style="display:inline-block"><label for="mw-input-wpcirrussearch-pref-completion-profile-fuzzy" style="font-weight: bold">Default (recommended)</label><div>Corrects up to two typos. Resolves close redirects.</div></div></div><div><div style="vertical-align:top; display:inline-block;"><input id="mw-input-wpcirrussearch-pref-completion-profile-strict" type="radio" value="strict" name="wpcirrussearch-pref-completion-profile"/></div><div style="display:inline-block"><label for="mw-input-wpcirrussearch-pref-completion-profile-strict" style="font-weight: bold">Strict mode (advanced)</label><div>No typo correction. No accent folding. Strict matching.</div></div></div><div><div style="vertical-align:top; display:inline-block;"><input id="mw-input-wpcirrussearch-pref-completion-profile-normal" type="radio" value="normal" name="wpcirrussearch-pref-completion-profile"/></div><div style="display:inline-block"><label for="mw-input-wpcirrussearch-pref-completion-profile-normal" style="font-weight: bold">Redirect mode (advanced)</label><div>No typo correction. Resolves close redirects.</div></div></div><strong>Prefix search</strong><legend>The legacy search-as-you-type suggestion algorithm.</legend><div><div style="vertical-align:top; display:inline-block;"><input id="mw-input-wpcirrussearch-pref-completion-profile-classic" type="radio" value="classic" name="wpcirrussearch-pref-completion-profile"/></div><div style="display:inline-block"><label for="mw-input-wpcirrussearch-pref-completion-profile-classic" style="font-weight: bold">Classic prefix search</label><div>No typo correction. Matches the beginning of titles.</div></div></div></div>
</td></tr>
</tbody></table>

</fieldset>


</fieldset>

There are two valid <legend> tags near the beginning, generated by the HTMLForm class in MediaWiki core. The three <legend> tags afterwards are invalid, they should probably be <p> or something. They're hardcoded in the CirrusSearch\HTMLCompletionProfileSettings::getInputHTML() method.

@matmarex My thanks go to you for fixing this! It is much better to forget about referencing a bug than not working on a bug at all. :)