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
Followup to c22000
Remove unset() for 'search' type, it will now simply be unset through the regular checking (removed it in the validTypes for that, but it is still in validTypes in HTML5 mode).
Update / remove outdated code comments.
Change-Id: I452462b81360b67b76dd8baa732d52113b6aafe6
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
Changed Html::dropDefaults() so that when an array is
passed as an attribute value, it does not call strval(),
thus triggering a PHP notice. Instead arrays are
imploded with a space as the separator.
Change-Id: I2521b78c7de94c183b7de7e7d4b2b510ab0c7770
When inserting XML elements inline <such as this one>, doxygen chokes
about it not being known. Simply enclosing the tag in double quotes
prevents doxygen from emitting a warning.
Also enclosed a few invalid functions calls such as \. and double quoted
the HTML entities such as &foobar;
Change-Id: I4019637145e683c2bec3d17b2fd98b0c50a932f1
* 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)
* 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
* Using params and option arrays instead of 4 random parameters like Xml::namespaceSelector did
* Right now it's passing $selectAttribs['name'] to Xml::label, this is done because that's what Xml::namespaceSelector did. However it's wrong since labels associate over ID not NAME. Will fix in the next commit, making sure unit tests stay functional first. This bug has been in Xml::namespaceSelector for a long time but usually unnoticed as people kept either defaults. Although it was easy to get wrong as the NAME was configurable but the ID was hardcoded in Xml::namespaceSelector.
* Deprecated Xml::namespaceSelector and made it cal Html::namespaceSelector
* Follows-up r109974, r109698
* XmlTest.php still runs successfully
This patch move an array hidden in Html::expandAttributes() to the top of
the class definition as self::$HTMLFiveOnlyAttribs.
That also make the Html::expandAttributes() method a bit more concise.
HTML browsers strip the first newline from the literal contents of a <textarea>, but keep any additional newlines beyond that.
Prepending an extra newline in Html::textarea() when the contained text started with a newline makes our output basically look like this:
<textarea> <-- (this added newline is ignored)
<-- (any original newline here is preserved)
blah blah</textarea>
This seems to consistently resolve the stripping of single initial newlines from every edit operation as seen on bug 12130; as noted on comments there <https://bugzilla.wikimedia.org/show_bug.cgi?id=12130#c17> this had deleterious effects on Wikisource, where transcription/proofreading tends to involve breaking up lots of little pages, which may have a significant newline at the start of a page boundary.
Text that didn't have initial newlines won't see any difference in the HTML output.
Followup to test cases in r98576, which confirm that supported browsers consistently have this behavior.
* 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.
