Directly use the UTF-8 encoding of the 'NO-BREAK SPACE' (U+00A0) instead of
the HTML/XML entities   or   or .
With the UTF-8 character the generated HTML is shorter and better to read.
Also change the special value for the label in HTMLForm from   to
U+00A0 but also support   for backward compability.
Bug: T154300
Change-Id: I882599ac1120789bb4e524c4394870680caca4f4
This is really a workaround for an issue in a completely different place:
JS RadioSelectInputWidget internally uses `<input type="hidden">`
rather than real radio buttons, which does not work correctly with the
code in mediawiki.special.preferences.confirmClose.js. Ideally we would
change RadioSelectInputWidget to not do such weird things.
However, I think this is actually a good thing to do in general.
From the user's perspective, PHP RadioSelectInputWidget and JS
RadioSelectInputWidget look and behave the same, so there's no reason
to infuse and rebuild them.
This behavior was implemented in f50cee1375
in which unfortunately I did not document the reason for it. For other
fields it makes obvious sense (the JS widgets have improvements like
autocompletion, or at least look "pretty"), but I have no idea why
I did it for this one.
Bug: T180643
Change-Id: I53e50f8cda39466b2396b374e642c154487888bb
It adds the ability to replace the current section ID escaping
schema (.C0.DE) with a HTML5-compliant escaping schema that is
displayed as Unicode in many modern browsers.
See the linked bug for discussion of various options that were
considered before the implementation. A few remarks:
* Because Sanitizer::escapeId() is used in a bunch of places without
escaping, I'm deprecating it without altering its behavior.
* The bug described in comments for Parser::guessLegacySectionNameFromWikiText()
is still there in some Edge versions that display mojibake.
Bug: T152540
Change-Id: Id304010a0342efbb7ef2d56c5b8b244f2e4fb2c5
It mostly already worked. HTMLForm::trySubmit() needed a little
adjustment to handle things properly.
Change-Id: Ibb17bb61ac0b2d41953249980bc2f23b8a3ae5b6
This is not really what we had in mind when developing the infusion
feature and I think it's not helpful. Most of the time there is just
no benefit; a ButtonWidget generated in PHP and in JS behaves and
looks pretty much the same, and rebuilding it through infusion is a
small performance hit. If you're not adding any event handlers, it only
makes sense for various dropdowns, which have themed styling.
For the primary use case of adding JS behaviors to PHP widgets you
need to call OO.ui.infuse() anyway to get a reference to the JS
widget, and not infusing automatically should make it easier to reason
about your code. Infusion tries to be very transparent, but it can't
hide the fact that the DOM is re-built, making your references to DOM
nodes from before infusion useless and losing anything from PHP that
wasn't included in the config (e.g. custom attributes).
This commit removes automated infusion from mediawiki.page.ready
and adds some custom code in mediawiki.special.movePage and
mediawiki.htmlform. I see only two extensions using infusable OOjs UI
widgets in Gerrit (ArticlePlaceholder and ExtensionDistributor) and
neither should be affected by this change.
Change-Id: I56608c537fc57c5c54960b0603694f2612f45618
It's getting more difficult to navigate the files in includes/htmlform/
with every new field and every new helper class that is being added.
Change-Id: I92ce2356baf6151f17b2440970d5abdf86503820
2016-08-01 07:58:56 +00:00
Renamed from includes/htmlform/HTMLRadioField.php (Browse further)
