* 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 . . .
The code didn't handle the case where a non-associative array was passed
for the attributes, like array( 'autofocus' ) instead of array(
'autofocus' => '' ). In retrospect, allowing this syntax was a bad
decision and I wish I hadn't. Associative arrays shouldn't pretend to
be lists. Probably too much trouble to change it now.
Is implemented in recent WebKit but with no UI, so it's worse than just
giving a server-side error. The only other implementation right now is
Opera and its UI is pretty ugly, so not yet worth the effort to do UA
sniffing. Will backport to 1.16, as a regression fix.
This fixes a few minor discrepancies, like Vector outputting dir=""
(redundant to the one on <html>), and non-Monobook-based skins omitting
the capitalize-all-nouns class (!). This adds Html::openElement() and
refactors Html::rawElement() accordingly, so I checked that all parser
tests still pass.
I wasn't able to figure out if I broke some feature of right-floating
quickbars in the Standard skin, because I wasn't able to figure out what
the feature was in the first place. Hopefully either it works, or
nobody cares, or someone else will figure out what it was supposed to
do. (This is the stuff in getBodyOptions() in Standard.php I deleted;
I'm not sure the addition to sticky.js does what I want.)
Bug 16921. maxlength is not allowed on textareas in HTML4, so this only
works in HTML5. Note that Firefox 3.5 and Opera 9.22 ignore the
attribute (didn't test IE), so this isn't a complete fix. Recent WebKit
does respect the attribute (tested in Chrome 4).
Of course, the length limit of 200 is a hack, just like for edit
summaries, and we really need to move to a non-varchar(255) backend for
all these fields.
Relevant to r45517, r45571.
* spellcheck is not a boolean attribute; it is an enumerated attribute
whose possible values are "true" and "false". If it were boolean, the
permitted constructs would be <input spellcheck>, <input
spellcheck="spellcheck">, and <input spellcheck="">, which would all
set it true, and it would only be set to false if omitted entirely.
(It would be boolean if HTML5 had invented it, but can't be for
historical reasons.)
* spellcheck is valid on any HTML element, not just input, and so should
be stripped on any element.
For reference, a table of all HTML5 attributes can be found at:
<http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#attributes-0>
- EditPage::showEditForm broken up into task specific methods
- Subclasses can indicate they can't support section mode
- Standard inputs should all be now in methods they can be grabbed from by subclasses that want to re-arange things
- Many more places to override and hook into to change behavior
- showTextbox1 parameters changed from $classes to $customAttribs and $textoverride
- showContentForm and importContentFormData added; New workflow to override the wpTextbox1 behavior to use an alternate edit form ui or handle wpTextbox1 content in an alternate way.
- getActionURL added for EditPage subclasses used in places where $this->action isn't enough (ie: EditPage on special pages)
Html::textarea added
This fixes r56407, which fixed bug 20655. Now $wgWellFormedXml is used,
not $wgHtml5. The previous code was outputting malformed XML if
$wgHtml5 and $wgWellFormedXml were both true.
I wish we had unit tests for this. :(
As suggested by Nikerabbit on code review for r56778, noted how boolean
attributes are handled in a function-level comment. Also adjusted
comments to reduce duplication by referring to other functions'
comments.
Reported by Nikerabbit on IRC to happen on Preferences, although I
couldn't reproduce immediately. The change should be helpful for this
kind of thing anyway.
Only affects wikis with $wgWellFormedXml = false. In principle, the old
behavior might have permitted XSS in IE if that setting is false (which
is not the default), but I haven't checked. See
<http://code.google.com/p/html5lib/issues/detail?id=92>.
Some attributes that have defaults in HTML5 don't have defaults in
XHTML1, particularly type="" on scripts and styles (bug 20713). There's
not much point in trying to maintain two separate sets of defaults,
so I've just kept the HTML5 ones and haven't tried to strip any defaults
in XHTML1 mode.
