Commit graph

5 commits

Author SHA1 Message Date
Jon Robson f31f0bbf50 [Cleanup] Address FIXMES relating to cached HTML
Change-Id: I6f5e97dde1f774e741a4236d1f6b49ad146cc236
2022-11-15 23:23:56 +00:00
TheresNoTime 559a71638e
skinStyles: Move mw-parser-output out of more specific selector
`.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
2022-11-04 09:43:45 +00:00
Jon Robson 614da1dc5e Features: Make max width a feature
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
2022-10-24 13:12:06 -07:00
Sam Wilson c2e7595809 Set width of preview to match reading
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
2022-10-18 13:26:31 +08:00
Sam Wilson 0ebae6c4ef In max-width mode, constrain the width of page previews
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
2022-05-30 11:52:59 +08:00