* Update classes to use clientpref-1 and clientpref-0 suffix for limited width
I've limited this to the only client preference for now to reduce
risk.
* For cached HTML retain existing CSS rules, and continue saving
a cookie
* Migrate cookie if found for newly generated pages. This will be
to ensure the old cookie and new cookie are in sync (this should be
a one time operation)
Depends-On: I1e635f843ac9b2f248b1f7618134598e80291b38
Bug: T341641
Change-Id: I120f8f7114b33d2cfbd1c3c57ebf41f8b2d7fec4
Also change alignment of preview box to the left, to match
reading mode.
Bug: T322385
Bug: T322738
Bug: T323751
Change-Id: Iaee930d9ddc0c4539aad417a80a7c95d590e8099
`.mw-parser-output` needs to be can be present for both the normal
preview and the realtime preview. It appears only the normal preview
adds the "limited-width" classes.
Moving `.mw-parser-output` out of that selector seems to work.
Bug: T322337
Change-Id: I575cd50615b6bf0d1cfa73c827169f8bf17fa2d3
Making this a feature part of the feature management system is integral
to making this a toggle and will allow us to explore making this
persistent in future.
Bug: T319447
Bug: T319449
Change-Id: I80c7b892a6891094854b4154db90917b67986102
Preview width is set at 60em, but the container as a different
font-size to .vector-body and so the preview was displaying at
the wrong width.
This change removes the font-size from the grantparent and
re-sets it on the contents of #wikiPreview, ensuring that the
final size matches the actual non-editing width of the body
content.
In addition, the 'submit' action is added to the list of those
excluded from constrained width, so that the editing textarea
remains at full width even when previewing.
Bug: T312963
Change-Id: I1a1df32b00d5faecb73f8c53256342d356a9352c
This allows the editing form to be wide, but makes sure that the
preview seen will more closely match how the page will end up
after being saved.
Bug: T307725
Change-Id: Ib2085eece69fe08b7fca4aaeacef66b26cdd5f16
