Themes 2.0 overflow problems

Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.

This document examines the overflow:hidden - fixed width problem currently plaguing several areas of Moodle 2.0 (as of October 26, 2010)

http://tracker.moodle.org/browse/MDL-24895 Has been created to track implementation of a solution

The problem

Content that is too wide for the main content area is not displayed correctly is obscured behind the side blocks or off-screen, and the browser doesn't scroll horizontally.

To see it, shrink your browser window and look at:

1. http://moodle.org/mod/forum/discuss.php?d=32796 (large image: 15.748px × 3.893px)
2. http://moodle.org/mod/forum/discuss.php?d=114746 (large table) --Frank Ralf 10:44, 27 October 2010 (UTC)

It is caused by oversized, unwrappable content:

1. Large images or other media of one form or another.
2. Tables, any table that has numerous columns and/or large content in columns.
   1. Tabulated data
   2. Tables for internal layout (like the forum)
3. Unwrappable content
   1. This is normally always user-entered text or images.
   2. Different browsers handle things differently.

The technical description

The cause is a combination of the fixed width that gets set on the core layout XHTML, and the overflow:hidden setting that is required by the layout.

The layout used in the base theme within Moodle is based on Matthew James Taylor's Holy grail layout which is an excellent layout, however (and it does state this in the description of the layout) wide content is a known problem.

This problem starts on the very first div that contains content within the body *<div id="page-content">....</div>* which has the following style:

#page-content {
    clear:both;
    float:left;
    overflow:hidden;
    position:relative;
    width:100%;
    min-width:900px;
}

Setting the width to 100% instantly boxes the displayable area to just the browsers internal display width, and then overflow:hidden ensures that any overflow is not visible.

This is required because the premise of this layout is to move everything out of the viewport and then move things back into the correct position and in doing this it goes as far as expanding content divs out to 200% width.

Because of this if we remove the width 100% and/or overflow hidden everything breaks because the page will ALWAYS expand beyond the browsers displayable area even if the content is easily displayed.

As far as I can see there is no way to avoid this problem while using this layout.

On the other hand there are very good reasons for using this layout:

• it is cross browser,
• columns are orderd 2,1,3 which is good for accessibility and search engine optimisation, and
• in EVERY other respect it works well

Proposed solution 1 - Additional wrapper DIV

A couple of days ago I sat down with Martin and explained this to him and we looked into it and came up with the following three part solution:

1. Wrap format_text output within a div with a class that allows us to manage overflow. The themes can then turn on overflow:auto for these areas to make sure that user content wraps correctly (eg forum post content).
2. Convert places that use tables for layout to divs (eg forum posts) so that they wrap cleanly. Without this the large user content causes the table cells to grow too large, causing wrapping issues.
3. Locate places where tables are likely to require horizontal scrolling and wrap them in divs with a class like `flexible-wrap` that sets an overflow:auto so that the table is scrollable if required.

Advantages

1. A standard way for developers and themers to deal with these issues (can go in coding guidelines)
2. Will remove the possibility for users to intentionally/accidentally destroy the interface by posting large content

Possible problems

1. Because all format_text calls will be wrapped by this special div there might be regressions throughout Moodle - we will have to review the calls and possibly disable the new wrapping divs for some of them. (For example, quiz multiple choice options are processed by format_text, then output inside a Label. The wrapping div would break that horribly.)
2. Some parts of Moodle can never be made to fit in a sensible width. For example the gradebook, and other reports.
3. IE6/7 (and possibly IE 8/9?) render their scrollbars INSIDE an element rather than outside like most other browsers meaning that there is a *VERY* high chance there will be redundant scrollbars within some elements that don't actually require wrapping (on these browsers)
4. Elements that require scrolling will have their own scrollbars and particularly in the case of tables this is likely to require scrolling the page vertically to locate the horizontal scrollbar, scrolling horizontally and then locating the desired row vertically again.
5. Elements with a set width (e.g.style="width:2000px") greater than the content area will need to be wrapped in a div with the wrapping class as well.

Proposed solution 2 - Source code order

Compromise, and use a 1, 3, 2 or 1, 2, 3 layout (with skip links for accessibility).

Advantages

1. It can be made to work for all pages.
2. We use a 1, 3, 2 at the OU, and it is reliable.

Possible problems

1. Slightly less accessible (unless you are comparing with the current situation that actually chops off text for most users even before you start resizing fonts, and is therefore infinitely less accessible, of course).
2. Hurts our pride to give up on a 2, 1, 3 layout.

Proposed solution 3 - JavaScript

Add some JavaScript to the page, so that once everything has been laid out, it computes how wide the page needs to be to avoid truncation, and then changes the min-width: 900px to whatever width is needed to make the content fit.

Advantages

1. Might be the easiest solution to implement.

Possible problems

1. Ewwwwwww! This is clearly a horrible hack.
2. JavaScript for layout is deeply evil.

Proposed solution 4 - Admin theme

Use different page layouts for different needs. Admin/settings pages show very different content than the normal learning pages. All pages for admins and teachers where they change settings or edit content are shown with the admin theme. Two different page layouts would solve a lot of issues. In for example WordPress and Drupal the concept of the admin theme for admin/settings pages and the "nice" theme for content is standard.

1. Use an "admin theme" with flexible width and a 1-2 layout for the admin and settings pages. The huge tables are mainly on the admin pages. Most table issues would be solved this way.
2. Use the existing 2-1-3 fixed width layout for all learning pages.
3. Change all tables in the forum layout and other modules if existent to div layouts.
4. Create a filter to display a miniature of oversized media and open the original size in a bigger overlay on click. The maximum width can be a setting in the filter to fit different theme needs.

Advantages

1. The pages with different needs get different layouts better fitting these needs.
2. One optimized admin theme can be used with many different themes. Theme designers can focus on the content pages when they work on themes.
3. The flexible width admin theme helps a lot when the content shall be displayed in any fixed width page layout.
4. The different look of the admin theme signals: be careful - you are changing things which may seriously affect the system or the learning content.
5. I use an flexible width admin theme I developed for some time now with all fixed width themes and solve the table width issues on admin/settings pages. It's always the same admin theme with very different content themes.

Possible problems

1. The deeply nested forum threads issues are not solved with the admin theme.

Opinions

Tim

I vote for 2, or failing that 3. I think 1. will not work.

Sam

agree with Tim except I don't think 3 is likely to be reliable either.

http://moodle.org/mod/cvsadmin/view.php?conversationid=5929

Frank

IMHO the only real problem is 2.2.Tables for internal layout (like the forum) and possibly 3.2. (Which, by the way, only proves that tables for layout are a bad thing, Frank Ralf/Semantic HTML3). Any other oversized, unwrappable content will break the layout one way or another and should be the responsibility of the author. That said, I favor solution 2; any solution which requires JavaScript (3) only makes the situation even more complex. --Frank Ralf 14:41, 26 October 2010 (UTC)

Urs

I vote for 4.

3 is no option - from my experience using JavaScript to correct page issues breaks every once in a while.

2 does not solve the table width issue in fixed width themes.

1 seams to offer more problems than advantages.

Please don't throw out the existing 2-1-3 page layout. In my opinion to skip it means much more than it "Hurts our pride to give up on a 2, 1, 3 layout.". By introducing an admin specific theme many issues can be solved. Additionally theme designers have less pages to work on.

I thought all table based page layouts should have gone in Moodle 2.0.

Chosen solution

Thank you to everyone for your thoughts both in this discussion and the developers chat.

The solution that we will go with is as follows:

1. An option will be added to format text that when set to true will wrap the text in a final div before returning it. This div will have a class with a predefined style so that large content is displayed with scrollbars if required,
   The option will be off by default but as part of the solution a review of format_text usage will be performed and the option turned on where required.
2. Forum posts will be converted from using tables for layout to a div structure. I have already created a patch for this which is largely backwards compatible with existing themes and changes the forum posts structure as little as possible.
3. A new report layout will be created, see the section below for details. A review all reports and uses of tables for pages where the new report layout should be implemented.

As well as the above tasks there will of course be the ongoing tasks of locating areas also affected by this problem and finding solutions on a case by case basis.

The report layout

The new layout won't use the 2,1,3 structure of existing layouts and won't be quite so accessible which isn't a big concern as we will only use it when there is no other option and in those few cases the content is normally not at all accessible anyway.

This layout will have one block region by default and will be a 1,2 layout (1=blocks, 2=content).

It is unfortunate that we need to move away from the 2,1,3 layout for the default themes (base, and standard) however after much deliberation it was decided that this was going to provide the most natural feel for most users. This will only be done in this one layout and it will be stressed that this layout only be used where absolutely essential, in fact it will only be allowed in situations where the content is tabulated data that is likely to require it. Anywhere tables have been used incorrectly will be converted as part of the ongoing tasks.

As part of the deliberations and trials with this there was also a report layout created that would be more accessible where the blocks were below the main content (block laid out horizontally as well). This layout whilst not used in the end will be preserved in a docs which I will link to after I write it.