$fieldType = static::class; ... $html .= Html::rawElement( 'tr', $rowAttributes + [ 'class' => "mw-htmlform-field-$fieldType {$this->mClass} $errorClass $rowClasses" ], $field );
So this is fine when a class is not namespaced, but if you try and namespace the class (as I'm trying to do in BetaFeatures), this changes the class name applied on the element.
The expected <tr class="mw-htmlform-field-HTMLFeatureField"> becomes <tr class="mw-htmlform-field-MediaWiki\Extension\BetaFeatures\HTMLFeatureField">
While this is possibly fine, it feels unexpected. And I wouldn't have noticed without the tests inside BetaFeatures, until maybe someones CSS gets broken somewhere in production.
It's obivously easy enough to "workaround" this by adding a cssclass entry for the old name, and then update the tests (if applicable) to match.
It does lead me to wonder if I (or anyone else) has "broken" things in similar situations when namespacing extensions. Other possible examples could be HTMLFormRadioRangeColumnLabels in MediaWiki-extensions-SecurePoll... Where a cssclass replacement wasn't added.
It would be possible to add a constructor (if one doesn't exist) already into the subclass, and then inject/add a cssclass entry, such as the below... Which seems slightly preferable to adding a cssclass at every usage point.
public function __construct( $params ) { if ( isset( $params['cssclass'] ) ) { $params['cssclass'] .= ' mw-htmlform-field-HTMLFormRadioRangeColumnLabels'; } else { $params['cssclass'] = 'mw-htmlform-field-HTMLFormRadioRangeColumnLabels'; } parent::__construct( $params ); }
Or the other option is doing something (reflection based?) to look if the class is namespaced, and if it is, add an extra class... Or unconditionally just do str_replace( __NAMESPACE__ . '\\', '', get_class() ) and drop the namespacing entirely...