Last modified: 2014-04-30 18:33:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T65466, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63466 - mediawiki.util: Deprecate mw.util.$content in favor of mw.hook( 'wikipage.content' )
mediawiki.util: Deprecate mw.util.$content in favor of mw.hook( 'wikipage.con...
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
1.23.0
All All
: Normal minor (vote)
: 1.23.0 release
Assigned To: Fomafix
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-03 09:34 UTC by Fomafix
Modified: 2014-04-30 18:33 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Fomafix 2014-04-03 09:34:13 UTC
mw.util.$content from module mediawiki.util seams to be needless.

	$( function () {
		mw.util.$content...
	} );
can be replaced by
	mw.hook( 'wikipage.content' ).add( function ( $content ) {
		$content...
	} );

mw.hook() is necessary to support Live Preview[1].

[1] https://www.mediawiki.org/wiki/Manual:Live_preview
Comment 1 Gerrit Notification Bot 2014-04-03 09:37:37 UTC
Change 123559 had a related patch set uploaded by Gerrit Patch Uploader:
Deprecate mw.util.$content

https://gerrit.wikimedia.org/r/123559
Comment 2 Krinkle 2014-04-04 20:24:42 UTC
Closing as won't fix per discussion between Daniel Friesen and myself at https://gerrit.wikimedia.org/r/123559.

Although the naming is unfortunate, these are different things for different use cases.

mw.hook( 'wikipage.content' ) is to get a reference to #mw-content-text (the true wiki page content, no skinning around it). It is different from $( '#mw-content-text' ) in that:

* It can be asynchronous (you can register the hook without needing to explicitly wait for document-ready).
* It is more semantically correct if your intent is "change content" because it will re-fire when the content changes dynamically (e.g. after saving an edit with VisualEditor, or when ajax live previewing wikitext, or in some hypothetical "ajax navigation" feature).

mw.util.$content is to get a reference to the body content wrapper (the element containing #mw-content-text, usually indicated by .mw-body). Because mw.util.$content has been around since before mw.hook, it is likely that there are existing uses out there that would benefit from using mw.hook instead. However there remain uses for mw.util.$content where mw.hook is not a suitable alternative.

Having said that, I still think we should deprecate mw.util.$content because it sucks (retrieving its value is tricky because it is asynchronously initialised without a clear callback for when that happens). However until we have an alternative for it, let's keep it.

Ideally we'd just mandate that all skins follow the convention to use mw-body class and then just document that as an API (similar to how addPortletLink's html structure has become more or less skin independent, though not quite there yet) that people use by waiting for domready and querying mw-body or mw-body-primary.
Comment 3 Fomafix 2014-04-05 10:32:14 UTC
Thanks for explanation.

What about a new hook 'wikipage.body'?

In mediawiki.page.startup.js fire
	mw.hook( 'wikipage.body' ).fire( mw.util.$content ) );

In mediawiki.notification.js replace
	$( function () {
		mw.util.$content...
	} );
by
	mw.hook( 'wikipage.body' ).add( function ( $body ) {
		$body...
	} );
Comment 4 Gerrit Notification Bot 2014-04-30 18:33:43 UTC
Change 123559 abandoned by Krinkle:
Deprecate mw.util.$content

Reason:
Superseded by I30bdd893e0a0a340076.

https://gerrit.wikimedia.org/r/123559

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links