Responsive Admin

[nacin]

The admin should be made more responsive for devices of various sizes.

[saracannon]

Initial discussion will be on the UI Blog: ​http://make.wordpress.org/ui

[azaozz]

Possibly related #14423. We will probably need to address auto column switching for the dashboard and Write/Edit screens.

[azaozz]

In [18581]:

Auto column switching (post.php only for now), see #18198

[azaozz]

Will need to select "Number of Columns: auto" from screen options to test the above patch.

[kirasong]

This works well for me in (All OSX) Safari 5.1, Chrome Dev 14.0.835.18, Chromium Trunk (15.0.860.0 - Build 97745), Firefox 6, and iPhone iOS 4.3.3

[azaozz]

In [18582]:

Auto column switching for the dashboard, see #18198

[azaozz]

Added the same method of auto column switching to the dashboard however it's not working well there. Moving postbox containers when they are empty is no good. Seems like we will have to rearrange the dashboard widgets inside the containers but that might be a bit too intrusive.

[westi]

Replying to azaozz:

Will need to select "Number of Columns: auto" from screen options to test the above patch.

I got this auto-selected on one of my local test installs (maybe I had never selected an option previously).

I ended up with a new post page with nothing apart from a post editor and no way to publish posts :(

[azaozz]

Replying to westi:

I got this auto-selected on one of my local test installs (maybe I had never selected an option previously).

Yes, the idea is to have 'auto' as default.

I ended up with a new post page with nothing apart from a post editor and no way to publish posts :(

This sounds bad... The current patch moves around the postbox containers, it doesn't care what's in them. Could you have a look in Firebug (or friends) and see where the postboxes actually are?

[azaozz]

Some more thoughts about the dashboard postbox placement: perhaps we can switch from having up to 4 columns to having one area with floated postboxes. This will automatically "push" them into 1, 2, 3 columns when the browser window is wide and back to 1 column then it's narrow.

We still can save the order of the postboxes, i.e. Right Now = 1st, Quick Press = 2nd, etc. and let the user rearrange that order. Then we can adjust the min-width and max-width with JS to force them to display in columns depending on the browser width.

[SergeyBiryukov]

Replying to westi:

I ended up with a new post page with nothing apart from a post editor and no way to publish posts :(

Same for me (see 18198.no-sidebar.png​).

Replying to azaozz:

Could you have a look in Firebug (or friends) and see where the postboxes actually are?

Firebug shows negative margin, coming from wp-admin.dev.css:

.wide-screen .inner-sidebar {
    margin-right: -870px;
    width: 100%;
}

After switching to 2 columns, the sidebar is back, though it's noticeably wider than it was in 3.2.1 (see 18198.wide-sidebar.png​).

[SergeyBiryukov]

18198.has-right-sidebar.patch​ is an attempt to fix this.

[scribu]

After switching to 2 columns, the sidebar is back, though it's noticeably wider than it was in 3.2.1

I have the opposite problem: the left column doesn't extend all the way to the sidebar anymore: narrow-column.png​.

[SergeyBiryukov]

Replying to scribu:

I have the opposite problem: the left column doesn't extend all the way to the sidebar

Turned out the sidebar is only wide right after changing the number of columns. After page reload, my screen is similar to yours, with lots of empty space.

[SergeyBiryukov]

Oh, that's only for two columns. For "auto", the sidebar is displayed with normal width during page load, and then fills the remaining space.

[scribu]

Indeed. However, switching to "auto" from post-new.php doesn't work.

[SergeyBiryukov]

18198.save-auto-columns.patch​ should fix saving "auto" columns number.

[azaozz]

In [18607]:

Improve auto column switching for post.php, see #18198

[azaozz]

In [18624]:

Disable js moving of dashboard postboxes, add all of them in the first column on 'auto', see #18198

[DrewAPicture]

At about 680px, the menu collapses and the flyout is misaligned. Clicking on any other menu header restores the full-width menu.

[azaozz]

In [18625]:

Toggle class 'responsive' on div.wrap when auto columns is toggled, see #18198

[nacin]

Replying to azaozz:

Disable js moving of dashboard postboxes...

Wait, what? Are they no longer arrangable?

[jane]

They should still be drag and drop orderable.

[azaozz]

Replying to nacin:

Sry, bad wording of the commit message. Of course they are draggable/arrangeable, disabled the auto-arranging for narrow/wide screens as it will be handled in css (see today's #wordpress-ui chat).

@DrewAPicture think this may be caused by [18621] or stale cache.

[kirasong]

Not sure how much of this is intended, but --

With this patch, when I switch to auto in the dash, it always moves to using one column, no matter the width.
When switching back to two columns, it adds the column, but all widgets in the dashboard stay in the first column until they're manually moved back to the second one.

[azaozz]

Replying to DH-Shredder:

Yes, @saracannon is working on the css atm, expect a patch soon :)

[SergeyBiryukov]

body { min-width: 950px; } from [18581] made thickbox windows too wide (see the screenshot).

[saracannon]

I've attached a diff that adds CSS3 Columns and responds with media queries when the dash is on "auto"

[scribu]

Wouldn't it be better if the blocks inside media queries were indented?

[saracannon]

still got to test for browsers other than chrome.

[GaryJ]

Replying to scribu:

Wouldn't it be better if the blocks inside media queries were indented?

+1.

Sara's patch also needs the properties alphabetical as per the ​WP CSS standards, including putting the vendor-prefixed properties before their CSS3 standard counterparts.

[saracannon]

4 columns: ​http://cl.ly/2I1O131h0F3W3r0Z2s3n
3 columns: ​http://cl.ly/2N450a1P3J11192r3q1U
2 columns: ​http://cl.ly/0X1G1k1s441C1Y050a0I
1 column: ​http://cl.ly/0V2l3t0k2L0O3l1f2W3W

I'll indent and alphabetize ;)

[ocean90]

The CSS codings standard is still a draft. See ticket:16317#comment:8 and the following ones.

[saracannon]

CSS Dashboard Responsiveness When in "Auto"

[saracannon]

Updated the Dash patch to make it work in FF by removing floats

[azaozz]

Trying to make responsive-dashboard-patch.diff play nice in all browsers but seems near impossible:

• Chrome 'forgets' to add any vertical spacing on blocks that are inside a display:inline-block container, i.e. <p> has no top and bottom margins
• Safari moves the content away from the container (looks quite weird)
• Opera breaks in many different ways depending on page width
• IE9 doesn't show columns at all...

Only FF seems to handle css3 columns + complex div with display:inline-block properly. What's even worse is that recent (not the very latest) versions of the browsers break in different ways too.

In that terms we should probably use some other styling to achieve similar results. Unfortunately that would mean we will have to use some minimal JS to help/trigger the css on page resize, hopefully not on page load.

[helenyhou]

Responsive tables, pass 1 (posts/pages)

[helenyhou]

Just attached a very rough patch that starts maybe-responsive table stuff. Looks like this, except the tiny gaps between borders is gone (fixed it after I took the screenshot): ​http://cl.ly/063j2u3Y3I0G232l1p2Z

Things that I know about:

• Checkboxes are hidden, so there's no bulk editing (and I can't seem to target just that select and button to hide)
• Highly unlikely that it works in IE. At all. Haven't fired up the VM to look yet, but I don't see people using IE at 640px or narrower (the breakpoint I went with).

I think custom added columns should work just fine, but whoever adds them has to also use CSS to add their column label, as it's a pseudo-element.

This actually already looks okay in the other admin screens with list tables (plugins, users, etc.), but they'll need some specific tweaking for labels and some other layout things. Will keep playing with it.

[scribu]

That's a really interesting layout, but I would choose bulk actions over responsive design any day.

What I'm trying to say is that we need those checkboxes somewhere. :)

[helenyhou]

I think they can be brought back with some positioning work to make sense. Will also have to work on making Bulk Edit manageable at that width. Can anybody think of a way for a select all checkbox/link to make it back in? The thead/tfoot are hidden at this width.

[scribu]

I think the "select all" checkbox is not that essential, since you likely won't be able to see all the items at a glance, like you would on a normal screen.

Worst case, we use a little bit of JavaScript to show a custom control. It doesn't work without JS anyway.

[helenyhou]

I'd also lean toward not having select all, but we can get there later, I guess :)

Already have the checkboxes back in, right now positioned under the Title label: ​http://cl.ly/2Q062s1s2p1g271u0U03

Also, forgot to mention that I made the row actions visible, instead of a hover. Thought it made more sense for what are probably touch devices.

[jane]

That's not a list anymore, though. You shouldn't have to scroll past each entry's metadata to read down the list on small screens.. that's actually making it *harder* to use. A better approach would be to not show all the columns by default at that size, so it can still be a list, with a toggle to display more or something.

[jane]

(And may I be struck with lightning as I'm agreeing with @scribu, but I agree the select all checkbox needs to be there.

[jane]

Oh, wait, I misread: scribu wants there to NOT be a select all checkbox, and I do. The world is right again. :)

[helenyhou]

Replying to jane:

That's not a list anymore, though.

Very true. I'm a little conflicted, so just kind of experimenting with this approach. It's interesting, but definitely not quickly usable.

I think it would be pretty easy to remove all but the default core columns, but it doesn't seem possible to compensate for custom columns in terms of choosing which to show and which not to. For posts and pages, this might not matter a whole lot, but sometimes for custom post types you really need that information, or at least that's been my experience. I'm also biased toward wanting more information, though. Sticking with the standard table format would keep the select all checkbox, at least :)

Maybe the toggle for excerpt mode could switch between the two views? Would that be changing the effect of the button too much? It actually kind of visually represents the change pretty well.

[DrewAPicture]

You shouldn't have to scroll past each entry's metadata to read down the list on small screens.. that's actually making it *harder* to use.

+1

[chexee]

A pass at what the Menus screen for mobile might look like. I think this would be something for next cycle, but it got me thinking. Going to start on a tablet netbook optimised screens next.

Thoughts?

​http://chx.mx//ao/w103mqp340wg0.png
​http://chx.mx//13/pr6j4xmaas8oo.png

[chexee]

Replying to helenyhou:

Replying to jane:
I think it would be pretty easy to remove all but the default core columns, but it doesn't seem possible to compensate for custom columns in terms of choosing which to show and which not to. For posts and pages, this might not matter a whole lot, but sometimes for custom post types you really need that information, or at least that's been my experience. I'm also biased toward wanting more information, though. Sticking with the standard table format would keep the select all checkbox, at least :)

Would it be possible to make each "row" expandable (similar to how metaboxes work) where, by default they would only show only the title cell, but when tapped or clicked on they would expand below to show the rest of the meta data and actions?

[sabreuse]

Replying to chexee:

Replying to helenyhou:

Replying to jane:
I think it would be pretty easy to remove all but the default core columns, but it doesn't seem possible to compensate for custom columns in terms of choosing which to show and which not to. For posts and pages, this might not matter a whole lot, but sometimes for custom post types you really need that information, or at least that's been my experience. I'm also biased toward wanting more information, though. Sticking with the standard table format would keep the select all checkbox, at least :)

Would it be possible to make each "row" expandable (similar to how metaboxes work) where, by default they would only show only the title cell, but when tapped or clicked on they would expand below to show the rest of the meta data and actions?

+1 to this -- initial presentation on a small screen needs to have pretty compact rows, just big enough to be a good tap target; the larger (chunks? pods? sections?) don't look obviously enough like a list at all on a phone-sized screen and multiple selections will take a ton of scrolling.

And yes to select all!

[helenyhou]

Replying to chexee:

Would it be possible to make each "row" expandable (similar to how metaboxes work) where, by default they would only show only the title cell, but when tapped or clicked on they would expand below to show the rest of the meta data and actions?

Not sure; that's definitely a way better idea, but would have to have some kind of JS added to control that. I'll play with removing columns too. I agree that the initial look should be way more compact, but if we can find a way to include an expanded view, that would be awesome.

[azaozz]

Replying to helenyhou:
Replying to chexee:

Not sure; that's definitely a way better idea, but would have to have some kind of JS added to control that.

Don't worry about the JS.

Usually the best way to control this kind of switching is by adding and removing a class on a parent element. If you get it to work that way, the JS would be one line toggle (you can test that in Firebug and friends by adding/removing the class by hand).

If you think we need something more complicated, ping me in #wordpress-dev and we will put it together fast :)

[chexee]

Added larger, touch-friendly input boxes and submit buttons:

​http://chx.mx//kc/b3vgofhog4cc4.png

[helenyhou]

Here's a run of just the title with an expanded state, using azaozz's advice to just add a class on the tr. Needs some kind of indicator that you can expand/collapse. The table head/foot is kind of misleading/confusing when expanded, since it just says Title. Select all checkbox is back though, hooray!

Default: ​http://cl.ly/1t3b1N463b452l322N2j
Expanded: ​http://cl.ly/3h2J1p3I1c35011p2I3O

[helenyhou]

Replying to chexee:

Added larger, touch-friendly input boxes and submit buttons:

​http://chx.mx//kc/b3vgofhog4cc4.png

Cooooool. The top accordion could probably use visible arrows to indicate expand/collapse, like the individual menu items have.

[sabreuse]

Replying to chexee:

Added larger, touch-friendly input boxes and submit buttons:

​http://chx.mx//kc/b3vgofhog4cc4.png

Love the big targets! I'm noticing that the labels of menu items/tabs are cut off on both the left and right - could we enforce showing the beginning of each label (and optionally cut off the end of the label) so we have something more like "Another M..., Menu 1, Sample M..." instead of "nother Menu, Menu 1, Sample Men" or wherever it happens to truncate?

[chexee]

Replying to sabreuse:

Love the big targets! I'm noticing that the labels of menu items/tabs are cut off on both the left and right - could we enforce showing the beginning of each label (and optionally cut off the end of the label) so we have something more like "Another M..., Menu 1, Sample M..." instead of "nother Menu, Menu 1, Sample Men" or wherever it happens to truncate?

That could get messy if someone has a lot of menus (even 5 would make the tabs tiny) or has similar pre-fixed menus. I'm not in love with the scrolling sidebar either, though :/

Replying to helenyhou:

Cooooool. The top accordion could probably use visible arrows to indicate expand/collapse, like the individual menu items have.

They have them on hover, which is totally unhelpful for a touch device :P Whoo, I'll make them persistent. Cool!

[sabreuse]

Replying to helenyhou:

Needs some kind of indicator that you can expand/collapse.

I'd suggest something like the little gray down-arrow on accordeons, but (same issue as with Chexee's menu accordeons) we'd need to make it persistent since we can't assume hover, at least on mobile.

The table head/foot is kind of misleading/confusing when expanded, since it just says Title.

Title isn't ideal for either collapsed or expanded - it's not just labeling that one field any more, but the whole page/post/media item/whatever. I'm not sure what to call it more generically, though.

[sabreuse]

Replying to chexee:

That could get messy if someone has a lot of menus (even 5 would make the tabs tiny) or has similar pre-fixed menus. I'm not in love with the scrolling sidebar either, though :/

Yeah, I don't think getting rid of the scrolling would happen with any decent number of tabs. I was thinking more of the readability of the labels themselves: forcing them to start with the beginning of the label text even if they fade off at the end feels like it should make for better comprehensibility.

[helenyhou]

Replying to sabreuse:

I'd suggest something like the little gray down-arrow on accordeons

For sure. I can go digging for the image and see about applying it. I wonder if maybe clicking/tapping anywhere on the row that's not a link/checkbox should make it toggle? The arrow might be kind of a small target, but having it toggle anywhere could be really unexpected behavior.

Title isn't ideal for either collapsed or expanded - it's not just labeling that one field any more, but the whole page/post/media item/whatever. I'm not sure what to call it more generically, though.

Could probably change the text with JS to the name of the screen we're on. The tables get a class based on the screen, so it'd be easy enough to determine what the name should be. Sometimes they are sortable, though, so changing the name might still be weird. Don't want to lose sort.

[sabreuse]

Replying to helenyhou:

For sure. I can go digging for the image and see about applying it.

wp-includes/images/toggle-arrow.png, looks like

I wonder if maybe clicking/tapping anywhere on the row that's not a link/checkbox should make it toggle? The arrow might be kind of a small target, but having it toggle anywhere could be really unexpected behavior.

I wouldn't go so far as the full row. It's not a button, and it would be weird for it to act like one - but the arrow by itself is way too small by itself. IIRC the recommended target sizes for touch are generally 30-40px - so I'd vote for making the last section of each row clickable, but not the whole thing.

[azaozz]

Replying to chexee:
Replying to helenyhou:

All looking very good. Starting to think we may be able to add some phone browsers support in 3.3 and refine it in 3.4.

@helenyhou we probably can try having something similar to how the widgets are opened/closed, i.e. a large enough div that is floated right with the arrow as a centered background. The html for it would look something like

<div class="toggle-whatever"><br /></div>

(the filler <br /> gives it shape in all browsers).

The JS for the above example would be:

jQuery('.toggle-whatever').click( function(){
  jQuery(this).parents('tr').toggleCalss('my-toggle');
});

You can paste that in the (Firebug) console and run it while testing too.

[helenyhou]

It works! ​http://cl.ly/3F1L0N3z1M0F0Z3t0X3W

I did this one with the toggle under the checkbox, just because it was the simplest for proof of concept. It's kind of a small target right there (30px by 20px), but it really could be moved anywhere, maybe the end of each line with some padding added to prevent collision with titles. Not sure what the right way of adding this in is, though. I ended up adding it to the class method for testing.

By the way, if you resize a Webkit browser after page load, it does terrible things to the table elements that switch to display:block. Since this is really targeting mobile, I don't see it as a huge issue, but you might experience it on your full-size machines :)

[DrewAPicture]

This may be a candidate for another ticket another time, but how will the (new flyouts) menu be treated when the dashboard is resized with this new responsive admin? Will the hover still exist but just be moot in terms of touch screens? Will the menus expand down automatically at a certain screen width? Or maybe a tap to open animation without a page refresh? My motivation for asking is this: If the purpose of the flyouts was to make any menu accessible via one-click access, how will you match that for devices that don't inherently support hover events?

Something to think about. I've posted the same on koop's ticket (#18382).

[saracannon]

We're moving all small-screen discussion and patches to #18655 - as it will be for future-release. :]

[helenyhou]

​18198.list-tables-max-width.diff adds max-width to #posts-filter, .widefat and .tablenav to keep it from getting too wide to read on large screens. Number is kind of arbitrary, open to other suggestions.

[helenyhou]

Limit max width of widefat list tables, semi-arbitrarily to 2000px

[azaozz]

In [18667]:

Auto-column switching for the dashboard (js based), see #18198

[saracannon]

responsive category pages

[saracannon]

initial pass: responsive category pages.. converts to one col after 768px

still needs testing on ipad/tablets.

​http://cl.ly/0a2T0k192N3c3x2F3k1s

​http://cl.ly/0m0e0C3z2V2a0o2c2730

[azaozz]

In [18670]:

Limit max width of .widefat list tables, props helenyhou, see #18198

[azaozz]

Typo in the commit message, meant to reference this ticket.

Changeset [18669] by azaozz
Responsive tag and category pages, props saracannon, see #18198

[helenyhou]

CSS for theme screens, also limits plugin cloud tag width

[helenyhou]

Modifications to the two list-table classes for theme screens

[helenyhou]

JS to make each row of div's equal height on load/resize, from ​http://stephenakins.blogspot.com/2011/01/uniform-div-heights-for-liquid-css-p.html

[helenyhou]

First pass at theme screens (available and install). Feedback on width (they are fixed) and the whole border/whitespace/grid thing welcome.

• Big screen: ​http://cl.ly/3N1G412d2s2L0H1b3W2A
• Laptop-esque screen: ​http://cl.ly/1W1N0v0h1J0w1Q3s3V3V
• Tablet-esque screen: ​http://cl.ly/1M1a0n2h0m2v1f0D2R41

​18198.themes-css.diff has the CSS for the theme screens and also limits the width of the plugin tag cloud to wrap that up. I think it also takes out the .widefat max-width @saracannon had put in the responsive stuff because it was breaking things for me.

​18198.class-wp-theme-install-list-table.diff makes the two theme list tables... not tables. Both are also now 24 per page, just as a number that's more likely to come out even.

​18198.theme-row-height.js is a piece of JS that makes each row of divs adjust to the height of the tallest one on load and resize. Not a big JS person, this could use some review.

[azaozz]

In [18671]:

Remove max-width for .widefat, see #18198

[nacin]

Bumping up to 36 rather than down to 24 should result in the same opportunities. But it's also been a long time since I took fifth grade math.

[helenyhou]

Sure, I'm always for more information per-screen. 24 was definitely an arbitrary pick - you core people are welcome to change it whatever you think is best :)

Edit: I just realized you meant for the search screens. I forgot it was 30 before - installed themes screen was at 15, which is where I was going from.

[ptahdunbar]

Replying to azaozz:

In [18667]:

Auto-column switching for the dashboard (js based), see #18198

FYI: This changeset introduced new bug #18665 (Admin Dashbord Widgets columns are 'stuck').

[helenyhou]

Tried it out without borders to eliminate the need for the JS piece: ​http://cl.ly/2w1P1m1Y0G0B0E3C2p2x. Need some feedback on whether or not it's legible/scannable/etc.

[helenyhou]

No borders, no JS

[azaozz]

In [18673]:

Responsive themes screen, props helenyhou, see #18198

[andrewryno]

Uploaded screenshot with 2 of the issues I'm seeing. Flyouts don't look right and then the sub-menu of the active item doesn't hide itself.

[helenyhou]

I'm seeing the same thing, and also having hover problems with the flyouts. Should this go on #18382?

[andrewryno]

True, forgot about that ticket. I put it in here only because I noticed it once the responsive admin stuff went it. Looks fine on my old trunk install from before all the responsive stuff.

[azaozz]

Replying to helenyhou:

...Should this go on #18382?

Yes, actually ​reported that couple of weeks ago. Thinking it needs a css fix, no point in running js on page load to fix the css there.

[helenyhou]

Fix for theme information (install thickbox)

[helenyhou]

Attached a patch to fix the theme information display in the install thickbox, as pointed out by Ipstenu. Body still has a min-width from elsewhere, which is messing with all thickboxes, so it still scrolls horizontally.

[Viper007Bond]

I assume the max-width on the lists is a result of this ticket? It's rather lame having whitespace to the right of my list of comments, posts, etc.

Screenshot below.

[azaozz]

Replying to Viper007Bond:

I'm not sure what's worse: having white space on the right or having super long (2000px+) rows that make you turn your head to see the right side.

As far as I've seen nobody uses the browser maximized on a 27"/32"/46" screens, so this may be a secondary consideration.

[Viper007Bond]

Replying to azaozz:

As far as I've seen nobody uses the browser maximized on a 27"/32"/46" screens, so this may be a secondary consideration.

I do. :( For at least 5 years, I used WordPress at 1920x1200 (24") and have been using WordPress at 2560x1600 (30") since early this year. I've never had a single problem. Heck, I still run WordPress maximized at 1920x1080 on my 13" laptop.

I don't understand how (or why) people don't use things like browsers in anything but maximized mode. Perhaps it's a Mac thing. I can't remember the last time I had an application that wasn't maximized.

[Viper007Bond]

According to Twitter, I am weird for running things in fullscreen. Then again, responses were from Mac users. Hmm.

[ryan]

I too run fullscreen/maximized. Xtra-wide is how I ride. That said, I don't really have a max width preference for the list table pages.

[wpmuguru]

I run one of my browsers fullscreen because I'm using firebug, etc. I use multiple desktops/sessions and one desktop has just that browser. I don't object to a bit of whitespace on the right.

[azaozz]

The (not that many) people I've seen that work on large 2000px+ screens usually have the screen split in two "zones" left/right and do stuff in more than one app at the same time. Only seen designers/artists that have Photoshop or similar in full screen mode (and even a second screen for all the palettes).

[nacin]

Replying to azaozz:

Replying to Viper007Bond:

I'm not sure what's worse: having white space on the right or having super long (2000px+) rows that make you turn your head to see the right side.

As far as I've seen nobody uses the browser maximized on a 27"/32"/46" screens, so this may be a secondary consideration.

I don't get it. If no one uses it this way, then why the max width? Now you *can't* use it this way.

Say someone manages a CPT all day long. 27" screen, long titles, full descriptions, a dozen columns. Designed exactly for a big screen.

We shouldn't be putting a max width on anything. We should make some screens (like widgets) take full advantage of it. And leave the rest alone.

[helenyhou]

Replying to nacin:

Say someone manages a CPT all day long. 27" screen, long titles, full descriptions, a dozen columns. Designed exactly for a big screen.

That's a good point, and so's Viper007Bond's on Twitter that a user could control it if it really bothers them. I'll work on an alternative that just deals with how awful the import screen is at full width in a bit.

[azaozz]

Replying to nacin:

... We shouldn't be putting a max width on anything.

That's not going to work on most screens. Reading very long lines is hard and tiring. And is ergonomically wrong.

On the other hand I agree we shouldn't needlessly constrain width if it can be made useful. Perhaps we should try to look at individual "reading areas", for example the Comment column on the comments screen and make sure they don't exceed 800-900px. Also all these lengths should be in em IMHO.

As an experiment: open Firebug (or friends) right now, find div#content and remove the width: 58em from it. Now try reading/responding :)

[azaozz]

In [18693]:

Add missing var in postbox.js, see #18198

[azaozz]

In [18694]:

The rest of add missing var in postbox.js, see #18198

[SergeyBiryukov]

Dashboard has whitespace on the right in 1440x900 (see the screenshot).

[helenyhou]

Attaching a patch to make the import screen not exceed necessary width on wide screens, as it does not change too often. Screenshot: ​http://cl.ly/0I3a372Y1j3P3Z0t1u3s

[helenyhou]

Import screen list table

[dd32]

See also #18670 - Add new Link screen defaults to 1 column, however only shows the first columns widgets (2nd column, containing the publish widget, remaing hidden until the 1/2/auto options are selected)

[azaozz]

In [18704]:

Importers and Install themes thickbox fixes, props helenyhou, see #18198

[azaozz]

In [18736]:

Responsive admin improvements for the dashboard, new/write screens and links screens, see #18198

[sabreuse]

Fix for tab and category sidebars in post-new

[sabreuse]

On the post-new screen, expanding the "most used tags" or "add a new category" options causes ugly overflow. Screenshot here: ​http://cl.ly/2X0G403q3A3A280f1F30

The attached patch fixes this, while still respecting responsiveness when shrinking to 1 column layout.

[azaozz]

Replying to sabreuse:

On the post-new screen, expanding the tab or category options causes ugly overflow. Screenshot here: ​http://cl.ly/2X0G403q3A3A280f1F30

This looks like a bug. These screens (Add / Edit Post, Add /Edit Link) have three states:

• narrow (right postboxes are under the editor)
• normal (right postboxes on the right, width: 280px)
• wide (right postboxes on the right, width: auto, min and max width so they are a little "elastic" and fill some of the white space).

From the screenshot it seems some css or js has not loaded properly. Perhaps try resetting the browser.

[Ipstenu]

I had this problem too, and that was my first action after I saw it (even did the Chrome hard-flush of all cached files, and unrelated, rebooted the computer because XP sucks). I can repro it on a clean site/theme too.

[azaozz]

In [18743]:

Fix inconsistent css handling of .wide-screen, see #18198

[azaozz]

Yes, it was a bug in the css, [18743] should fix it.

[sabreuse]

Per ui meetup discussion, remove max-width on tables (updated)

[sabreuse]

Missed a max-width in the first patch I uploaded, replaced with edited version

[azaozz]

In [18801]:

Remove max-width from list tables. Better to limit the width on individual fields or areas where readability is impacted, see #18198

Props sabreuse. Sry, forgot to include in the commit message.

[azaozz]

Fixed for now, more responsive in 3.4.

[WraithKenny]

semi-related #17959

[azaozz]

In [20942]:

Remove leftover JS global, see #18198