Was only used by UploadWizard, and no-where else in Wikimedia Git.
UploadWizard has its own copy as of last year. (T144974)
Change-Id: I3d426f67f8ba061d10434469f261cb725bd672d6
addEmbeddedCSS() is a big part of the hot code path that moves a module from
state "loaded" to "ready". Especially on repeat views (where most loads
are cache hits from local storage), this is the main thing that JS spends time
on before running scripts (which must wait for the styles to apply first).
* newStyleTag: Avoid use of jQuery.
Before
- jQuery()
- jQuery#init
- jQuery#before
- jQuery#domManip, jQuery#buildFragment, jQuery#inArray
- Node#insertBefore
- Node#appendChild
After
- Node#insertBefore
- Node#appendChild
* getMarker: Store raw Node instead of jQuery object. Makes it easy for other
code to avoid jQuery. And for those that don't, creating a jQuery object is cheap.
Also use querySelector directly since it's ensured by our feature test.
The only cases jQuery/Sizzle accounts with querySelector is IE8 (already excluded
by our feature test), and Opera 12 (in an edge case that doesn't apply to this
selector).
Before
- jQuery
- jQuery#init
- jQuery#find
- Sizzle
- querySelectorAll
- jQuery#pushStack
After
- querySelector
* addEmbeddedCSS: This was needlessly calling the fairly slow .data() method for
all style tags in all browsers. It should've been guarded by IE<=9 if-statement.
The consumer of this data property already had that check. The setter did not.
Before:
- getMarker
- ..
- newStyleTag
- ..
- jQuery#data
- jQuery#each, jQuery#data, internalData, ..
- fireCallbacks
- ..
After
- getMarker
- newStyleTag
- fireCallbacks
- ..
Change-Id: Ie5b5195d337b5d88f0c2ca69d15b13a4fb9d87e2
From https://developer.mozilla.org/en-US/docs/Web/API/File :
A File object is specific kind of a Blob, and can be used in any
context that a Blob can. In particular, FileReader, URL.createObjectURL(),
createImageBitmap(), and XMLHttpRequest.send() accept both Blobs and Files.
Change-Id: I171f884fc4ada6180e5c605a44b27044fc03f26e
The core implementation will only support wikitext.
Flow will add its own implementation, and it can be used for any talk
page system identifiable by content model.
Bug: T91805
Change-Id: Ic69acafb24aa737536fe3a074e1958690732f0a7
The jQuery Client library is no longer mastered in MediaWiki, and is
instead a proper, published library, which is now tagged as v1.0.0.
Change-Id: Idd19d738b392a5f742fef6f98c885e8c391a5cbf
* Move configuration to /jsduck.json per standard. This way
it can be run as plain '$ jsduck' without needing a maintenance
script or custom Jenkins job. Similar to JSHint, JSCS, Grunt,
and Gem etc.
* Move --processes=0 from maintenace script into config file.
This should've been in the config file all along and serves as
workaround for https://github.com/senchalabs/jsduck/issues/525.
* Use grunt-contrib-copy instead of a symlink for resources.
For local development a symlink works fine, but for publishing
from Jenkins to doc.wikimedia.org the /docs/js/ directory needs
to be standalone. This was previously done with a manual post-build
step that added an additional rsync, but this logic should be
in the repository so that the doc entry point can be simplified
and standardised to 'npm run-script doc' for all projects.
Change-Id: Iaaaac50ee78dd9ff8f24f1ef3a3685ad51cf33b2
