* Prepare the usage of MediaWiki UI.
* Add new HTMLForm output mode "inline" (very close to "raw")
Bug: 71436
Change-Id: I12240aaf624dff5219b344648b20373594b5ec46
* Sanitizer: dev.w3.org/html5/spec-preview
Follows-up 8e8b15afc6.
Use stable reference to www.w3.org/TR/html5 instead (currently
from October 2014) instead of an old preview branch from 2012.
* parserTests: dev.w3.org/html5
Follows-up 959aa336a1.
Url is now a dead end. Replaced with link to a draft from around
that time. The relevant section no longer exists in the curent
spec as it got split off into a separate spec. Maybe this one:
https://url.spec.whatwg.org/#percent-encoded-bytes
* Parser, HTMLIntField: dev.w3.org/html5
Use stable reference to www.w3.org/TR/html5 instead.
* HTMLFloatField.php: dev.w3.org/html5
Url is now a dead end. Draft from around that time:
http://www.w3.org/TR/2011/WD-html5-20110525/common-microsyntaxes.html#real-numbers
The section "Real numbers" no longer exists in the current spec,
but the Infrastructure chapter has a section on floating point
numbers that describes the same sequence now.
Change-Id: I7dcd49b6cd39785fb1b294e4eeaf39bda52337b2
Various fields use this differently than I thought, breaking things.
Let's add a separate variable.
Change-Id: Ia974a42c2a905cbc9e8405d9f03c10c8ad692864
…and in general, work with the existing HTMLForm design for defining
display formats, rather than against it.
Breaking changes:
* HTMLForm::isVForm() is now deprecated.
* You can no longer do this:
$form = new HTMLForm( … );
$form->setDisplayFormat( 'vform' ); // throws exception
Instead, do this:
$form = HTMLForm::factory( 'vform', … );
When using FormSpecialPage, override the new getDisplayFormat() method
instead of calling $form->setDisplayFormat() in the alterForm() method.
(Other display formats are not affected, only 'vform'.)
Bug fixes:
* Correctly suppress empty labels for VForm fields
* Correctly disable <fieldset/> wrappers for VForms
Other benefits:
* Reduce code duplication related to $getFieldHtmlMethod
* Introduce HTMLForm::factory() method for constructing HTMLForms
Related cleanup:
* Correctly style 'reset' buttons in MediaWiki UI mode
* Label $wgHTMLFormAllowTableFormat as a mobile-specific hack
* Display checkboxes normally in MediaWiki UI mode (removed weird
override that only broke things). Also, always render checkboxes
in VForms as .mw-ui-checkbox.
* self:: → static::
Bug: T85285
Change-Id: I086a84f1c8cc6a16710709b7806c7f5f96462b32
One call in core already called it non-static
Avoid:
[GlobalTitleFail] MessageCache::parse called by
Message::toString/Message::parseText/MessageCache::parse with no title
set
Change-Id: Ic91e715177c0a4578825640a31ec68ecba3176e0
Pass the HTMLForm parent instance in the constructor so context
is available when parsing a message.
Change-Id: I532c0d95698cbcc57294b9bd2725f33838f393a9
A reason on a SelectAndOtherField can have two parts, one of the scroll
down box and a free text field. The free text field is actually
unlimited.
This patch allows the maxlength on that field. To respect the concat of
the two parts, also javascript code is added, which adds a dynamic
maxlength to respect also the text from the scroll down box.
The HTMLSelectAndOtherField is only used on Special:Block,
where the maxlength attribute is now set to 255 (length of the database
field ipb_reason).
Change-Id: I5c164b41ab047e7ecf9d92db6eddcc980e2db048
Use HTMLForm instead of self-built table structure, to be
prepared for use with MediaWiki UI.
Bug: 71446
Change-Id: I5c03dc543b910aab27a26a5a223341be50893cf3
HTMLHiddenField is unable to output a non-default value, which makes it
unsuitable for actually persisting changes across multiple form
submissions. To preserve compatibility with forms that aren't expecting
persistence, fixing this requires a new parameter in the field
definition.
Also, due to the unusual way that hidden fields are added to the HTML
output, they are not being correctly handled by HTMLFormFieldCloner.
Special-case that.
Change-Id: I1fde7372401299b4432d28ac61982d47d5f3bbea
Although the classes (e.g. mw-ui-input) are still there,
the style module was not being loaded.
This affects forms that deliberately use VForm even without
wgUseMediaWikiUIEverywhere (since they pre-date it).
This applies at least to PasswordReset, which was added in
d32891d99f (last October).
Bug: 71448
Change-Id: Ieca36c0036d4c93244c533237eddd678564dd3c0
* Apply mw-ui-destructive to Special:Preferences/Reset
when $wgUseMediaWikiUIEverywhere is enabled
Introduces HTMLForm->setSubmitDestructive()
Bug: 65317
Change-Id: I1d6691dce3e7dab662bda9a718e16c5caee6c041
Check for isVForm() and apply styling matching the default submit button
when generating alternate form submit buttons.
Change-Id: Ia3313087248af1537ac4740694846b6ff1187b1a
- Added space after reserved words: function, foreach, if
- Combined 'else if' into elseif
- Added braces to one-line statements
- Added spaces after comma, before parentheses
Change-Id: Ie5bbf680d6fbe0f0872dab2700c16b1394906a72
This is much like the one OAuth has in
Special:OAuthConsumerRegistration/propose, except it stores the
autocompletion options in a data property rather than a global and uses
jquery.suggestions rather than jquery.ui.autocomplete.
Change-Id: I42473cea75f3706cc0125167f9191275ca6cb3b0
Ensure that a form field which sets 'csshelpclass' and is rendered as
a vform receives expected styling.
Change-Id: Ibe082e07fe846334bd4dc257c9c0df8db23a1957
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
Hidden fields are supposed to be ignored during validation; more
completely ensure this by checking in HTMLForm::trySubmit before calling
validate.
Also, more properly handle HTMLCheckFields in the isHidden check by
casting their booleans to strings.
Bug: 68132
Change-Id: I84f8239c299727b773015643048eed4684417733
When a message needs plural support, it should be possible to parse a
message object with the params set.
Change-Id: Ifb67952b589a1821cde452b2be3f327f24e6b534
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I41a84e8e1dec39170aa655250325ffc485eaeaef
- Added/removed spaces around parenthesis
- Added space after switch/if/foreach
- changed else if to elseif
Change-Id: I99cda543e0e077320091addd75c188cb6e3a42c2
There is now a new option named csshelpclass that can be passed in form
descriptors for HTMLForm objects. This option accepts a css class and
applies it to the help text that is provided with the help option in the
form descriptor.
Bug: 65087
Change-Id: If1bd1d12a9159895f45c9cf0fbb7992e4c7e3526
