Does it have to be so bloody complicated? (preferred_width)

Does it have to be so bloody complicated? (preferred_width)

by Tim Hunt -
Number of replies: 27
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I am working on Development:Very flexible block system proposal, part of the Moodle 2.0 navigation/themes/etc. changes; and I am looking at the bit where it computes the width of each column of blocks, and thinking "does it really have to be this complicated".

Here is how it currently works:
  1. Moodle works out which blocks will be visible in, say, the left column.
  2. It then asks each of those blocks what it's 'preferred_width' is. (At this point, almost every block answers 180(px), looking through core code and contrib, other responses (with number of blocks that give that response) are 210 (8), 250 (2), 210 (2), 170 (1), 140 (1))
  3. Then it asks the theme if it wants to put any limit of the size of the blocks columns. Most themes use the default min = 100, max = 210. The two exceptions in core+contrib are anomaly: min = max = 200, and customcorners: min = max = 180. - Oh, except for the places where it does not bother the consult the theme, and instead hard-codes min = 180, max = 210.
  4. Then Moodle computes the actual width of the column as max(preferred widths from 2), but limited to be within the min and max given by the theme.

What does Moodel actually do with this number? Well, if this is a page that is still using horrible old-style tables for layout, then that width in pixels goes on the td for that blocks column as a style="width: NNNpx;" attribute.

However, on pages that have been converted to divs, like course/format/weeks/format.php, then that number is ignored, and instead in the theme we have
.weeks-format #left-column {
width: 11.5em;
}
in the theme CSS.


So, the whole seems pretty pointless these days, especially since page layouts in terms of px are not that sensible if you want things to work nicely when users change the font size.

I plan to just remove all this complication, and just the the theme decide how wide the columns should be in its CSS. Does anyone have a problem with that?
Average of ratings: Useful (2)
In reply to Tim Hunt

Re: Does it have to be so bloody complicated? (preferred_width)

by Nicolas Connault -
I'm happy with any effort to simplify something that should be as simple as block widths. If this could help the admin pages, all the better smile
Average of ratings: Useful (1)
In reply to Nicolas Connault

Re: Does it have to be so bloody complicated? (preferred_width)

by Frank Ralf -
The less the better! Layout is the responsibility of the theme.
Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Does it have to be so bloody complicated? (preferred_width)

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
I think blocks should be still be allowed to specify a preferred width in pixels if they want to.

Moodle should take all those and boil it down to one number which it makes available to the theme.

The theme can then do what it wants with that info (including ignoring it).

IMO the existing div-based course formats should use that number - it's a bug that they don't.
Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Does it have to be so bloody complicated? (preferred_width)

by Jeff Forssell -
I agree with the idea that ems rather than px width sounds like a good goal.

In the Docs:

"That means that the width setting is a best-effort settlement; your block can request a certain width and Moodle will try to provide it, but there's no guarantee whatsoever about the end result. As a concrete example, all standard Moodle course formats will deliver any requested width between 180 and 210 pixels, inclusive. "
http://docs.moodle.org/en/Development:Blocks

How should that be "ems" rephrased?

It would seem good to have all blocks, and themes, descriptions include what width they need, respectively which block widths they will support.

Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Does it have to be so bloody complicated? (preferred_width)

by Ian G -
Hi Tim,

I'm curious where the idea to make the widths in em's come from? Is there some research about that somewhere as a best practice?

I've heard of using ems and percentages for type sizes to allow for resizing, but I have not heard any accessibility reasons for doing that with layouts.

Will all images now be resizing too? I don't think background images resize (except browsers that use a "zoom" technique for resizing like Firefox).

---

More to the point of your question, I think it's important to have predictable results. I have a course where the instructor has a randomly generated post from a wiki appearing on the course page in a column. It drives me nuts that the column keeps resizing depending on the content that gets ported into it (long urls that don't break and other things). Sometimes the page displays beautifully and other times it expands squishes the center column which has the main content, reads very poorly, and looks like a mistake.

regards,
Ian
Average of ratings: Useful (1)
In reply to Ian G

Re: Does it have to be so bloody complicated? (preferred_width)

by Mat Cannings -
Hi Tim,
I do not have a solution but I remember that one of the problems with CSS only course formats was that you need to specify widths for the side columns, and the layout would get mucked up completely if one of the blocks was larger than this width.

Ideally a fixed width maximum for all blocks would solve this,sort of, but then you will get problems such as when a teacher places a wide image in a HTML block. Unless there is a mechanism for preventing this you will always end up with a potential problem. On my site I use max-width CSS rules for images in blocks that sort of prevent this but it does not prevent images having wrong aspect ratios and only catches this one circumstance.

After typing the above I do think that the best solution may be that the block width needs to be a value specified by the theme that all blocks must adhere to, especially with the planned changes to themes.
Average of ratings: Useful (1)
In reply to Mat Cannings

Re: Does it have to be so bloody complicated? (preferred_width)

by Frank Ralf -
Preventing large images to destroy the layout can be achieved by using the CSS property "overflow" (http://www.w3schools.com/Css/pr_pos_overflow.asp).

I strongly discourage using inline styles provided by the PHP code.

IMO each block should be given a descriptive id so that it can be themed easily by CSS.
Average of ratings: Useful (1)
In reply to Frank Ralf

Re: Does it have to be so bloody complicated? (preferred_width)

by Mat Cannings -
Hi Frank, I agree completely that there is no reason for inline CSS, I use the code below in my theme to 'capture' any occurrences of staff using over sized images in blocks.

#right-column img, #left-column img {
max-width:190px;
}

I would not expect a staff member to add inline CSS and can not really expect them all to resize images before uploading.

With the overflow property that you provided and maybe some other CSS in a theme it would be possible to make the block width irrelevent as it would all be controlled by CSS in the theme.

I believe, although I may be wrong, that the new theme/layouts would allow for wider or narrower areas for blocks/content to fit into so it may be that all blocks need to be made suitable for containment in flexibly sized spaces and not have their own widths specified at all.

Unfortunately with something like Wordpress or Drupal the block placement is managed by the admin or someone else who knows what fits the design, so width of columns can be flexible and the placement of Widgets/Content can be managed carefully, possibly changing the theme a little to make the Widget work. In Moodle the placement is usually managed by the Teacher who in many circumstances will try to place content wherever they are able, irrespective of suitability/aesthetics. In Moodle the theme needs to be more carefully controlled so that the blocks "just work". (I have always had equal widths for both left and right column because of this.)

Would it be suitable for the theme developer to control which blocks may appear in which area? i.e. Calendar could not be placed in a narrow area.
Average of ratings: Useful (1)
In reply to Frank Ralf

Re: Does it have to be so bloody complicated? (preferred_width)

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Each block is given a class name that is based on the block type, and a unique id too. What more do you want!
Average of ratings: -
In reply to Tim Hunt

Re: Does it have to be so bloody complicated? (preferred_width)

by Mat Cannings -
Hi Tim,
In a round about way I am agreeing with your original suggestion! but I am also playing devils advocate a bit.

You can make column width controlled solely by the theme itself, but at the same time you can not have full control of where the end user will place blocks, or what is in the block (HTML block).

I guess I am trying to emphasize that it will require more work by the theme developer to maintain a desired appearance once the end user starts to place blocks within the theme.

For example, I am thinking of a circumstance of a theme with two columns where blocks can be placed, one narrow and one wide, and the Calendar block that would need style adjusting depending on which column it is in to keep one week in a single row.

The theme developer will need to consider the appearance of all blocks when placed in either of these columns. Either creating rules for how blocks appear when placed in either column, or relying on the end user to not 'break' the theme by placing a wide block in a narrow column.


Average of ratings: Useful (1)
In reply to Mat Cannings

Re: Does it have to be so bloody complicated? (preferred_width)

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Well that is the problem with flexibility. It gives people many more creative ways to screw things up wink

I don't think that is a reason not to give people powerful tool, but you have hope that they use them responsibly, and you have build in as many safety features as you can.

On that note, can anyone recommend me HTML for a nice, robust three-column layout that I can use for displaying the blocks in the standard theme when I get to that part of the work? It would be nice if you experts could reach a consensus on the best approach while I am on holiday, and record your recommendation on MDL-19077. I really don't want to have to work that bit out myself wink Thanks.
Average of ratings: -
In reply to Tim Hunt

Re: Does it have to be so bloody complicated? (preferred_width)

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Tim > can anyone recommend me HTML for a nice, robust three-column layout... ?

I'm not going to recommend that, Tim, as I much prefer a 2-column layout.wink

Joseph

Average of ratings: -
In reply to Tim Hunt

Re: Does it have to be so bloody complicated? (preferred_width)

by Frank Ralf -
Hi Tim,

I have just stumbled over this website http://realworldstyle.com that provides CSS layouts with 2 or 3 columns, header and footer, which even work with NN4 (I'd call _that_ robust...).

hth
Frank
Average of ratings: -
In reply to Frank Ralf

Re: Does it have to be so bloody complicated? (preferred_width)

by Mat Cannings -
There is a good list of 3-column tableless layouts here http://css-discuss.incutio.com/?page=ThreeColumnLayouts

I think that the current CSS course layouts uses a variation of the third one down (One True Layout) to layout it's three columns. From that list it seems to suggest to me that the One True Layout or one of Alex Robinson's methods are best.

There has been some discussion about this type of CSS layout in http://tracker.moodle.org/browse/MDL-9306. Most of the problems discussed have arisen from the course layout conflicting with the Theme layout which I suppose would disappear if the Theme was to take more control.

One problem that I can foresee is what to do with a "block area" if there are no blocks within it? If a theme designer did not want to leave the space empty then I think a possible solution would be to check for emptyness and add a no_xxxxx tag to all areas when one area is empty. You could then create CSS for #left-column .no_left-column and #middle-column .no-left-column that would deal with the column resizing accordingly (I think there would only be three permutations! no-l, no-r and no-l-or-r).





Average of ratings: -
In reply to Tim Hunt

Re: Does it have to be so bloody complicated? (preferred_width)

by Ian G -
Hi Tim,

What happens to those unique ids when a course is archived and restored on a new server? Is there new id's or the same?

Ian
Average of ratings: -
In reply to Ian G

Re: Does it have to be so bloody complicated? (preferred_width)

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I am afraid that they change. And I can't think of anything that is guaranteed by be unique, but also not to change sad
Average of ratings: -
In reply to Tim Hunt

Re: Does it have to be so bloody complicated? (preferred_width)

by Ian G -
I wouldn't want to use them for themes if they will change.

All I can think of is pulling something from the user enter information on the course settings page, like "Course short name". If it was rendered into an ID div around the whole page the theme could do course specific styles

#CourseShortName .CssStyle {etc...}

Though, that wouldn't give the ability for the same block to behave differently on separate pages in the same course.

It would still be nice if users could enter their own tags around a block through the editing interface somehow. Those could move with the course content, just like any other block info would.

---

It would also work if you made a form field on the settings page that linked to a CSS that was in the Moodle course files section. It would travel with the course through archives and restores and the form could automatically update the new URL in the database. That would also solve the problem of how you manage the complexity of a number of different course themes from the server side theme's folder.

In fact, a new Moodle course could come with a custom_styles.css file already sitting in the files folder that was already connected. It could be blank and theme designers could just add any over-ride code they want through the browser and into that file...Hmm, I really like that idea. wink

Ian
Average of ratings: -
In reply to Ian G

Re: Does it have to be so bloody complicated? (preferred_width)

by Mat Cannings -
Hi Ian,
The unique ID for a block is mainly there for Javascript (Drag and Drop Re-ordering) purposes and not used for styling CSS, although you could.

When styling blocks you would use the class tags.

Most of the functionality that you have described is currently in Moodle so I would assume will remain in future.

At the moment there are classes and/or id that contain courseID, editing status, columns and most others you could think of so you can get very specific with styles. I do not not have Firefox but you can use CSS something like the examples below.

course-14 #left-column .block_calendar_month
or
course-1 editing #right-column .block_html





Average of ratings: -
In reply to Mat Cannings

Re: Does it have to be so bloody complicated? (preferred_width)

by Ian G -
Thanks Mat,

My post was not very clear and a little rambling. I was thinking as I wrote it. My last sentence about a course css is the important idea, and this is not currently offered in Moodle.

...a new Moodle course could come with a custom_styles.css file already sitting in the [course's] files folder that was already connected [to the course ID through the course settings page which would automatically update the URL with restores or moves of the course]. It could be blank and theme designers could just add any over-ride code they want through the browser and into that file. [You would probably need to have one example CSS showing the correct syntax for writing the style.]

I understand that classes can affect things specifically like the calendar. However, they do it for the whole theme. Just to pick one block as an example, there is no stable way to make the calendar look different for a French 100 than in French 200.

You could use the course ID but if that changes when the course is moved, archived, or restored...all the CSS would break.

This seems particularly relevant to the discussion of a more flexible block system in Moodle 2.0. How is the theme going to specify what happens to block A in course 1 and have something else happen to block A in course 2?

regards,
Ian
Average of ratings: -
In reply to Ian G

Re: Does it have to be so bloody complicated? (preferred_width)

by Ian G -
Oh, when I say course's file folder, I mean the files section available through the browser when you are in the course.
Average of ratings: -
In reply to Ian G

Re: Does it have to be so bloody complicated? (preferred_width)

by Mauno Korpelainen -

I think the important thing is how we define position for blocks. Current moodle has in table mdl_block_instance letters l and r defining position left or right but a more flexible block positioning could allow any custom positions (region in Tim's plan). And if position "xxx" or "yyy" is not defined in theme default position (l) could be used. That way if you have defined a position f to mean footer in theme and if you use same theme in restored course with the same theme blocks would get the same position when you backup and restore courses. Some block properties could be also as a separate field in table block_positions (or block_properties?) and again if some properties or custom styles do not exist default width and height could be used. I could imagine a situation where I would like to place 3 blocks to footer and each of them could have a different width...

Using custom css files inside course folders is rather interesting idea - they can be used already if you upload css files to course files and define your theme to use those files but in backup/restore process theme should recognize something like $CFG->currentcourse instead of old course id. Instead of getting some course settings from a separate css/php file course styles, different block positions and other styles could be also saved to database as a "course profile" or each user could have one field in database for custom course settings but it makes things more complex again.

Average of ratings: -
In reply to Ian G

Re: Does it have to be so bloody complicated? (preferred_width)

by Mauno Korpelainen -

Ian - you can also use <?php echo $COURSE->id ; ?> instead of the actual number. If course is restored with course files id just changes but $COURSE->id finds the file from correct place(s).

So if you use some custom code in your theme that has course files included it still works after backup-restore.

Average of ratings: -
In reply to Mat Cannings

Re: Does it have to be so bloody complicated? (preferred_width)

by Frank Ralf -
JFTR: See also this discussion on "Semantic DIV IDs?" (http://moodle.org/mod/forum/discuss.php?d=121398)

Frank
Average of ratings: -
In reply to Frank Ralf

Re: Does it have to be so bloody complicated? (preferred_width)

by Graeme Starke -

I have posted twice about image cutoff with IE7 and then found this thread with another search (now that I knew what to search for.

I am deliberately trying to use a basically two column layout for front page - a 750px wide graphic on the left and other blocks down the right, with a gap between.

I can see from this thread that the 210px width "happens" with moodle. How can I force it wider? .. up to 750px?

Regards

Graeme

Average of ratings: -
In reply to Graeme Starke

Setting width of left column

by Frank Ralf -
Hi Graeme,

The width of the left column is hard coded in the markup:

<td style="width: 210px;" id="left-column">

But you should be able to override that with CSS:

td#left-column {
  width: 750px !important;
}

(In the screenshot I set it to 300px.)

hth
Frank
Attachment left-column_300px.png
Average of ratings: -
In reply to Frank Ralf

Re: Setting width of left column

by Graeme Starke -

Thanks for that Frank, but I've scoured back over the two CSS sheet codes I can see (for standard and for formal-white theme) and cannot see where the coding is for left column. Do I have to put that in as specific coding?

Regards

Graeme

Average of ratings: -