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
Migrated some convenience functions from the Xml
class to Html so they can be used. Only added
functions that acted as more than just a wrapper
for another function.
Change-Id: I4cc5876d4be6e04ec554444242cc049a3cff0f58
Previously the behavior was more or less undefined for most attributes
except for the ones in $spaceSeparatedListAttributes (currently 'class',
'accesskey' and 'rel'). If an other attribute is set to an array (no
matter what it contains) the method produces broken HTML like
'key=' and only triggers a warning if error_reporting is enabled. If
error_reporting is not enabled a developer may overlook this.
To clarify: The method always *ALLOWS* array values. This is *NOT*
about unexpected types in the call signature but unexpected
combinations of nested values. These combinations are already
checked in the method but the check was incomplete.
I considered several solutions:
* Simply use the first array element. But we can't know if the first
element is what the caller expected.
* Silently drop all arrays if the attribute doesn't allow lists. This
is close to the current behavior of always returning 'key=' but is a
breaking change for boolean attributes like 'checked' and 'selected'.
Browsers accept the current 'checked=' as true while omiting the
attribute means false.
Choosing to always throw an exception. As above, this is a
breaking change in some cases.
Change-Id: Id5fcbdef2696d0a81a91d54338939ee678475ca3
* $wgHtml5 = false; is now ignored completely.
* $wgDocType and $wgDTD have been removed.
* $wgXhtmlDefaultNamespace is now ignored.
* XHTML5 will be output if $wgMimeType is set to an XML mime type (according to HTML5's rules).
* For backwards compatibility with extensions $wgHtml5 and $wgXhtmlDefaultNamespace are set
in Setup.php but depending on them is deprecated.
Change-Id: Iad9634e2ee420b5a3bbffe550421fde4fa1819b0
Change some tests to use setMwGlobals to have restoring of globals after
the test.
This also removes some save/restore code, which is not needed, due to
the automatically restoring on tearDown with setMwGlobals.
Change-Id: I8d2ac9f6cc14f0bd4ee8eb851c09f2e71babc6e0
The default value for "step" is "1" which effectively bans any decimal
number from being entered into an 'type="number"' field and makes
HTMLFloatField unusable.
Change-Id: I103fd4047814a7fb0dfdc174f36badd5b660b7a4
According to standard the default type for <button> elements is "submit". Depending on compatibility mode IE might use "button", instead.
To work around the IE bug this patch forces the standard "submit", if nothing is specified explicitly.
See remarks on http://msdn.microsoft.com/en-us/library/ie/ms535211%28v=vs.85%29.aspx :
-----
The default value of the type attribute depends on the current document compatibility mode. The default value is submit. In other compatibility modes the default value is button.
...
Windows Internet Explorer 8 and later. The default value of the type attribute depends on the current document compatibility mode. In IE8 Standards mode, the default value is submit.
In other compatibility modes and earlier versions of Windows Internet Explorer, the default value is button.
-----
Change-Id: I3b97a8cac74bbfca63699dfcbf1cc5e9a2cef193
The HTML and XML test now set the globals they depend on
(instead of relying on the default settings).
Tests for the "other" scenarios still exist, globals are
overridden inline. They are automatically restored after each
test## function by PHPUnit from MediaWikiTestCase::tearDown.
Also fixed 2 other problems with the test suite:
* HtmlTest::testDropDefaults forgot to pass
$message to the assertion from the provider ($case[3]).
* The data provider for HtmlTest::testDropDefaults was calling
Html::element directly (instead of calling it within the test)
which is problematic because data providers are expected to be
static. PHPUnit calls them outside the setUp/tearDown flow.
(also fixed the function to be public static, as PHPUnit
expects).
That last one was crucial to make the test still pass correctly.
Updated the expected strings to what they are with these
fixed non-leakage settings.
Took wgHtml5 without xmlform as default. And added tests
for variations where it made sense.
Change-Id: Iccf6ea81f4bc2639273ab2ad101c58788ee49d45
This closely match Html::dropDefaults() logic and hopefully test out
all default dropping.
Introduce a test case that match a failure in f34547ab where attribute
default values passed in an array are not cleaned up.
Change-Id: If8d16b066015ed1bcaf38408511ac3713eaa6540
The default value for value="" on <input> elements is not always an
empty string.
In particular the default value for type="radio" is "on" and by
stripping value="" out of the attributes a "" becomes "on" and our
cleanup code ends up breaking forms.
Change-Id: Ibe5a3be3f45a2f93ef95dbe42729b8f8c94a41cb
HTML5 introduced new types for the input element. For some reasons we
never added them to Html::openElement which would thus strip them even
in HTML5 mode.
The issue is:
$wgHtml5 = true;
Html::element( 'input', array( 'type' => 'color' );
# -> "<input />"
With this patch, we returns: <input type="color" />
Change-Id: I7de373635d0eb47f788d1d664c3a913c8801efd6
* Remove default id/name attributes
* Remove now redundant tests introduced in r110274
* Add tests to make sure label has no 'for' attribute when label isn't null but name/id are unset
* Update tests to not include id="" and name="" when calling with no arguments
* Updating calls to add name/id if needed, and while at it remove useless 'null' params
* Context:
-- Introduced in r109990, r111376, r111315
-- No callers exist that assume these defaults. Forcing an ID that should be unique is annoying and redundant. The name used in the query when submitting a form should be mentioned in the same file where it is used from the submission, never assume what name="" is from unrelated code
-- Same for ID, this is often used in CSS or JavaScript, shouldn't be assumed. (It should be simple to but two simple namespace selectors on a page without getting DOM conflicts)
Since we're here: nothing uses $namespaceNames, $mNamespaceIds or $namespaceAliases
outside of this class (core or extensions) so lets make it protected.
* r109993 broke the test by overwriting namespaces it tried to preserve
* tearDown should always have the opposite order of the overrides in setUp
* Adding wgLanguageCode while at it, no reason not to, just in case.
-- Follows-up r109993
* Previously it was passing $selectAttribs['name'] to Xml::label, which uses its value for the <label for=""> attribute. This works as long as $selectAttribs['id'] and $selectAttribs['name'] match, but when they don't it fails. <label for=""> always corresponds with <{input,text area,select} id=""> in browsers, never with "name".
* Make name/id match eachother by default to avoid backwards compatibility breakages (they used to match in the Xml class method as well)
* Add HtmlTest.php entries similar to the ones in XmlTest
* Fix E_NOTICE about $params['selected'], default to ''
-- Follows-up r109974, r109698, r109990
-- Bug originally introduced in r41425
-- XmlTest.php still runs successfully
-- HtmlTest.php runs successfully
* Has been suggested since August 2009 in r54767 (doc-comment from rawElement/element function)
* Implements normalization for these attributes (removal of duplicates and redundant space)
* Adds support for arrays (instead of just string) for these attributes.
* String are still supported, and are converted to arrays to get the same normalization.
* Wrote unit tests (which pass locally: $ php phpunit.php includes/HtmlTest.php)
* Not trigger for the media-attribute. Reason: Although some people think it's space-separated, it's actually comma-separated. Treating them as space separated might even destroy the value. [2] [3]. Neither the html4 or html5 spec documents media-attribute as space-separated, and as of HTML5/CSS3 the media attribute may contain "media queries".
[1] "In the future, other HTML-specific features might be added, like allowing arrays for the values of attributes like class= and media=" in r54767 by Simetrical.
[2] http://www.w3.org/TR/1999/REC-html401-19991224/types.html#h-6.13
[3] http://dev.w3.org/csswg/css3-mediaqueries/#background
Implementation note: I choose to have a single list of attributes that trigger this feature. Some of these attributes only support multiple values and/or are documented as space-separated as of html5 (such as accesskey), but since those attributes in general have existed in html4 as well (just different w3c spec), they are not stripped if wgHtml5 is not true. So if this feature would (eg. for accesskey) would only be done if wgHtml5=true, then people could get output like <a accesskey=Array /> depending on a configuration variable, which will get messy and make developers' life hard.
