HTMLFormField::getAttributes() is unfortunately reused both for
generating HTML tag attributes and generating OOUI widget
configuration. For boolean ones passing '' for true (empty string)
works for HTML (where the attribute only has to be present), but not
for OOUI (where the configuration option has to be truthy).
It would be cleanest to pass true/false, which is the expected input
for OOUI widgets and which the Html class handles intuitively, but it
seems that these values often end up in the Xml class's methods
instead (somebody remind me why do we even have that?). So let's play
it safe and pass the name of the parameter instead, which is okay for
both HTML/XML (both disabled="" and disabled="disabled" work the same)
and OOUI widgets.
(Note also that the whole thing relies on the default value of these
boolean parameters/attributes being false.)
This was not spotted before because we had hacks for this problem in
all the important places. This commit reverts three such hacky
patches that missed the underlying problem:
* e25eb30ea8
* 70910cd13c
* 8a164ff9f9
Change-Id: Ic6a1f3758cba62147f7fe8127cc0a83c695b0212
HTMLTitleTextField will automatically validate title input, can
optionally ensure the title is in a specific namespace, is creatable, or
already exists.
The field currently doesn't support GET requests since validation on
empty strings fails.
Bug: T104420
Change-Id: I45718462570d0a523a148c3830b1116b634df050
"spellcheck" attribute requires literal "true" or "false" values and can not
just be implemented by adding it to the list of HTMLFormField::getAttributes's
$boolAttribs.
Change-Id: I5882e71af2ca64d367a1824634f61e16097e341d
* Convert Special:LinkSearch to use HTMLForm for preparation of MediaWiki
UI everywhere
* Add support for dir= tag in HTMLTextField
Bug: T73439
Change-Id: I8503c391a40f1654f8570578a9de9015d86c9845
This provides better mobile experiences on various pages
and a more consistent UI across both mobile and desktop.
It does this in two ways.
1) Forces HTMLForms to not use table based layouts so as
not to interfere with responsive nature of mediawiki ui elements
2) Applies MediaWiki.UI classes to most pages
If a page is created via Xml or Html classes it will use mediawiki ui
Where possible I've added classes unconditionally, but for cases of buttons
this is behind the $wgUseMediaWikiUIEverywhere global since button styling is
enabled on pages by default and for checkboxes since it is changes HTML markup.
3) Adds all MediaWiki.UI styles to pages which can use it
When enabled:
* Apply these styles to all pages which use HTMLForms
* Apply to EditPage
* Apply to anything that uses certain elements outputted by the
Xml or HTML helper classes
* Apply to History page
* Apply to protection page
* Apply to move page
* Apply to deletion page
Currently kept behind a global to allow us time to finetune
existing elements. After further testing we will look to kill the
globals and make mediawiki.ui the default
See: I430c0fbb79d2a33bb828b2427bda0ee01115d73f
Change-Id: I47db5eab4569514d039261d11b6dedb0eeae17b5
SecurePoll will have a field that's a url, so we may as well use the
correct HTML5 input type for it.
Change-Id: Id3ddd8f2efdff08c8a188089d321d143ce5ef9c9
It is already set for some fields in Special:Block, but are
discarded by HTMLForm and its fields.
Some notes:
- fields with multiple inputs (radio, select and other, select
or other) will have the same tabindex set on all elements
- Some items such as multi-select and check matrix are not yet
implemented
Change-Id: I3e1ba7f16f3a3183f231afcf60dd392ce6d6eb6b
