WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#8092 closed defect (bug) (fixed)

Style hides content that extends further than the container

Reported by: Cimmo Owned by:
Milestone: 2.7 Priority: normal
Severity: minor Version: 2.7
Component: UI Keywords: needs-patch
Focuses: Cc:

Description

I'm the Cimy User Extra Fields author, I installed WordPress 2.7 beta2 under my small test notebook that still has 1024x768 (still lot used) and horizontal bars are gone from WordPress administrator pages.

So all plugins should now fit to even 800x600? This is the result... please put them back.

Attachments (4)

cimy_uef_1.2.0_under_WP27beta2.png (89.4 KB) - added by Cimmo 6 years ago.
Cimy User Extra Fields 1.2.0 under WordPress 2.7 beta2 and 1024x768 res
8092.diff (413 bytes) - added by westi 6 years ago.
Enable the horizontal scrollbar for wraps
WordPress trunk demo blog › Cimy User Extra Fields — WordPress.jpg (78.2 KB) - added by westi 6 years ago.
What it looks like with the patch
example-table.png (156.3 KB) - added by jick 6 years ago.
Here is an example screenshot of my table. As you can see, there are many columns. You can also see it goes off the right side of the image.

Download all attachments as: .zip

Change History (35)

@Cimmo6 years ago

Cimy User Extra Fields 1.2.0 under WordPress 2.7 beta2 and 1024x768 res

@westi6 years ago

Enable the horizontal scrollbar for wraps

@westi6 years ago

What it looks like with the patch

comment:1 @Cimmo6 years ago

Yes I tried the patch, much better, is it already committed to 2.7?

Thanks

comment:2 follow-up: @Cimmo6 years ago

Even though the horizontal bar before was always visible on the bottom, now you have to scroll till the end of the wrap div

a bit disappointing about this decision... WordPress past from not using big resolutions to needs them.

comment:3 in reply to: ↑ 2 @thee176 years ago

At some point too there is the arguement that where the menu can be shrunk expanded and on multiple resolution and the write pages 1 column or two that plugin authors should be responsable for styling the plugin to wrap better in smaller resolutions too.

comment:4 @Cimmo6 years ago

This is insane! I can optimize the field creation part, but how can I optimize the Authors and Users Extended? I put all created fields in a row and I cannot predict nor optimize for N fields.

I cannot really understand what's wrong with horizontal scrollbar, if WordPress's developers are so good to fit into 800x600 good for them, horizontal scroll bar will be hidden, but for everybody else leave it!

comment:5 @ryan6 years ago

  • Component changed from Administration to UI
  • Owner anonymous deleted

comment:6 @jick6 years ago

I have also noticed this problem on a new plugin I'm working on for 2.7. I have a table I'm displaying which requires quite a few columns. When the content in the columns is too big the table goes off the right side of the screen and you cannot scroll to get to it. Pretty annoying. I'm trying to keep the width of my table as small as possible but I'm afraid that in some cases I just can't control that. So, there is a need for a horizontal scroll bar definitely!

comment:7 follow-up: @jacobsantos6 years ago

  • Milestone 2.7 deleted
  • Priority changed from high to normal
  • Resolution set to invalid
  • Severity changed from major to minor
  • Status changed from new to closed

I swear! Sometimes developers are insane!

What? Never heard of using another line? Using JavaScript to create a new dialog? Creating another table or page for managing the other details?

Sorry. This ticket is not a problem within WordPress, but with your plugin(s). The hack in the patch is worthless.

comment:8 @jick6 years ago

  • Keywords needs-patch added
  • Milestone set to 2.7
  • Resolution invalid deleted
  • Status changed from closed to reopened

I'm not saying the patch is the right way. In fact, I think that patch is the wrong way to do it. I just think there is a need for allowing a horizontal scroll bar. In my case using JavaScript or another page is not an option. Putting the data on another page would make the table make no sense.

I think not allowing a scroll bar is actually making things less accessible. I don't see why it should be an issue. It's not like every page needs the scroll bar. Just the ones that need it. In versions prior to 2.7 there could be a horizontal scroll bar when needed. Why does that have to change for 2.7? I think that actually makes it a regression.

comment:9 @DD326 years ago

I do agree, If the page content is wider than the resolution, The page needs to allow for the scroll bar to appear, Unless the plugins UI is using floats or something else CSS/JS which is simply incompatible with it.

A scrollbar on the wrap class isnt a very good solution IMO, the browser window scrollbar should be visible - Why its not visible, i'm not sure though.

comment:10 @jacobsantos6 years ago

<table class="wide">

Change to:

<table>

comment:11 @jacobsantos6 years ago

  • Milestone 2.7 deleted
  • Resolution set to invalid
  • Status changed from reopened to closed

Class changed from "wide" to "widefat". Use "widefat" for your table instead to fix the problem.

comment:12 @jick6 years ago

Actually, I am currently using "widefat" already on my table. Still no scrollbar when the content gets too wide. There must be some styles somewhere which are different from 2.6 and lower that specify a width and don't allow scrollbars. That's the only thing that would cause it to have no scrollbars as far as I can tell. Just not sure where the said styles would be.

comment:13 @jacobsantos6 years ago

What revision of 2.7 are you using?

comment:14 @jick6 years ago

I'm actually using the very latest (2.7-beta3-9791). I just updated it again right before posting this reply.

comment:15 @jacobsantos6 years ago

Doing more research on this. If you post more of your plugin code, we might find a correlation between the plugins that I've found that don't work and why your plugin(s) isn't/aren't working.

The issue with HTML Purifier seems to be different from yours.

comment:16 @jick6 years ago

The plugin I'm currently working on is pretty much your standard widefat table. I actually copied the base for it right from the Posts Edit page. The only real difference is that mine has more columns than the one on the Posts Edit page (9 columns to be exact). The table will contain user-submitted data so I can't really control the width that much. That many columns makes the table pretty big to begin with. It only overflows without a scrollbar when I resize the window to a smaller size or lower the resolution. The resolution I usually use (and am using right now) is 1280x1024.

Does that help? I can provide more info if needed. Just let me know what you need.

comment:17 @jacobsantos6 years ago

Okay, so the issue isn't so much that the table is trying to extend further than it should. The "widefat" class is working as it should. It is just that your table is too wide that the table is naturally extending beyond the boundaries of the container.

My guess is that you are SOL, let me know how you feel about that.

comment:18 @jacobsantos6 years ago

My suggestion for you jink is to not use a table in your instance. I know you think you have to, but the table seems a little bit incoherent. If you flatten the form, you will be able to fit in any resolution and the scrollbar will appear.

comment:19 follow-up: @jick6 years ago

Well why would there not be a scrollbar? Isn't that sort of odd that the table is allowed to go outside the bounds and not have a scrollbar on the window? I mean, if there is no way to fix it I'll just live with it but that just seems like odd behavior. Usually when stuff goes outside the bounds of the window a scrollbar shows up. That's how things usually work.

Oh, just noticed your follow-up. Well, I thought when you have a lot of similar data you're suppose to show it in a table. Kind of like how Posts, Pages, etc are.

comment:20 in reply to: ↑ 19 @jacobsantos6 years ago

Replying to jick:

Well why would there not be a scrollbar? Isn't that sort of odd that the table is allowed to go outside the bounds and not have a scrollbar on the window? I mean, if there is no way to fix it I'll just live with it but that just seems like odd behavior. Usually when stuff goes outside the bounds of the window a scrollbar shows up. That's how things usually work.

Oh, just noticed your follow-up. Well, I thought when you have a lot of similar data you're suppose to show it in a table. Kind of like how Posts, Pages, etc are.

I was talking to Mark Jaquith about this issue. It seems that the overflow: hidden is needed for some reason or the administration theme starts to freak out. However, it might have been left over for legacy reasons and no longer needed.

Your problem stems from the navigation being added to the left side. It works in 2.6, because you had the extra space to display your table and it fit perfectly. It may still be fixed before 2.7 is released.

In my humble opinion, your form will look a lot better if it was flat instead of in a table. Not everything needs to be in a table. The plugins which worked perfectly in 2.7, did not use a table. When I lowered the resolution, the scroll bar appeared for them.

comment:21 @jick6 years ago

I'm actually not using the table for a form. I'm using it for actual data pulled from the db. Just like Posts, Pages, etc. Any forms I have in my plugin are in divs, etc rather than tables. But where I need to display the data from the db I use a table because it just makes sense to display it that way. Just like it makes sense to display the Posts, Pages, etc in a table.

@jick6 years ago

Here is an example screenshot of my table. As you can see, there are many columns. You can also see it goes off the right side of the image.

comment:22 @jacobsantos6 years ago

  • Keywords resolution horizontal bar removed
  • Milestone set to 2.7
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Summary changed from Removed horizontal bar killed plugins under small resolutions to Style hides content that extends further than the container

After some thought, I was wrong, this should be fixed.

comment:23 @jacobsantos6 years ago

It appears that westi's patch or setting #wpbody-content { overflow: auto; } is the solution to this problem. "Fixing" the issue at the source only breaks the entire design instead of fixing it. It also appears that I was correct in saying that the side navigation is what is causing the breakage.

Your plugin does work in higher resolution but utterly fails with lower resolutions.

Jick, the pages / posts table inline edit was optimized for 2.7 display. Most likely it will also break on smaller resolutions or it has something to limit the width of the table.

There seems little that can be done for this.

comment:24 @jick6 years ago

Oh I see. Well, hopefully we can figure out something. It would be a shame to be stuck with this problem.

comment:25 in reply to: ↑ 7 ; follow-up: @Cimmo6 years ago

Replying to jacobsantos:

I swear! Sometimes developers are insane!

yes, especially developers that removes something without a valid reasons and benefits but only few hours of non payed code for other developers


What? Never heard of using another line? Using JavaScript to create a new dialog? Creating another table or page for managing the other details?

Never heard about people is using their spare time to develop and they have to waste time because what ever reason horizontal bar shouldn't be visible at all?

Sorry. This ticket is not a problem within WordPress, but with your plugin(s).

Sorry if I'm not payed and I'm helping WordPress community to grow for free and thanks for feeling me so welcome!

comment:26 in reply to: ↑ 25 ; follow-up: @jacobsantos6 years ago

Replying to Cimmo:

Replying to jacobsantos:

I swear! Sometimes developers are insane!

yes, especially developers that removes something without a valid reasons and benefits but only few hours of non payed code for other developers


Well, my foot is often in my mouth, so you have me there. I should do something about that. However, that journey of introspection is long and difficult.

The reason is valid, without it, the design falls apart. If you remove the style that causes the problem, the content drops to below the navigation. This is an even great bug.

No, sorry, I'm not paid to work on WordPress either. I do it because, well it is fun and I enjoy it.

From my perspective, I see a bug that could hold up the release of a version and is invalid. I want this version to be released as quickly as possible without the core developers (some of which are paid to work on WordPress) wasting their time.

From my perspective and from the screenshot, what I see is someone using a table that should not be. In my experience, such a trivial matter is best resolved with the plugin developer.

I do understand the whole, "WTF? I have to change my code." I have a plugin which I have to do just that for each upgrade (more because of the crappy plugin/theme code than WordPress).

As for my being an asshole, I didn't know of any way to state what I wanted without being labeled as such. You misinterpreted my suggestions as insults when I was trying to help. Sorry, if the truth is slightly difficult to handle, I'm not kind, so I wouldn't know how to break it to people better.

comment:27 @jick6 years ago

Would it be inappropriate to set the priority of this bug higher? It does seem like quite a major issue. Even though not everyone will experience it. Still, it seems like we should get a fix for this as soon as possible. Whether that be the fix westi posted or something else. Although about westi's fix, I'm not sure I like that. If you have a long page and/or a small resolution you'll have to scroll down before you can scroll side-to-side. Seems a bit unintuitive. But, maybe that's just me...

comment:28 @jacobsantos6 years ago

Jick, That is the only solution I can think of. Anything else would get in the way of the rest of the theme.

comment:29 follow-up: @azaozz6 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [9827]) Fix base css blocks for easier horizontal scrolling, fixes #8092

comment:30 in reply to: ↑ 26 @Cimmo6 years ago

Replying to jacobsantos:

The reason is valid, without it, the design falls apart. If you remove the style that causes the problem, the content drops to below the navigation. This is an even great bug.

Well I know that breaks, but why happens? Because all the new theme was buildt around the (crap) idea of dropping horizontal bars.
If that insane idea wasn't done initially I would say we weren't here trying to patch or workaround a buggy theme.

From my perspective and from the screenshot, what I see is someone using a table that should not be. In my experience, such a trivial matter is best resolved with the plugin developer.

if you can manage to fit 50 users (rows) multiplied N fields (columns) into 800x600 in a readable way, you are kindly asked to speak! I will develop asap!

comment:31 in reply to: ↑ 29 @jick6 years ago

Replying to azaozz:

(In [9827]) Fix base css blocks for easier horizontal scrolling, fixes #8092

Great fix azozz! The horizontal scrollbar shows up when expected now. Thanks!

One little nitpick though... There doesn't seem to be any margin on the right of the page when you shrink the window down to where it needs a scrollbar. Everything on the right is butted right up next to the edge of the viewport. Not sure if that is something that could be fixed but that would make everything perfect as far as I'm concerned. It's fine though if it can't be fixed. Just having the scrollbar now is a major improvement!

Note: See TracTickets for help on using tickets.