[Feature] drop-label disappears when max file limit reached - optionally keep displayed?

[morrow95]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe.

New user. When the max file limit is reached the drop label disappears. When that happens there is a considerable 'gap' of empty space before the images show. This 'gap' seems to be a combination of the drop label and list scroller elements - neither of which have any content, but take up margin/padding to create this gap.

I don't know if this matters, but I am using the grid style css changes so files are not 'stacked' and instead in a grid. As far as I am aware that is pure css and nothing changes internally with the js because I made those css changes so there should be no difference.

Describe the solution you'd like

I see two solutions here.

1 - The drop label does not disappear when the max file limit is reached. Yes, your drop label will still show, but it would eliminate this 'gap' before the files list shows. In the scenario I am talking about I have a use case where only 1 image can be uploaded. I preload that image when the page shows... there is no drop label and a gap before the image shows. From a user perspective, it might be more intuitive if the drop label still showed, but we were able to change the text of the drop label and/or disable it. It would be easier for the user to understand what is going on then. If they remove the image the drop label text changes back and it is no longer disabled.

2 - This is sort of in combination with the above, but it would be nice if a new class was added alongside '.filepond--root' when max files are reached. This way we could manipulate css based on whether or not max files was reached. If you were to go this route then there is no need to automatically remove/hide the drop label... there could just be some css on '.filepond--root.filepond--maxfiles' for example that hides the drop label if we wanted to do that. We could also disable the filepond--drop-label link inside if we wanted to with css. What this would require is a new property such as 'labelIdleMax' where we could set a new string that shows in the drop label when max file limit is reached.

As a coder myself... I think option 2 would be the best route to go here. You could easily do this and still have the default behavior like nothing ever happened for people who would be upgrading... .just have some new css that hides the drop label when the limit is reached. Users could optionally comment that css out to leave the drop label showing and then set the optional 'labelIdleMax' and so on as mentioned above.

Describe alternatives you've considered

see above

[morrow95]

Playing around with this more and I see opacity:0 and visibility:hidden are placed on the drop label when max files is shown. So yes, I can override those.

With that said, you are applying transform and height css properties on elements in the js depending on things that happen and a lot of the elements are positioned absolute too which makes changing things with css impossible. I would think things like the drop label and previews would be best all relative that way the whole filepond takes up the space it needs automatically without any of these 'height' and 'transform' properties needed. The other stuff of course like close buttons and so forth would have to be positioned absolute, but it would not affect the default layout and at the same time make changing the layout with css trivial.

Seems like the only option is if you create an option to 'always show' the drop label. And, it would be nice to have a 'labelIdleMax' option to go with that which replaces the label text when max limit is hit.

[morrow95]

I'm including some images of what I am talking about :

Max files is set to two. First image is me preloading a single image. Second image is me adding a second image - where I reach the max files and the drop label disappears which leaves me with this empty space showing.

What I would like to do, at the minimum, is show the drop label at all times to avoid this from happening. This can not be accomplished by overriding the css for opacity and visibility that you set because you are also calculating height and transform properties in your js code which screws up the layout (see image 3 that shows me overriding the css).

[rikschennink]

Hm, It was never intended to be used like, showing the items below outside the drop area. The drop label hides to indicate that no more items can be added.

See this demo on the landing page on how it's supposed to look: https://pqina.nl/filepond/#multi-file-demo

[morrow95]

@rikschennink I literally just followed the docs for doing the grid style layout (https://pqina.nl/filepond/docs/api/style/. I wouldn't necessarily have an issue with the drop label hiding if the js correctly positioned everything so there wasn't a huge gap in its place (See picture 2 I posted above). Going from picture 1 to picture 2 is what happens when the max limit is reached - the gap is my main problem and I can't correct it on my own with css because you are doing calculations on things in js then applying height and transform properties in css.

[morrow95]

@rikschennink Okay, I see what happened now. I was putting a transparent background on .filepond--panel-root so the gap is actually the padding and now transparent part showing before the images do. When I put a background color back it doesn't look bad.

With that said, I am just now noticing that there is no 'max file' warning showing at all like the demo you linked does. Any ideas on why that might be? If I have max set to two and select more than two nothing happens at all (nothing showing in the console either). If I select 2 or less then images are added in my preview.

[rikschennink]

You can listen to onwarning and place the warning somewhere you like. It’s not a default feature.

[morrow95]

@rikschennink Okay, kind of confusing because you show it in the demo, but nothing is listed in the demo's code either regarding it. Thanks.

[rikschennink]

Yes, could definitely be better documented. Kind regards, Rik | PQINA PQINA BV Sint Willibrordusstraat 16 5502 BH Veldhoven The Netherlands

…

On 30 Sep 2024 at 17:01 +0200, morrow95 ***@***.***>, wrote: @rikschennink Okay, kind of confusing because you show it in the demo, but nothing is listed in the demo's code either regarding it. Thanks. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>