I spent the better part of my evening last night trying to create a new Base theme that used percentage column widths instead of fixed pixel widths. I had some success in as far as I achieved three columns all dynamically set to take up a percentage of the screen. However, I couldn't get the content to appear in those columns.
Moodle's new layout is based on this system:
http://matthewjamestaylor.com/blog/holy-grail-no-quirks-mode.htm
and this one too (for some reason)
http://matthewjamestaylor.com/blog/ultimate-3-column-holy-grail-pixels.htm
But, it uses an entirely different naming scheme for some reason. I thought that I figured it out, but alas, I'll probably have to try it again.
Why am I sharing this? Two reasons:
1.) Horizontal scrollbars in sidebars should not be a design decision. It's a sign that something is wrong, in my humble opinion.
2.) If someone else can have a go at this, I'd really appreciate it.
3.) At the very least, I'd like to discuss alternative ways of creating more dynamic columns.
Oops. That's three.
Patrick:
Joseph
PS.- I wish there was a single place to discuss moodle 2.0 themes features, bugs & development. At the moment discussions seem to be spread out in this (Themes) forum, the Development forum, Documentation for developers :Development:Themes 2.0 and the bug tracker!
I totally agree. I find that the left column is much too narrow anyway, and there should be an easy way to change its width. See attached.Horizontal scrollbars in sidebars should not be a design decision. It's a sign that something is wrong, in my humble opinion.
Joseph
PS.- I wish there was a single place to discuss moodle 2.0 themes features, bugs & development. At the moment discussions seem to be spread out in this (Themes) forum, the Development forum, Documentation for developers :Development:Themes 2.0 and the bug tracker!
Joseph, regarding a single place to discuss moodle 2.0 themes features, bugs and development, let's keep using the themes forum and add discussion links to tracker issues and developer documentation.
If you come across a themes discussion in the general developer forum which you think would be better in the themes forum, please let me know so I can move it.
If you come across a themes discussion in the general developer forum which you think would be better in the themes forum, please let me know so I can move it.
Hi Patrick,
I hate that scroll bar! And yes it is a sign that there is something afoot!
I too spent ages last evening working/learning a new theme with little success I might add. I kept going off at a tangent distracted by things like cross-browser compatibly!
As for the Holy Grail of a three column design, has anyone used the 960 Grid System?
I thought the coding for that system is far easier to understand than Matthew's.
It's been adapted into a Drupal theme read more here...
Mary
I hate that scroll bar! And yes it is a sign that there is something afoot!
I too spent ages last evening working/learning a new theme with little success I might add. I kept going off at a tangent distracted by things like cross-browser compatibly!
As for the Holy Grail of a three column design, has anyone used the 960 Grid System?
I thought the coding for that system is far easier to understand than Matthew's.
It's been adapted into a Drupal theme read more here...
Mary
I'm sure that this is set for 2.0 for the indefinite future. Two thoughts:
1.) It's complex, but it works. I don't know why, but it does. I just need to understand it so I can modify it.
2.) Browser incompatibility is inevitable with the degree of changes that were made. Please make them known by filing bugs in the Tracker. If they are related to a theme, assign them to me. I'll fix them or pass them on to Petr or Sam.
1.) It's complex, but it works. I don't know why, but it does. I just need to understand it so I can modify it.
2.) Browser incompatibility is inevitable with the degree of changes that were made. Please make them known by filing bugs in the Tracker. If they are related to a theme, assign them to me. I'll fix them or pass them on to Petr or Sam.
The 2.0 theme i'm working on completely does away with the three columns and blocks. Block are instead just titles/icons on the left, when hovered over, the content swings out and opens into the content area. See yahoo's homepage (left nav column) for an example.
Since there is plenty of room, no scrolling. I started with the base theme, and whatever I set the column width to, the blocks expanded to that width. The new themes are 100x more flexible than the old system. But there are plenty of quirks...
Since there is plenty of room, no scrolling. I started with the base theme, and whatever I set the column width to, the blocks expanded to that width. The new themes are 100x more flexible than the old system. But there are plenty of quirks...
Just been reading all the info on the layout and devised a Moodle Map of the Page-Layout as defined by Moodle 2.0 v Matt's Holy Grail. See attached text file.
It certainly puts it all into perspective.
Mary
It certainly puts it all into perspective.
Mary
Morning Patrick,
Yes I did got it to work - after a fashion, but left it unresolved for the most part, last night. After what must be 'latent insight' after a good night's sleep, I realised this morning that the masks are, in effect, sandbags propping up the sides, which was probably explained in Matt's webpage, but I don't read everything, I'm too eager to get hands on experience. You can read this article about Sandbag CSS HERE
I've worked on three columns before so is not new to me, just the awful CSS code in pagelayout.css which makes no sense to me what so ever. I can't work with all that compressed mark-up, it gives me a headache.
Mary
Yes I did got it to work - after a fashion, but left it unresolved for the most part, last night. After what must be 'latent insight' after a good night's sleep, I realised this morning that the masks are, in effect, sandbags propping up the sides, which was probably explained in Matt's webpage, but I don't read everything, I'm too eager to get hands on experience. You can read this article about Sandbag CSS HERE
I've worked on three columns before so is not new to me, just the awful CSS code in pagelayout.css which makes no sense to me what so ever. I can't work with all that compressed mark-up, it gives me a headache.
Mary
In a reply to John St this morning I suggested that overflow: hidden is causing the scroll bars to appear. This is also required in the HolyGrail Percentages style as Matt says...
All the dimensions are in percentage widths so the layout adjusts to any screen resolution. Vertical dimensions are not set so they stretch to the height of the content.
Maximum column content widths
To prevent wide content (like long URLs) from destroying the layout (long content can make the page scroll horizontally) the column content divs are set to overflow:hidden. This chops off any content that is wider than the div. Because of this, it's important to know the maximum widths allowable at common screen resolutions. For example, if you choose 800 x 600 pixels as your minimum compatible resolution what is the widest image that can be safely added to each column before it gets chopped off? Here are the figures:
- 800 x 600
- Left & right columns: 162 pixels
- Center page: 357 pixels
- 1024 x 768
- Left & right columns: 210 pixels
- Center page: 459 pixels
Working on the the layout_demo I realized that the Moodle 2.0 Page-Layout naming scheme is very confusing - if not wrong.
Below the naming schemes in Moodle 2.0 :: Matt's Holy Grail :: My proposal
* #page * #page-header * #page-content :: colmask :: page-content * | #regions :: colmid :: region-main-box * | #regions-mask :: colleft :: region-post-box * | #region-main :: col1wrap :: region-main-wrap * | | #region-main-mask :: col1 (middle) :: region-main * | | .region-content * | #region-pre :: col2 (left) :: region-pre * | | .region-content * | #region-post :: col3 (right) :: region-post * | | .region-content * #page-footer
When you try out my layout_demo you will see, that my naming scheme makes much clearer where to set background colors (-box) and where to set the width. The direct correlation between the background boxes and the columns should be obvious from the naming scheme.
If you think my proposed naming scheme helps to understand the structure better I recommend to change the naming scheme in Moodle 2.0.
Patrick, you're not convinced?
I followed the existing approach to use Moodle terminology for the naming scheme. In Moodle 2 we need to get used to work with regions.
On the other side you may intend to ask why we may call something a region what in reality is a column and may better be called column? And why we need Moodle specific names when everybody needs to read the original documentation and gets confused?
Hm. The best solution I can think of in the long run is a naming scheme that helps to understand the concept and the relation between the three boxes (background) and the regions/columns (content). The naming scheme should inherit from Moodle terminology. For me the proposal I developed makes most sense from this point of view.
The only way to succeed is to create good documentation to get people to work quite fast. And with good Moodle documentation nobody needs to reed the original documentation Matt created and nobody will be confused any more. Right?
The only way to succeed is to create good documentation to get people to work quite fast. And with good Moodle documentation nobody needs to reed the original documentation Matt created and nobody will be confused any more. Right?
Good point. The naming scheme should define the areas. Yours works fine. I was looking for more of an explanation than a convincing argument. Thanks!
Sam, each content area is contained in an extra div with the class ".region-content". What is this extra div needed for?
* #page * #page-header * #page-content * | #regions * | #regions-mask * | #region-main * | | #region-main-mask * | | .region-content * | #region-pre * | | .region-content * | #region-post * | | .region-content * #page-footer
If there is no need for the extra div, I propose to remove it and add the class to the region container like:
* #page * #page-header * #page-content * | #regions * | #regions-mask * | #region-main * | | #region-main-mask.region-content * | #region-pre.region-content * | #region-post.region-content * #page-footer
Hi Urs,
The .region-content div is there purely to provide an easy to find location for people to start making changes. It's certainly not a required element but simply there to minimise casualties.
From memory border, margin, and padding changes will cause IE6 to fall out of alignment if applied to #region-pre, or #region-post and not compensated for in their parent elements.
What are your thoughts on this one Patrick? should it stay or go.
As for the naming scheme, I'm certainly open to that. However I am not the one working on the new themes in Moodle 2.0, that of course is Patrick
I'll leave it up to him.
My only concern there is that if it is going to be done it needs to be done ASAP as people have already started creating themes.
The .region-content div is there purely to provide an easy to find location for people to start making changes. It's certainly not a required element but simply there to minimise casualties.
From memory border, margin, and padding changes will cause IE6 to fall out of alignment if applied to #region-pre, or #region-post and not compensated for in their parent elements.
What are your thoughts on this one Patrick? should it stay or go.
As for the naming scheme, I'm certainly open to that. However I am not the one working on the new themes in Moodle 2.0, that of course is Patrick
My only concern there is that if it is going to be done it needs to be done ASAP as people have already started creating themes.
When talking about grid systems, I like to use the one from http://konstruktors.com/ Cant get any easier simpler to code. With some more customization I have used it to create many different layouts and all in quick code mode. I remember I have used this to completely change the look and feel of moodle for a tableless layout and beyond the constrain of columns(i did have to hack moodle code a bit but the requirement for that project was doing that anyway)
Just thought you might want to take a look at this system. Lot less simpler, lot cleaner, lot more logical and it can get you started in matter of minutes ;)
Cheers!!
--
Nave
Just thought you might want to take a look at this system. Lot less simpler, lot cleaner, lot more logical and it can get you started in matter of minutes ;)
Cheers!!
--
Nave
Hello,
Just getting into Theming and I've enjoyed parsing through the page layouts comments; thanks for the hard work! Concerning Mary's question, "As for the Holy Grail of a three column design, has anyone used the 960 Grid System?" I'm interested in how this system might affect Moodle layouts.
Thanks
Also wanted to add, how sure are you that the scroll bar in the that block is related to the css of the column layout and not to the block (and/or containing divs) itself?
Some testing, using a completely independent (and different) css column layout with 2.0, revealed (for me at least) that scroll bars still showed up... Just something to think about.
Some testing, using a completely independent (and different) css column layout with 2.0, revealed (for me at least) that scroll bars still showed up... Just something to think about.
The scrollbars are being created inside the sideblock stylesheets where they appear.
Specifically:
- /moodle/blocks/settings_navigation_tree/styles.css
- /moodle/blocks/global_navigation_tree/styles.css
These two blocks have nearly identical CSS.
To fix, this:
.block_settings_navigation_tree .block_tree {margin:5px;padding-left:0px;overflow-x:auto;overflow-y:visible;}
becomes:
.block_settings_navigation_tree .block_tree {margin:5px;padding-left:0px;overflow:visible;}
And, this:
.block_settings_navigation_tree .block_tree .tree_item {white-space:nowrap;margin:2px 0px;padding-left: 16px;margin:3px 0px;white-space:nowrap;text-align:left;}
becomes:
.block_settings_navigation_tree .block_tree .tree_item {margin:2px 0px;padding-left: 16px;margin:3px 0px;text-align:left;}
Then, this gets deleted:
.ie7 .block_settings_navigation_tree .block_tree {overflow-x:scroll;}
This removes the scrollbar and wraps lines that are too long.
Specifically:
- /moodle/blocks/settings_navigation_tree/styles.css
- /moodle/blocks/global_navigation_tree/styles.css
These two blocks have nearly identical CSS.
To fix, this:
.block_settings_navigation_tree .block_tree {margin:5px;padding-left:0px;overflow-x:auto;overflow-y:visible;}
becomes:
.block_settings_navigation_tree .block_tree {margin:5px;padding-left:0px;overflow:visible;}
And, this:
.block_settings_navigation_tree .block_tree .tree_item {white-space:nowrap;margin:2px 0px;padding-left: 16px;margin:3px 0px;white-space:nowrap;text-align:left;}
becomes:
.block_settings_navigation_tree .block_tree .tree_item {margin:2px 0px;padding-left: 16px;margin:3px 0px;text-align:left;}
Then, this gets deleted:
.ie7 .block_settings_navigation_tree .block_tree {overflow-x:scroll;}
This removes the scrollbar and wraps lines that are too long.
I've made a couple of small changes to the base body tag and #page selector, more to do with the way I would center a website.
From:
body { margin: auto 0px; width:auto; }
Note: is this body margin set to auto (top/bottom) and 0px (left/right) deliberately, or are these values the wrong way round?
#page { width:100%; overflow:hidden;}
To:
body { text-align: center; }
#page { text-align: left; width:90%; margin: 0px auto; overflow:hidden;}
Note: #page width can vary depending on what effect one is after. I set it to 90%, but that's a personal thing. Also I am assuming it's OK to keep the overflow: hidden in the #page css mark-up?
From:
body { margin: auto 0px; width:auto; }
Note: is this body margin set to auto (top/bottom) and 0px (left/right) deliberately, or are these values the wrong way round?
#page { width:100%; overflow:hidden;}
To:
body { text-align: center; }
#page { text-align: left; width:90%; margin: 0px auto; overflow:hidden;}
Note: #page width can vary depending on what effect one is after. I set it to 90%, but that's a personal thing. Also I am assuming it's OK to keep the overflow: hidden in the #page css mark-up?
MDL-22108 has now been resolved.
I am still a little unsure however whether this was a wise idea. I am concerned about the usability of the navigation blocks if several large items have been added to a course. What does everyone think? I hate the horizontal scroll bars as much as anyone but I still don't know whether this is a great solution.
MDL-21350 may lead to a possible solution. Feel free to comment.
I am still a little unsure however whether this was a wise idea. I am concerned about the usability of the navigation blocks if several large items have been added to a course. What does everyone think? I hate the horizontal scroll bars as much as anyone but I still don't know whether this is a great solution.
MDL-21350 may lead to a possible solution. Feel free to comment.
Thank you, Sam.
Can we get some community feedback on a solution to this new potential problem of navigation items wrapping on too long?
Why does a navigation block have to show every activity? Why not just show the week or topic sections? My guess is clicking these will take the user immediately to that section anyway.
Can we get some community feedback on a solution to this new potential problem of navigation items wrapping on too long?
Why does a navigation block have to show every activity? Why not just show the week or topic sections? My guess is clicking these will take the user immediately to that section anyway.
Hi Patrick,
There is a setting for the blocks in fact that limits what they can show, I am close to committing several changes to the navigation one of which was to remove that setting however I will reconsider now.
IMO that being said I don't think that removing activities from the navigation would really be a good solution to this. It would mean a big change to the navigation at this point and would put the onus back on plugin developers for those who want them on the navigation, hiding them is an option still but we would need to support them being shown in the base theme at least.
There is a setting for the blocks in fact that limits what they can show, I am close to committing several changes to the navigation one of which was to remove that setting however I will reconsider now.
IMO that being said I don't think that removing activities from the navigation would really be a good solution to this. It would mean a big change to the navigation at this point and would put the onus back on plugin developers for those who want them on the navigation, hiding them is an option still but we would need to support them being shown in the base theme at least.
Here are my two cents.
A tooltip(with trim to words) or a mouseover modal window approach is best to set this straight I think!
Looking at the potential problems
1. IMO noone likes horizontal scrollbars.
2. A trim can lead to unexplained section/activity names(have seen many course activities setup using a naming scheme. so if those are trimmed it will lead to only same names)
3. Most of the installations have many activities have many many activities in a course or a section so that will lead to loooong vertical scroll.
IMHO best design option would be to use a modal window up and down scroll on reaching for content upwards or downwards, but am not sure how much of it will be acceptable to non-js users. Will have to code it such that it downgrades to a normal menu with activity/section names trimmed to words instead of letters with a tooltip. Or may be just give the users the option to chose that. I understand how complex it can get but the UI I think will be rich and lot simpler!
Cheers!!
Nave
A tooltip(with trim to words) or a mouseover modal window approach is best to set this straight I think!
Looking at the potential problems
1. IMO noone likes horizontal scrollbars.
2. A trim can lead to unexplained section/activity names(have seen many course activities setup using a naming scheme. so if those are trimmed it will lead to only same names)
3. Most of the installations have many activities have many many activities in a course or a section so that will lead to loooong vertical scroll.
IMHO best design option would be to use a modal window up and down scroll on reaching for content upwards or downwards, but am not sure how much of it will be acceptable to non-js users. Will have to code it such that it downgrades to a normal menu with activity/section names trimmed to words instead of letters with a tooltip. Or may be just give the users the option to chose that. I understand how complex it can get but the UI I think will be rich and lot simpler!
Cheers!!
Nave
Hi Navin,
The trim is certainly a fidgity personal thing, I'll be implementing block based settings to take control of that in the next couple of days (will see MDL-21350 resolved).
The idea of redelivering the content through some JS means is certainly something that should be explored.
We would need to default to non-js, Moodle should work without JavaScript first, and then be enhanced. That of course isn't a problem the navigation structure already supports generation though AJAX, we would just need to find a way to harness it for unaltered information so that we could expand the information we already have (i.e. non-trimmed text).
My only concern with this would be the time that it would take to, design-implement-test a solution. Moodle 2.0 isn't far off now and time is VERY limited.
Perhaps this will be something that can be better explored once we have entered beta.
For the time being any idea's are most appreciated
Cheers
Sam
The trim is certainly a fidgity personal thing, I'll be implementing block based settings to take control of that in the next couple of days (will see MDL-21350 resolved).
The idea of redelivering the content through some JS means is certainly something that should be explored.
We would need to default to non-js, Moodle should work without JavaScript first, and then be enhanced. That of course isn't a problem the navigation structure already supports generation though AJAX, we would just need to find a way to harness it for unaltered information so that we could expand the information we already have (i.e. non-trimmed text).
My only concern with this would be the time that it would take to, design-implement-test a solution. Moodle 2.0 isn't far off now and time is VERY limited.
Perhaps this will be something that can be better explored once we have entered beta.
For the time being any idea's are most appreciated
Cheers
Sam
Hi Sam,
This looks marginally better than the "horrible" scrollbar, but...
- Why is the Navigation colum so ridiculously narrow to start with? Now that we are using wide screens, we have plenty of room to accomodate wider column, don't we? Or could we not have something similar to what we had in "good old" (now deprecated) frames, where the end-user could set at will the width of frames?
- We seem to be losing precious horizontal space by incrementing by too many pixels, especially in the very last increment (under Week 1).
- Since the column widths are now set universally by the theme designer, whatever solution we come up with needs to take into consideration that we don't necessarily have control over the left and right column width any more. While I realize that a column width setting would seem to be an easy fix to this solution, I'm not sure that leaving such a design decision to users would be good all themes. I think a better solution from us to come up with something that satisfies all reasonable widths while still serving the navigation function.
- I completely agree that the horizontal space can be reduced. That's a partial fix and I'll file a task for myself to test this out.
Hi Joseph,
I certainly agree with you that the navigation is narrow, I work on a large screen myself and my browser is always maximised. Unfortunately we can't bet on the same for the rest of the community, I'm sure there are still many people who use small monitors (smartphones aside that's separate).
It's a bit like JavaScript at the end of the day, I would love to be able to rely on it but I can't.
1. I do agree with Patrick, he is right on the mark. A column width setting would seem like an easy fix, but a solution through design and theme implementation would be much more robust.
One of the cool things about Moodle 2 is that you can implement your own block regions, you can have as many as you want in your layout, and you can put them where ever you want; as a themer you can take total control of the regions including their width.
This unfortunately makes it nearly impossible for Moodle to provide simple width settings as we can't assume what is there and how it fits together.
However it is possible for you to define those settings if you want! In saying that I realise that the process of creating settings for a theme hasn't been documented, fingers crossed I will get a chance to do so soon.
2. I'll leave that up to Patrick Thanks Patrick
Cheers
Sam
I certainly agree with you that the navigation is narrow, I work on a large screen myself and my browser is always maximised. Unfortunately we can't bet on the same for the rest of the community, I'm sure there are still many people who use small monitors (smartphones aside that's separate).
It's a bit like JavaScript at the end of the day, I would love to be able to rely on it but I can't.
1. I do agree with Patrick, he is right on the mark. A column width setting would seem like an easy fix, but a solution through design and theme implementation would be much more robust.
One of the cool things about Moodle 2 is that you can implement your own block regions, you can have as many as you want in your layout, and you can put them where ever you want; as a themer you can take total control of the regions including their width.
This unfortunately makes it nearly impossible for Moodle to provide simple width settings as we can't assume what is there and how it fits together.
However it is possible for you to define those settings if you want! In saying that I realise that the process of creating settings for a theme hasn't been documented, fingers crossed I will get a chance to do so soon.
2. I'll leave that up to Patrick
Cheers
Sam
回复Patrick Malley
本讨论区帖子已移除
本讨论区帖子的内容已移除，无法再访问。
You are welcome Dietmar,
I still find confusion with #page-content because it is anything but! It's actually the right column!!!
I color coded all the elements in base theme page layout this morning so that each element became a solid color. It is surprising to see the left column with two colors, top one colour, bottom another, same with center main column but the right column is one solid color from header to footer.
I think the more you play with this 3 column framework the better one understands the principles of its structure.
Mary
I still find confusion with #page-content because it is anything but! It's actually the right column!!!
I color coded all the elements in base theme page layout this morning so that each element became a solid color. It is surprising to see the left column with two colors, top one colour, bottom another, same with center main column but the right column is one solid color from header to footer.
I think the more you play with this 3 column framework the better one understands the principles of its structure.
Mary
回复Mary Evans
本讨论区帖子已移除
本讨论区帖子的内容已移除，无法再访问。
This page layout works with two kinds of divs. First come three divs contained in each other for the boxes. Then come the three divs for the columns. Plus some wrapper divs to deal with browser issues. This way all column backgrounds have the same full hight of the tallest content.
Per column we have a box for the background and a container for the content.
You may have a look at the layout_demo I have created. You can turn the used style rules on and off one after another and see how affect the page.
The rules to set the background color and the width settings are highlighted.
"it's much easier to visualise in one's mind"
That's exactly what I intended when I worked on the explanition page and the proposed changes.
As I could see from the last Moodle 2.0 changes in CVS the changes are not official. Patrick needs to decide if there is enough positive forum feedback (he had asked for) to implement the changes.