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.
This fixes some possible XML invalidity from r54767: CDATA stuff was
being added only if $wgHtml5 was false, instead of whenever
$wgWellFormedXml is true. Also, it uses CDATA for script as well as
style, but in both cases only uses it if there's a & or < somewhere.
This fixes r54567. That made the password fields on Special:ResetPass
always required, but in fact the current password should never be
required (existing users always might have empty passwords), and the new
password is only required if $wgMinimalPasswordLength > 0.
This commit also permits passing array( 'required' ) to
Html::(rawE|e)lement() instead of array( 'required' => 'meaningless' ),
for boolean attribs only. This syntax is used in SpecialResetpass.
On second thought, if you're outputting user-supplied JS without careful
validation, it doesn't really matter if it's HTML-escaped or not. :D
CSS has expr() and such too.
Split the giant arrays of attributes/values to one item per line, which makes them easier to look at, easier to grep, and easier to see what's happening when they're changed in diffs.
We're not printing; vertical space isn't at a premium. ;)
