Page MenuHomePhabricator

Convert Proofpage WE layout to use display flex
Closed, DeclinedPublic


This edit area has always been a tad problematic wrt sizing. With flex box supported so widely, we should use that instead.

.prp-page-container {
    width: 100%;
    display: flex;
    flex-wrap: wrap;
.prp-page-content {
    flex: 1 1 auto;
    min-width: 15em;
    display: flex;
    flex-direction: column;
.prp-page-edit-footer {
    flex: 0 1 auto;
.prp-page-edit-body {
    flex: 1 1 auto;
.prp-page-image {
    flex: 0 1 auto;

Event Timeline

TheDJ created this task.Nov 20 2018, 12:32 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 20 2018, 12:32 PM
TheDJ removed subscribers: CSS, ProofreadPage.
Tpt added a subscriber: Tpt.Nov 20 2018, 12:50 PM

Great idea! I'll be very happy to +2 a change.

Change 475222 had a related patch set uploaded (by TheDJ; owner: TheDJ):
[mediawiki/extensions/ProofreadPage@master] Editor: Use flexbox to position the elements evenly

Change 475222 merged by jenkins-bot:
[mediawiki/extensions/ProofreadPage@master] Editor: Use flexbox to position the elements evenly

TheDJ closed this task as Resolved.Nov 27 2018, 9:42 PM
TheDJ claimed this task.
TheDJ removed a project: Patch-For-Review.
TheDJ moved this task from Backlog to Done on the ProofreadPage board.
beleg_tal added a subscriber: beleg_tal.EditedDec 13 2018, 2:18 PM

@TheDJ @Tpt This appears to have broken the ability to resize the textareas. See discussion at

Shenme added a subscriber: Shenme.Dec 14 2018, 6:48 PM

Also note the very next discussion entry Other display oddities

beleg_tal reopened this task as Open.Dec 14 2018, 8:20 PM

Also note the very next discussion entry Other display oddities

All children of the div with class="prp-page-content" are set to display:flex. However, it looks like only the child with class "mw-parser-output" needs to be flex; other divs should be left untouched. This particular instance of the problem involves a child div with class "patrollink" generated by the patrolled edits feature.

Change 479765 had a related patch set uploaded (by Tpt; owner: Tpt):
[mediawiki/extensions/ProofreadPage@master] Avoids to break the styling of patrollink

Change 479849 had a related patch set uploaded (by Samwilson; owner: Samwilson):
[mediawiki/extensions/ProofreadPage@master] Change proportions of flexbox layout for header/body/footer

Oh oops, sorry @Tpt I didn't see you'd already made a patch for this. :)

Actually, we were fixing different things.

See what you think of :-)

Change 479849 merged by jenkins-bot:
[mediawiki/extensions/ProofreadPage@master] Change proportions of flexbox layout for header/body/footer

Zdzislaw added a subscriber: Zdzislaw.EditedDec 16 2018, 8:10 PM

please, fix the ability to resize manually the textarea.
It was a very useful feature!


similar request:

Change 479765 merged by jenkins-bot:
[mediawiki/extensions/ProofreadPage@master] Avoids to break the styling of patrollink

please, fix the ability to resize manually the textarea.
It was a very useful feature!

I'm working on it now. :)

TheDJ added a comment.Dec 17 2018, 7:54 PM

If you want full free-flow resizing, you'll need to turn off the display flex rules as soon as you start resizing. Textbox resizing is kind of bonkers really, it doesn't really fit into the standard rules of CSS dimensioning, as soon as you start applying it, all CSS rules regarding automatic sizing are thrown out the window.

The approach I was thinking of is to change the areas between header and body and body and footer into draggable dividers, something like this:

Does this sound like a good idea?

Hi Sam,
All ideas that make the sizes of the headers (and footers) more or less the same to what it used to be a week ago, are good! The header and footer sizes are now larger than they were, and the complete edit window does no longer fit on my screen, so that I have to scroll every time I want to make an edit, for instance italics at the lower part of the page. If you can arrange that the header and footer areas become smaller again, or make them draggable, that would be very useful to me. It would be great if I could set the size of the windows for one time, and keep them like that for all successive pages I'm working on (until I change the size of course). Many greetings, and good luck with the job. --~~~~

Zdzislaw added a comment.EditedDec 20 2018, 8:15 PM

@TheDJ, @Samwilson, @Tpt It turns out that the changes introduced here have a big impact on many problems with displaying current content in the Page ns. See, for example, here:
The problem also applies to other templates using the float parameter and many others.
eg pl ws page:
that looked like this before the changes were made:

now it displays:

(see the differences through the "show preview")

It looks like the problem may affect hundreds or thousands of pages. I would suggest withdrawal of the changes.


a similar problems on fr ws:

vs. now:



Ankry added a subscriber: Ankry.Dec 21 2018, 12:46 AM

Please revert! Huge impact on all the it.source pages with an index (basically, the ones using template VoceIndice).

See an example at this page.

Change 481196 had a related patch set uploaded (by Tpt; owner: Tpt):
[mediawiki/extensions/ProofreadPage@master] Avoids to use display: flex for now

Change 481196 merged by jenkins-bot:
[mediawiki/extensions/ProofreadPage@master] Avoids to use display: flex for now

TheDJ added a comment.Dec 21 2018, 8:21 PM

You know, this is what I hate about MediaWiki sometimes.. Everything is so convoluted, even the smallest of changes turns into a F'ing nightmare. Moving this platform forward is like dragging a dead cat through mud. ;)

Alex_brollo added a subscriber: Alex_brollo.EditedDec 23 2018, 7:12 PM

Perhaps "as dragging a spirited cat into a thick brush" is a better image....?
Nevertheless: fr:Module:Table and its clones (itwikisource: Modulo:VoceIndice; mulwikisource:Module:VoceIndice) can be fixedsimply including main container into a simple div element. A simple div element can be added too to nsPage, including the full list of unchanged Module calls. See and try to delete the including div.

Here: the "life saving div" has been added into Lua code (al the beginning of local text definition).

@Alex_brollo I appreciate the sense of humor, but the problem concerns many other templates using eg 'float:", that we do not want to place in the div.
I know the simpler way, just remove 'display: flex' from the "mw-parser-output" div on Page ns :)

@Zdzislaw How? By javascript? There's a running code anywhere?

@Alex_brollo The display:block overriding should work fine in most cases. However, I cannot predict results when display:flex is used somewhere inside the wikicode.

@TheDJ I personally like the idea of window resizing,; but only if it does not break anything working and widely used. Probably more granular styling, applied only to the edit window and not to the view window would be preferred. And lack of window resizing is a real showstopper.

CSS changes should be easy to test. However wide choice of testcases among Wikisources is not trivial.

TheDJ added a comment.Dec 24 2018, 2:11 PM

"CSS changes should be easy to test."

You think this wasn't tested ? Both @Tpt, @Samwilson and me tested the changes. Testing ain't magic fairy dust.

I know the simpler way, just remove 'display: flex' from the "mw-parser-output" div on Page ns

The entire change was already rolled back, but it's christmas time, so no deploys of code atm.

Ankry added a comment.Dec 25 2018, 9:51 AM

"CSS changes should be easy to test."

You think this wasn't tested ? Both @Tpt, @Samwilson and me tested the changes. Testing ain't magic fairy dust.

I think that tests were not adequate to the change. And I do not think that it is good if the only final result of this change will be a revert and some complaints.

Maybe Wikisource communities can help developers to prepare better/wider sets of testcases? But they unaware where and how.

Maybe we found a way to announce future changes in ProofreadPage to the communities? wikisource-l? Tech News? another mass-message? something else? (eg. T104566 was announced via wikisource-l and, I think, Wikisource communities were more ready for it)

And finally I still believe that this change will come back in some modified form. Personally, I found it useful because of better interaction between edittools and main edit window - no need to scroll the screen. (But, maybe, only in my user CSS.)

@Zdzislaw can you elaborate whether T209939#4829011 would fit your needs or not?

I know the simpler way, just remove 'display: flex' from the "mw-parser-output" div on Page ns

The entire change was already rolled back, but it's christmas time, so no deploys of code atm.

As we have already found a workaround, the delay does not seem to be a problem.

As we have already found a workaround, the delay does not seem to be a problem.

The workaround only applies to the window resizing. There are additional problems in the Page namespace caused by the new code. Templates such as {rule} and {block right} no longer function correctly, except in Preview.

Zdzislaw added a comment.EditedDec 25 2018, 8:22 PM

@Ankry T209939#4829011 looks good, and... I agree with you that this change should come back.
@TheDJ The changes discussed here were really very good in edit mode. The question is, did they bring anything in view mode (where they caused problems)? In my opinion, no.
So the question is, could they be implemented only on edit mode - if the 'prp-page-container' does not contain the 'mw-parser-output' block inside?


As we have already found a workaround, the delay does not seem to be a problem.

The workaround only applies to the window resizing. There are additional problems in the Page namespace caused by the new code. Templates such as {rule} and {block right} no longer function correctly, except in Preview.

@EncycloPetey The workaround T209939#4842647 (to be applied in MediaWiki:Common.css) fixes behaviour of templates, not window resizing. It de facto disables this change in the view mode, not touching the edit mode.

AuFCL added a subscriber: AuFCL.EditedDec 26 2018, 8:57 AM

@Zdzislaw How? By javascript? There's a running code anywhere?

Hi @Alex_brollo,

This is what I have used and so far seems to restore "normal" operation (templates, floats etc.):
var FLEXpage = document.evaluate(
      document, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null
for(let F=FLEXpage.snapshotLength-1;F>=0;F--){
    FLEXpage.snapshotItem(F).setAttribute("style",FLEXpage.snapshotItem(F).getAttribute("style")+"; display: block;")
Xover added a subscriber: Xover.Dec 26 2018, 9:11 PM

Dear developers, again the header and footer have become very very small and it is posing difficulties in proofreading.

As Balajigadesh remarks above the header and footer now have no depth at all and are impossible to see and edit. When is this ruination going to be corrected? If the whole change cannot be reversed then we need resizable boxes urgently. The editor at the moment is frankly unusable. If only I had the option of using an older version.

See T209939#4840981, T209939#4841092 above. It includes the date: "2019-01-08".

EsmeShepherd added a comment.EditedJan 4 2019, 5:09 PM

This is what I have been looking at for nearly three weeks now:

Ankry added a comment.Jan 4 2019, 5:43 PM

This is what I have been looking at for nearly three weeks now:

I do not observe this effect on any Wikisource including
Did you try to clean you browser cache (F5)? I also had seen this effect somewhere few weeks ago, but it disappeared after cleaning the cache. Probably related to some cached old CCS/JS code.

I have now cleared my browser cache and it has made no difference, even after rebooting my computer. As this problem arose at the same time as some jiggery-pokery was going on with the programming of header-footer sizes (15th December), I think blaming something at my end is rather desperate measures. Why not just enlarge the header and footer fields again? That isn't going to prevent anyone form editing.
I've been posting on Wikisource for some years now and have contributed much material, so I think you owe me a little effort. Myself, I suspect some of the programming done was a little suspect and suggest the best way forward is to remove it and return to the perfectly good editor we had before.

I too see very small (4 px height) header and footer into it.wikisource.

EsmeShepherd added a comment.EditedJan 5 2019, 10:34 AM

Ankry states he has not observed these contracted header/footers. However, Wiki is a worldwide programme that has to be functional across a wide range of platforms, not just those on a little paradise island. For this reason the programming should always be robust and straightforward.
If I remember right, this all began because someone complained his headers were too large. Can you in all honesty say that you observed this for yourself? In any case, the changes made were a downgrade on what was there before and surely your efforts should be towards improvement rather than deterioration. I note from other contributors that there have been other adverse effects.
My computer is a MacBook Pro running under OS Mohave 10.14.2 with Safari 12.0.2. It is pretty clean with very few add-ons (Microsoft Office for one) and containing for the most part text and pdf files. It's cache is now cleared.
Incidentally, when this first began, mid-December, I first observed a reduction of the header field to one line. This was still usable but not very nice. That only lasted a few days before you blotted it out altogether. I can paste into the headers/footers but as I cannot see what is in them I cannot edit if anything is amiss.

Xover added a comment.Jan 5 2019, 11:42 AM

@Ankry The disappearing header and footer is more likely than not an issue only in Safari, or possibly on Retina-resolution devices (1pt = 4px, aka @2x, or higher), based on the reports I've seen (and it's probably some wonkyness related to font size: manually removing the font-size: 13px set on the text field using the web inspector makes the text field large enough to use).

@EsmeShepherd The change back in the middle of December was a mostly technical one that afterwards has turned out to cause a lot of undesired side-effects (i.e. bugs). In particular, the disappearing text fields was not an intended change. Due to these problems the developers have (aiui) decided to reverse these changes in their entirety (changed back in the code on 21 December). However, for various (good) reasons, this cannot happen immediately: these kinds of changes are deployed to the various projects (Wikisource, Wikipedia, Commons, etc.) in batches that happen at predetermined intervals. The next such deployment is on 7–8 January and the problematic changes should be rolled back then. For the particular problem you're seeing there may be some caching type issues that prolong it even after the rollback deployment, but you should see the problems go away shortly after that time frame.

(PS. Phabricator isn't really design to be a support channel: it is, primarily, a tool the developers use to keep track of development tasks, bug reports, and so forth. In other words, it's a great place to report a problem if you have sufficient technical aptitude to break it down to causes; but you probably won't get a lot of help with figuring out what the problem is, or discussions, etc. For those you'll have better luck on-wiki somewhere like the Scriptorium or a Village Pump).

Xover added a comment.Jan 5 2019, 12:00 PM

@Tpt @TheDJ @Samwilson Looking quickly at the patch here, this is not something I imagine it's possible to do using only CSS changes. Flex box is a completely new layout model and is almost certain to require code (generated markup) changes and interact badly with other styling and scripts (including the markup produced by templates or hard coded in pages). As an example, imagine what changes would be necessary to let users switch back and forth between the two as skins. My gut feeling is that this would have to be a part of a "ProofreadPage UI 2.0" level effort in practice.

On the other hand, if you want to try tweaking this until it stops breaking stuff, it should be easy enough to make the changes a Gadget that can be enabled or disabled for testing.

So are you admitting that the damage you have done is irreversible? Then I can only hope and pray that you can and will repair it? This is what you have done (15th December):

The font size is here set to 24. Default font size 9:

As you can see the header depth is apparently zero. The footer is exactly the same. Some days prior to that the depths were reduced from two lines to one, inconvenient in itself. When you are working on repairing this damage, remember that the object is to make the editor workable under Safari (I have 12.0.2), so how it may appear under other browsers is not to the point.
I gather I'm not supposed to be speaking to you here, but having my editor suddenly made unusable was and remains devastating and my cry for help in Sciptorium has hardly been taken seriously. I remain desperate.

Xover added a comment.Jan 6 2019, 1:55 PM

@EsmeShepherd The developers are aware of the problem you are experiencing, and the plan is (aiui) to fix it (by rolling back the changes that caused it) on 7 or 8 January. At that time, or shortly after, the header and footer fields should return to the size and behaviour they had previously.

And for reference, your report at the Scriptorium was, along with the other related problems reported there, what led the developers to decide to roll back these changes.

@EsmeShepherd: That tone is not welcome here. Please read and follow if you would like to stay active in Wikimedia Phabricator. Thanks for your understanding and for keeping this a respectful place!

Thank you. I did not mean to cause any offence but I was a little intemperate, so I offer my sincere apologies. May you all have a happy new year.

Still Experiencing the lack of ability to adjust the "header" or "footer" text-area here -,_1836.djvu/133&action=edit&redlink=1.

When will an alterantive soloution be provided to restore the functionality lost in a recent update? Thanks.

I'm using Firefox, and a button to adjust the text-area briefly appears just before a scanned image loads, but vanishes once a scanned page image is loaded.

Xover added a comment.Jan 9 2019, 9:57 AM

@ShakespeareFan00 The deployment that (aiui) rolls back this change isn't yet live on enWS. See most recent Tech News and the thread "Issue with the FI Template display" on the Scriptorium. Based on the schedule given in Tech News, the deployment should hit enWS at some point today (or possibly tomorrow, depending on how they schedule the rollout).

Thanks.. Ideally, what I'd like to see is a vertical only 'resize' (if that's feasible in the CSS) as disabling the flex options allowed for resizing, but in 2 dimensions rather than only the desired "vertical" direction..

AuFCL removed a subscriber: AuFCL.Jan 9 2019, 10:20 AM
Xover added a comment.Jan 9 2019, 8:57 PM

Quick update from enWS: 1.33/wmf.12 is now live there and a quick check suggests it fixes the disappearing horizontal rule and the tiny/uneditable header and footer fields. No structured testing done, but it looks very promising.

Thank you. Header and footer in idwikisource returns to its previous state.

TheDJ closed this task as Declined.Apr 17 2019, 2:43 PM

Let's close this. I don't think that interface of Proofread can easily be made sizeable without a complete and full redesign of the user interface, especially the part regarding the header/footers.

TheDJ removed TheDJ as the assignee of this task.Apr 17 2019, 2:45 PM