I'm aware that adding these type hints does have the potential of beeing
a breaking change if a caller misuses it. Note that it really is a misuse
in this case because all these parameters are documented as "array" and
nothing else.
I double-checked the usages of all methods I touched and could not find
any caller that does not fulfill the contract of these methods - in other
words, all callers I can find in my local code base (which includes all
major extensions like Echo, Flow, Parsoid, VisualEditor and so on) pass
arrays to these parameters.
I left the main methods openElement, rawElement and so on untouched
because they are called way to often (500 times and more).
Change-Id: I5ca13b26fb08d732ce4cadc4ee3d38314e606fd3
$wgLogoHD is meant to contain high-density alternatives for $wgLogo, but its
keys include the trailing 'x' (e.g., '1.5x'), making it unusable with
Html::srcSet(). Fix that by normalizing all density values to have a
single trailing 'x'.
Change-Id: I62cc3a9e4aeff3a7cb102de2965b8b40fd106c37
Escape > characters in attributes, so we don't confuse post-processing,
like LanguageConverter.
Bug: T73394
Change-Id: I768e2a12c7b6ba635e6c8571676b8c776b16bf72
I found this because my PHPStorm complains about the type mismatch.
I could have changed the @param tag to "string|bool", but when looking
at the code, the $class variable is casted to a string anyway and
never used as a bool.
Change-Id: I3450fa8a898923bbae26830ed3be0017685020d3
This is a pure inline-documentation patch. It fixes a few actual
mistakes in documentation tags and makes some generic "array" types
more specific, if that's possible.
Change-Id: Id02e1e936624b845316b8ce99f8b8d2a1f829e97
Hack #1: We were ignoring the 'size' attribute of input fields when
$wgUseMediaWikiUIEverywhere was true. Let's not do that.
Hack #2: We were setting a min-width for MediaWiki UI input fields,
because fields which were supposed to be full-line were becoming
tiny because of hack #1. Let's not do that either.
Bug: T92498
Change-Id: I1d2c6c9eb60b52a7267c122a719cfdaa1f74f815
We were always adding it previously, which seemed harmless since
'mediawiki.ui.input' RL module, providing the styling, was only loaded
if $wgUseMediaWikiUIEverywhere was true… unless someone loaded it
manually to have specific input fields styled. Whoops.
There are a lot more unconditional additions like this in tons of
places in the code, and someone should check whether each one is
intentional or not, but probably no one will. Oh well.
Bug: T92496
Change-Id: I5e91a3852a76ebbbfe64485bccb4c30ddee28b66
Old advice from 2009 (7aa4a8f9), not quite useful nowadays. The preceding
sentence already says that in absence of attributes the function may not
do much.
Change-Id: I4d276d6f42394fc09662ddfd7e1ffd13fb197bf6
Stop littering MediaWiki with globals, provide a common
api for generating them similar to how we do text input
attributes before things get out of control.
Adds
* submitButton
* linkButton
Change-Id: I61bb3c358f755ed9f2153d94b744c1a9da02c456
There are no files worth referencing there anymore.
No usages found in extensions, only one usage in core already didn't
depend on that behavior.
Change-Id: If1fd68a3a7355c8195fd2aad86e7584a5772bd4c
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
Although it's allowed by the HTML Living Standard in particular
circumstances, the rules are non-trivial and can not be enforced
by this method since it has no context.
For example, as of http://web.archive.org/web/20140807160955/http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#optional-tags
it says:
"A head element's end tag may be omitted if the head element is not
immediately followed by a space character or a comment."
Html::closeElement has no way of knowing whether there is a space
character or comment after the tag.
There are similar issues with some other tags (e.g. body). Also,
even when the rule should be followed anyway (e.g. lists can only
contain li elements), there is evidence of browser issues (bug 52210).
Use closing tags for all elements for simplicity.
Bug: 52210
Change-Id: I97ce415288300e40c4d0aa0442bdf4ee3dedb30f
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
- 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: I783e4dbfe5f6f98b32b9a03ccf6439e13e132bcc
- Added/removed spaces around parenthesis
- Added space after switch/if/foreach
- changed else if to elseif
Change-Id: I99cda543e0e077320091addd75c188cb6e3a42c2
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
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I0056b4a8df243cfc0c5f25378de48f7a35170aca
Also swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: Ic36c8c7820a6c2d603f1138130670c6bf6a1ca59
- Place commas correct
- Moved comments
- Add space after if/foreach/catch
- Reformat some conditions
- Removed trailing spaces/tabs
Change-Id: I40ccda72c418c4a33fcd675773cb08d971510cdb
Also removed some unnecessary ones. I think I've caught them all.
The spaceless version already appears in core ~300 times (after
accounting for false positives when grepping). Some consistency would
be nice.
Change-Id: I607655b5f4366e66dc78730d5fd2f57ed8776cae
Finish up with the /specs/web-apps/current-work/multipage/ urls that
haven't been updated to /html/.
Change-Id: I4dbee0477eea440b0e8f113b1d393c6e0c739c4c
* $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
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
* Ran spell-checker over code comments in /includes/
* A few spellchecking fixes for wfDebug() calls
Found one very strange (NOOP?) line in Linker.php - see "TODO: BUG?"
Change-Id: Ibb86b51073b980eda9ecce2cf0b8dd33f058adbf
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Added/removed spaces after opening/before closing parentheses
Added a space after a comma
Removed unneeded parentheses in condition
Change-Id: I306091347ccaaf11dee0cdfda3019cb0c12be51b
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
* adds $wgResponsiveImages setting, defaulting to true, to enable the feature
* adds 'srcset' attribute with 1.5x and 2x URLs to image links and image thumbs
* adds jquery.hidpi plugin to check pixel density and implement partial 'srcset' polyfill
** $.devicePixelRatio() returns window.devicePixelRatio, with compat fallback for IE 10
** $().hidpi() performs a 'srcset' polyfill for browsers with no native 'srcset' support
* adds mediawiki.hidpi RL script to trigger hidpi loads after main images load
Note that this is a work in progress. There will be places where this doesn't yet work which output their imgs differently. If moving from a low to high-DPI screen on a MacBook Pro Retina display, you won't see images load until you reload.
Confirmed basic images and thumbs in wikitext appear to work in Safari 6, Chrome 21, Firefox 18 nightly on MacBook Pro Retina display, and IE 10 in Windows 8 at 150% zoom, 200% zoom, and 140% and 180%-ratio Metro tablet sizes.
Internally this is still a bit of a hack; Linker::makeImageLink and Linker::makeThumbLink explicitly ask for 1.5x and 2x scaled versions and insert their URLs, if different, into the original thumbnail object which (in default handler) outputs the srcset. This means that a number of places that handle images differently won't see the higher-resolution versions, such as <gallery> and the large thumbnail on the File: description page.
At some point we may wish to redo some of how the MediaHandler stuff works so that requesting a single thumbnail automatically produces the extra sizes in all circumstances. We might also consider outputting a 'srcset' or multiple src sizes in 'imageinfo' API requests, which would make ApiForeignRepo/InstantCommons more efficient. (Currently it has to make three requests for each image to get the three sizes.)
Change-Id: Id80ebd07a1a9f401a2c2bfeb21aae987e5aa863b
