vicb/bsmSelect

bsmSelect(sortable) + overflow-y:scroll + firefox: list items disappearing when moving

Opened this issue · 12 comments

I'm using normalize.css stylesheet, through html5boilerplate. The problem arise in Firefox (tested in Iceweasel 4.0.1), but at least no in Chrome and Opera.

In normalize.css the following rule is defined: html { overflow-y: scroll }. In firefox, it produces that when list items are moved, their top CSS property gets very low values (-700px, for example), making them appear on the top of the page and making them disappear from user visual field.

To solve this, you can define overflow-y: auto in .bsmList.

vicb commented

what do you mean by 'move' (i.e. when exactly the issue occurs)
do you have an example available online ?

I mean, when you start dragging a list item it then appears at the top of the window (so it disappears from bsmSelect visual module). I look at Firefox and what it happens is than the top CSS property gets too low values (but only in Firefox). Finally I realized that on the root of the issue there was the overflow-y: scroll property defined in normalize.css. If I remove this property, everything works all right.

I haven't any online example. This is for a backend. If you give me some time, I'll try to send to you a demo (I'll try today), but I think that setting html { overflow-y: scroll} to any page with bsmSelect will have that issue in firefox.

vicb commented

Ok, I see.
I asked the question to see if the issue is relative to jQueryUI or not. If it is then we should report the defect there also (and fix it in bsmSelect anyway).
No rush for the demo, I'll probably not be able to check this before eow.

Hey, I think there is no need of the demo. I just tried it in bsmSelect demo page and the same problem arised. Just add a rule overflow-y: scroll; in html element with firebug and here you have...

Thank you!

vicb commented

The example on the jQuery UI page is not affected because the container has overflow:auto (same as the fix you describe).

Would you mind submitting a PR ?
You need to adjust the css, readme.md (contributors), history.md & js (bump version, describe the update). Please include "(fix #21)" in the commit message

Thanks,
Victor

There is a problem with this solution.

  • If I apply overflow: auto to .bsmList or better to .bsmListSortable then ugly scroll bars (x and y axis) appear surrounding.
  • If I apply overflow: auto to .bsmContainer then only x axis scroll bar appears.
  • It's easy to make disappear x axis scroll bar in both cases, removing width: 100% in .bsmListItem. I think this rule should be replaced with width: auto, otherwise its 1px border forces the scroll bar to appear. An automatic width should work as desired, as li is a block element.

Ok, as you see, applying overflow: auto to .bsmContainer and changing width: 100% with width: auto in .bsmListItem makes everything looks great... but until you begin sorting items. When you do so, if you go beyond .bsmContainer limits then scroll bar appears again, instead of freely moving around the page.

In the example in jQuery UI page the problem is not immediately visible because they have a very big container, but they have the same problem if you move the items beyond the big container.

We should make better this solution or otherwise live with the ugly scroll bars, at least in Firefox. What would you prefer?

vicb commented

So what about using overflow: visible; ?
Switching to an auto width would also be more correct even if not required then.

vicb commented

And I forgot to thank you for your accurate analysis !

No, using overflow: visible doesn't fix the issue. It's only working with overflow: auto, don't know why.

No problem, thanks to you to work in this plugin.

vicb commented

Ok so let's go for auto then. Could you apply the changes programatically in the sortable plugin rather than having something "hardcoded" in the css ?

Are you sure? I mean, this issue is related purely with CSS, I think it would be cleaner to implement in CSS so anybody can see quickly.

On the other hand, we can go on with a generic rule or with a hack to firefox (I have seen this issue in firefox, but no in chrome or opera, no idea about ie). If we use a hack, then the scroll bar problems won't appear in browsers different than firefox, but the code won't be standard compliant. As you like.... :)

vicb commented

The thing is that you won't see the issue when you are not using the sortable plugin... but the extra css won't hurt when you do not use the scrollable plugin (I am thinking loud here).
So ok to do as you want and submit your PR the way you think is best (yeah I don't like hacking css either, but adding a comment might be worth).