The id #mw-content-text, as I understand it, is normally attached to the .mw-content-ltr/rtl div so that the element directly holding the content is accessible through javascript. However, during preview, the ID is instead attached to a different element, which has #wikiPreview as a child element, which then has an ID-less (and thus inaccessible) .mw-content-ltr/rtl div holding the content. #mw-content-text should consistently be the content-holding div.
Version: 1.19
Severity: normal
alexsm333 wrote:
Related issue (I think):
API action=parse does not return div.mw-content-ltr
so all "ajax preview" userscripts miss some global CSS,
one example is ".mw-content-ltr .magnify {float: right}"
for thumb images.
Looking at the preview page now, it has all the correct CSS rules applies. It inherits a direction from a dir="…" element, and it is presented within an element that has mw-content-ltr/rtl classes applied.
Is is still true today that this element does not have an ID of #mw-content-text. That element is elsewhere on the page, and has to be for compatibility with other code. It cannot be the same element because when previewing an edit, #mw-content-text is for the edit form (which is in your user language), whereas the .mw-content-ltr#wikiPreview element is for the page content (which is in the content language).
These unfortunately cannot be the same.
Focussing on the original use case, I believe you want to find the parts of the wiki content no matter whether it is a preview, oldid, or page view. Is that right? For that use case, we have mw.hook('wikipage.content') whicih will run for page views, previews, Live Preview, post-edit VisualEditor, Flow, Translate, Upload form, etc. anywhere where wikitext or templates may render.
See JS docs.