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

https://gerrit.wikimedia.org/r/475222

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

https://gerrit.wikimedia.org/r/475222

@TheDJ @Tpt This appears to have broken the ability to resize the textareas. See discussion at https://en.wikisource.org/wiki/Wikisource:Scriptorium#Editing_window_woes_(again)

Also note the very next discussion entry Other display oddities

In T209939#4824491, @Shenme wrote:

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

https://gerrit.wikimedia.org/r/479765

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

https://gerrit.wikimedia.org/r/479849

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 https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ProofreadPage/+/479849/ :-)

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

https://gerrit.wikimedia.org/r/479849

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

Z.

similar request: https://fr.wikisource.org/wiki/Wikisource:Scriptorium#Espace_Page_:_dimensionnement_de_la_zone_textearea

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

https://gerrit.wikimedia.org/r/479765

In T209939#4826671, @Zdzislaw wrote:

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

I'm working on it now. :)

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. --~~~~

@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:
https://en.wikisource.org/wiki/Wikisource:Scriptorium#Issue_with_the_FI_Template_display.
The problem also applies to other templates using the float parameter and many others.
eg pl ws page:
https://pl.wikisource.org/wiki/Strona:Henryk_Ibsen_-_Wyb%C3%B3r_dramat%C3%B3w.djvu/792
that looked like this before the changes were made:

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

Z.

a similar problems on fr ws:
https://fr.wikisource.org/wiki/Page:Satyre_Menippee.djvu/345

+ https://fr.wikisource.org/wiki/Wikisource:Scriptorium/D%C3%A9cembre_2018#Alignement_des_tableaux

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

https://gerrit.wikimedia.org/r/481196

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

https://gerrit.wikimedia.org/r/481196

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. ;)

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 https://wikisource.org/wiki/Page:Teatro_-_Salvatore_di_Giacomo.djvu/457 and try to delete the including div.

Here: https://it.wikisource.org/wiki/Modulo:VoceIndice 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 :)
Z.

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

@Alex_brollo ad hoc:
https://pl.wikisource.org/w/index.php?title=MediaWiki:Common.css&diff=prev&oldid=2155343

Z.

@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.

"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.

In T209939#4842997, @TheDJ wrote:

"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.

In T209939#4843264, @Ankry wrote:

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.

@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?

Z.

In T209939#4843383, @EncycloPetey wrote:

In T209939#4843264, @Ankry wrote:

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.

In T209939#4842622, @Alex_brollo wrote:

@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(
      "//div[contains(@class,'mw-parser-output')]",
      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;")
}

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".

In T209939#4855580, @EsmeShepherd wrote:

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

I do not observe this effect on any Wikisource including en.ws.
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.

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.

@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).

@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):

@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 https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette 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 -https://en.wikisource.org/w/index.php?title=Page:Arch%C3%A6ologia_Americana%E2%80%94volume_2,_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.

@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..

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.