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.
Outputting ' foo="" on `foo = null` promotes the writing of overly verbose code to avoid it, and ugly methods like our old Linker::getLinkAttributesInternal, both of which are completely counter to the purpose of Html::.
See r67090 for context. Everywhere that I've found this breaking
well-formedness is fixed. Tested with the following Python:
import xml.sax
class Myhandler(xml.sax.ContentHandler):
pass
h = Myhandler()
for page in ('BrokenRedirects', 'Deadendpages', 'DoubleRedirects', 'Longpages', 'Ancientpages', 'Lonelypages', 'Fewestrevisions', 'Withoutinterwiki', 'Protectedpages', 'Protectedtitles', 'Shortpages', 'Uncategorizedcategories', 'Uncategorizedimages', 'Uncategorizedpages', 'Uncategorizedtemplates', 'Unusedcategories', 'Unusedimages', 'Unusedtemplates', 'Unwatchedpages', 'Wantedcategories', 'Wantedfiles', 'Wantedpages', 'Wantedtemplates', 'Allpages', 'Prefixindex', 'Categories', 'Disambiguations', 'Listredirects', 'Userlogin', 'CreateAccount', 'Blockip', 'Ipblocklist', 'Unblock', 'Resetpass', 'DeletedContributions', 'Preferences', 'Contributions', 'Listgrouprights', 'Listusers', 'Activeusers', 'Userrights', 'Newimages', 'Log', 'Watchlist', 'Newpages', 'Recentchanges', 'Recentchangeslinked', 'Tags', 'Listfiles', 'Filepath', 'MIMEsearch', 'FileDuplicateSearch', 'Upload', 'Statistics', 'Allmessages', 'Version', 'Lockdb', 'Unlockdb', 'LinkSearch', 'Randompage', 'Randomredirect', 'Mostlinkedcategories', 'Mostimages', 'Mostlinked', 'Mostlinkedtemplates', 'Mostcategories', 'Mostrevisions', 'ComparePages', 'Export', 'Import', 'Undelete', 'Whatlinkshere', 'MergeHistory', 'Booksources', 'Blankpage', 'Blockme', 'Emailuser', 'Listadmins', 'Listbots', 'Movepage', 'Mycontributions', 'Mypage', 'Mytalk', 'Revisiondelete', 'RevisionMove', 'Specialpages', 'Userlogout'):
xml.sax.parse("http://localhost/git-trunk/phase3/index.php?title=Special:" + page, h)
I had to manually skip some of these for unrelated reasons, but none of
them became malformed because of this commit. Also tested the main page
and Special:Random a bunch of separate times. There are probably other
well-formedness errors lurking, but they can be fixed as they're
reported.
Expands on r67283 by not using any HTML5 input types either, except
search. Otherwise you'd still have problems when changing integer
fields in Special:Preferences, say. Sad, since in Opera it had a cute
little widget for incrementing/decrementing, and types like email have
some neat effects on platforms like the iPhone (see
<http://diveintohtml5.org/forms.html#type-email>). But there's no other
way to disable the constraints these impose without using JS, and given
how broken WebKit is right now . . .
