Page MenuHomePhabricator

[Regression] skin: errorbox text should not be bold by default
Closed, ResolvedPublic

Description

Change-Id: If606203218ece5974a956a3d41d5db40f55b2d5c fixed bug 33438 (misuse of <strong> in SpecialPreferences.php's successbox) by making *all* errorbox, successbox, and warningbox text bold, even in the many forms that don't want this.

In particular, this makes Create account form errors, which can go on for paragraphs (e.g. those from the AntiSpoof extension), into swaths of ugly bold text. And to fix 47691 I added a <strong>Account creation error</strong> to Create account's errorbox, but now this heading is indistinguishable from the error text.

The change to skins/common/shared.css needs to be reverted. Forms that want bold text in {error,success,warning}box should either apply an additional CSS style (e.g. a .mw-bold utility style), or use a CSS selector (e.g. .mw-special-Preferences .successbox) that only bolds in forms that want it.


Version: 1.22.0
Severity: major

Details

Reference
bz48197

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:17 AM
bzimport set Reference to bz48197.

swalling wrote:

Yeah there's no reason all of the text should be bold in an error or success box. Only the header needs this, at most.

ganeshaditya1 wrote:

how about if we add a
.successbox hx{
font-weight: bold;
}
and similar code to error box and other boxes as well ?

or I can't really think of any case where the text in a successbox would run into paragraphs of text(I have seen very little code of mediawiki)unlike the error box. so we should add font-weight: bold only to the successbox ?

Related URL: https://gerrit.wikimedia.org/r/62571 (Gerrit Change I1a3d774c2daef158176479fba7828b383a195bb9)

A simple solution is to restore the <strong> in includes/specials/SpecialPreferences.php but without the \n:

<div class="successbox"><strong>$1</strong></div>

Then no <p> tags are generated and the HTML is standard compliant.

Ganeshaditya's change I1a3d774c linked above uses a different solution, but IMO a fine one as well.