Moodle
  1. Moodle
  2. MDL-25630

Wrap the front page content in divs with descriptive classes so they can be styled individually.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.5
    • Component/s: Course
    • Labels:
    • Testing Instructions:
      Hide

      Note to Tester:
      It is important that Theme Designer Mode is enabled before you commence testing!

      1. To TEST first select a theme that uses a Custom setting page where you can add CSS directly into the theme. Afterburner or Formal White or Sky High to name a few...
      2. If Frontpage settings have not been set to use Site news/Course list/Category names/ Category combo, then set that up now so that they all display before and after login.
      3. Next add the following CSS to the theme's custom settings page Site Administration > Appearance > Themes > Afterburner... (Other theme links)...
        #site-news-forum,
        #frontpage-course-list,
        #frontpage-category-names,
        #frontpage-category-combo {
            padding: 20px;
            border: 5px solid #036;
            border-radius: 20px;
        }
        #page-site-index .headingblock {
            margin-top: 0;
        }
        

        Save settings!

      4. Next go to Home page, either logged in or not and TEST to see if the various elements on the front page have a solid border round them.

      PS: As with most Moodle themes, it will look better if your screen resolution is between 1024px x 768px and 1400px x 1050px. If you use a very wide screen, then try floating the browser window (restore down)and make the window narrower by pushing the right edge <<=to the left.

      Show
      Note to Tester: It is important that Theme Designer Mode is enabled before you commence testing! To TEST first select a theme that uses a Custom setting page where you can add CSS directly into the theme. Afterburner or Formal White or Sky High to name a few... If Frontpage settings have not been set to use Site news/Course list/Category names/ Category combo, then set that up now so that they all display before and after login. Next add the following CSS to the theme's custom settings page Site Administration > Appearance > Themes > Afterburner... (Other theme links)... #site-news-forum, #frontpage-course-list, #frontpage-category-names, #frontpage-category-combo { padding: 20px; border: 5px solid #036; border-radius: 20px; } #page-site-index .headingblock { margin-top: 0; } Save settings! Next go to Home page, either logged in or not and TEST to see if the various elements on the front page have a solid border round them. PS: As with most Moodle themes, it will look better if your screen resolution is between 1024px x 768px and 1400px x 1050px. If you use a very wide screen, then try floating the browser window (restore down)and make the window narrower by pushing the right edge <<=to the left.
    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_25_STABLE
    • Pull Master Branch:
      wip-MDL-25630_master
    • Rank:
      15080

      Description

      The content on the front page isn't wrapped with anything useful, it would be nice if it were possible to styles each section of front page content individually.

      Please see linked discussion.

      Cheers
      Sam

        Activity

        Hide
        Wiktor Wandachowicz added a comment -

        From what I know since Moodle 2.1 (I haven't tested 2.0) all views have generated id's so styling with CSS is easier.

        For example, front page of our Moodle installation contains this:

          <body id="page-site-index" ...
            <div id="page-wrapper" ...
              <div id="page" ...
                <div id="page-header" ... > ... </div>
        
                <div id="page-content" ...
                  <div id="region-main-box"
                    <div id="region-post-box"
                      <div id="region-main-wrap"
                        <div id="region-main" ...
        
                          <!-- All relevant content goes here -->
        
                        </div>
                        <div id="region-pre"> ... </div>
                        <div id="region-post"> ... </div>
                      </div>
                    </div>
                  </div>
                </div>
        
                <div class="clearfix"></div>
                <div id="page-footer" ... > ... </div>
              </div>
              <!-- END #page -->
            </div>
            <!-- END #page-wrapper -->
        
            ...
          </body>
        

        and specific CSS style definition can be for example:

        #page-site-index #page-content { color: red; }
        

        Have you tried Google Chrome -> RightMouseButton to examine elements?
        Or MS IE 8/9 -> F12 -> Find element to see all relevant div tags, their id's and classes?

        Or am I missing something?

        Show
        Wiktor Wandachowicz added a comment - From what I know since Moodle 2.1 (I haven't tested 2.0) all views have generated id's so styling with CSS is easier. For example, front page of our Moodle installation contains this: <body id="page-site-index" ... <div id="page-wrapper" ... <div id="page" ... <div id="page-header" ... > ... </div> <div id="page-content" ... <div id="region-main-box" <div id="region-post-box" <div id="region-main-wrap" <div id="region-main" ... <!-- All relevant content goes here --> </div> <div id="region-pre"> ... </div> <div id="region-post"> ... </div> </div> </div> </div> </div> <div class="clearfix"></div> <div id="page-footer" ... > ... </div> </div> <!-- END #page --> </div> <!-- END #page-wrapper --> ... </body> and specific CSS style definition can be for example: #page-site-index #page-content { color: red; } Have you tried Google Chrome -> RightMouseButton to examine elements? Or MS IE 8/9 -> F12 -> Find element to see all relevant div tags, their id's and classes? Or am I missing something?
        Hide
        Evan Irving-Pease added a comment -

        My understanding of the issue here is that on the "Site home" the contents inside <!-- All relevant content goes here --> are not themselves wrapped in usable DIVs.

        i.e. the different front page content items (News items, List of courses, List of categories, and Combo list) are not wrapped in DIVs, instead the are all first order children of the #region-content div. So if I wanted to do something very simple like draw a border around the news items content I cannot.

        Show
        Evan Irving-Pease added a comment - My understanding of the issue here is that on the "Site home" the contents inside <!-- All relevant content goes here --> are not themselves wrapped in usable DIVs. i.e. the different front page content items (News items, List of courses, List of categories, and Combo list) are not wrapped in DIVs, instead the are all first order children of the #region-content div. So if I wanted to do something very simple like draw a border around the news items content I cannot.
        Hide
        Mary Evans added a comment - - edited

        @Sam Hemelryk,

        I have just come across this tracker issue just now, it's been linked from the Theme's forum. I see it's been around for a long time now and since you are pretty busy, I thought you would not mind me assigning MDL-25630 to myself.

        I have a few ideas I would like to try that may help with styling the frontpage.
        For a long time now I have thought about adding divs to different frontpage items, like category/courses/combo much the same as mentioned by Evan, in his comment above this one.

        I'll send some ideas up to my github and put them up for Peer Review.

        Cheers
        Mary

        Show
        Mary Evans added a comment - - edited @Sam Hemelryk, I have just come across this tracker issue just now, it's been linked from the Theme's forum. I see it's been around for a long time now and since you are pretty busy, I thought you would not mind me assigning MDL-25630 to myself. I have a few ideas I would like to try that may help with styling the frontpage. For a long time now I have thought about adding divs to different frontpage items, like category/courses/combo much the same as mentioned by Evan, in his comment above this one. I'll send some ideas up to my github and put them up for Peer Review. Cheers Mary
        Hide
        Mary Evans added a comment -

        As you will see from the attached image, by just adding a div container around each section of the four allowed elements on the Frontpage (Site news/Course list/Category names/Category combo) you can achieve this simple view, but it would allow theme designers to be able to style this more easily, especially for smaller screens.

        I'll add the code sometime tomorrow.

        Show
        Mary Evans added a comment - As you will see from the attached image, by just adding a div container around each section of the four allowed elements on the Frontpage (Site news/Course list/Category names/Category combo) you can achieve this simple view, but it would allow theme designers to be able to style this more easily, especially for smaller screens. I'll add the code sometime tomorrow.
        Hide
        Sam Hemelryk added a comment -

        Hi Mary,

        You are always more than welcome to take items off my queue
        Ping me if you need a peer-review, otherwise I'll keep an eye out for this when it come through integration.

        Many thanks
        Sam

        Show
        Sam Hemelryk added a comment - Hi Mary, You are always more than welcome to take items off my queue Ping me if you need a peer-review, otherwise I'll keep an eye out for this when it come through integration. Many thanks Sam
        Hide
        Mary Evans added a comment -

        Hi Sam
        I've just added a bunch of folk who I thought may like to add a comment or vote or even contribute.

        At the moment all I have done is add a line or two of html to moodle/index.php to add some much needed divs around the various elements on the frontpage using html_writer to fit in with the way it has been written.

        However, I am wondering if this could be transfered to moodle/lib/outputrenderers.php, although it looks to be working ok.

        I'll wait until the posse arrives.

        Show
        Mary Evans added a comment - Hi Sam I've just added a bunch of folk who I thought may like to add a comment or vote or even contribute. At the moment all I have done is add a line or two of html to moodle/index.php to add some much needed divs around the various elements on the frontpage using html_writer to fit in with the way it has been written. However, I am wondering if this could be transfered to moodle/lib/outputrenderers.php, although it looks to be working ok. I'll wait until the posse arrives.
        Hide
        Amy Groshek added a comment -

        @Mary, do you have your changes available somewhere to view?

        Show
        Amy Groshek added a comment - @Mary, do you have your changes available somewhere to view?
        Hide
        Mary Evans added a comment - - edited

        @Amy
        I'm on with this now and hope to get it finished and pushed to my GITHUB the next half-hour or so.

        Show
        Mary Evans added a comment - - edited @Amy I'm on with this now and hope to get it finished and pushed to my GITHUB the next half-hour or so.
        Hide
        Mary Evans added a comment -

        @Sam
        When you have a moment can you Peer review this? Thanks

        Show
        Mary Evans added a comment - @Sam When you have a moment can you Peer review this? Thanks
        Hide
        Amy Groshek added a comment - - edited

        Thanks Mary.

        I question the need for IDs. There's no need to specify front page, because we have .pagelayout-frontpage to do that. We have .sitetopic for the topic/resource area. Why not continue with that model, giving wrappers for the Site News, Course Categories, and Combo List identifying classes? Might also be useful to give them all the class .box or to utilize a new class for the concept of "wrapper of an interactive information block or activity block displayed in full."

        Show
        Amy Groshek added a comment - - edited Thanks Mary. I question the need for IDs. There's no need to specify front page, because we have .pagelayout-frontpage to do that. We have .sitetopic for the topic/resource area. Why not continue with that model, giving wrappers for the Site News, Course Categories, and Combo List identifying classes? Might also be useful to give them all the class .box or to utilize a new class for the concept of "wrapper of an interactive information block or activity block displayed in full."
        Hide
        Mary Evans added a comment -

        Hi Amy,

        I prefer ID's for the much the same reason Daniel Wahl espouses in the Themes forum discussion "Markup standardization recommendations to make theming faster and more reliable" https://moodle.org/mod/forum/discuss.php?d=216519#p942919
        To quote Danny:
        "...I'm not too keen on OO-CSS because it doesn't accomplish the stated goal of "making theming faster and more reliable". For example:

        #footer {} - obviously the page footer
        .footer {} - could be a forum post? blog? gotta use body > .footer or #region_main + footer or something..."

        Show
        Mary Evans added a comment - Hi Amy, I prefer ID's for the much the same reason Daniel Wahl espouses in the Themes forum discussion "Markup standardization recommendations to make theming faster and more reliable" https://moodle.org/mod/forum/discuss.php?d=216519#p942919 To quote Danny: "...I'm not too keen on OO-CSS because it doesn't accomplish the stated goal of "making theming faster and more reliable". For example: #footer {} - obviously the page footer .footer {} - could be a forum post? blog? gotta use body > .footer or #region_main + footer or something..."
        Hide
        Amy Groshek added a comment - - edited

        So we know that ID's are the most efficient selectors. If you wanted to make the most efficiently rendering page possible, you would literally give every single element on the page a unique ID, then apply styling with single ID selectors. That would be super fast, and also super ridiculous. It would probably be extremely non-semantic and extremely difficult to maintain. You don't see this approach even on hardcore performance based sites. I think the lesson here is not to sacrifice semantics or maintainability for efficient CSS.

        http://css-tricks.com/efficiently-rendering-css/

        We should consider technical debt here on future theme maintenance and development.

        Show
        Amy Groshek added a comment - - edited So we know that ID's are the most efficient selectors. If you wanted to make the most efficiently rendering page possible, you would literally give every single element on the page a unique ID, then apply styling with single ID selectors. That would be super fast, and also super ridiculous. It would probably be extremely non-semantic and extremely difficult to maintain. You don't see this approach even on hardcore performance based sites. I think the lesson here is not to sacrifice semantics or maintainability for efficient CSS. http://css-tricks.com/efficiently-rendering-css/ We should consider technical debt here on future theme maintenance and development.
        Hide
        Mary Evans added a comment -

        How an element is styled on a page depends on what it is, where it is, and how it fits in with the rest of the page. Giving four separate elements IDs is not going to make the page look any better. Where the work needs to be fixed is right in the CORE of Moodle, the parts that have been put together with sticky tape and a myriad of classes that are extremely difficult to manage in some places. Forums and blogs come to mind here. You have already seen with your work in MDL=37264 what can happen when the wrong classes are added.

        I agree with what you are doing and hoping to achieve, what I cannot see is how you think making these four containers 'classes' will help style them better. If they share a commonality on the page, yes classes would work within them, but you still need the IDs to move then around the page. Classes don't work as well in that situation.

        Take a look at how simple the Zen Garden is and how versatile it is when it come to restying.

        http://www.mezzoblue.com/zengarden/alldesigns/

        Show
        Mary Evans added a comment - How an element is styled on a page depends on what it is, where it is, and how it fits in with the rest of the page. Giving four separate elements IDs is not going to make the page look any better. Where the work needs to be fixed is right in the CORE of Moodle, the parts that have been put together with sticky tape and a myriad of classes that are extremely difficult to manage in some places. Forums and blogs come to mind here. You have already seen with your work in MDL=37264 what can happen when the wrong classes are added. I agree with what you are doing and hoping to achieve, what I cannot see is how you think making these four containers 'classes' will help style them better. If they share a commonality on the page, yes classes would work within them, but you still need the IDs to move then around the page. Classes don't work as well in that situation. Take a look at how simple the Zen Garden is and how versatile it is when it come to restying. http://www.mezzoblue.com/zengarden/alldesigns/
        Hide
        Mary Evans added a comment - - edited

        I've just been looking at the page you linked to. Now what is written there in relation to how IDs should not be used is interesting as it states...

        ul#main-navigation {  }

        ID's are unique, so they don't need a tag name to go along with it. Doing so makes the selector less efficient.

        Don't do it with class names either, if you can avoid it. Classes aren't unique, so theoretically you could have a class name do something that could be useful on multiple different elements. And if you wanted to have that styling be different depending on the element, you might need to tag-qualify (e.g. li.first), but that's pretty rare, so in general, don't.

        The fact is, all the wrong stuff is being done in Moodle, and adding more classes will only add to the mess.

        Show
        Mary Evans added a comment - - edited I've just been looking at the page you linked to. Now what is written there in relation to how IDs should not be used is interesting as it states... ul#main-navigation { } ID's are unique, so they don't need a tag name to go along with it. Doing so makes the selector less efficient. Don't do it with class names either, if you can avoid it. Classes aren't unique, so theoretically you could have a class name do something that could be useful on multiple different elements. And if you wanted to have that styling be different depending on the element, you might need to tag-qualify (e.g. li.first), but that's pretty rare, so in general, don't. The fact is, all the wrong stuff is being done in Moodle, and adding more classes will only add to the mess.
        Hide
        David Scotson added a comment -

        Since you've added divs to wrap these items, you could remove line 298 which is currently being used to space them out by outputting a br tag between them.

        Regarding the class vs. ids discussion, it's worth bearing in mind the fact that Moodle is currently moving from a model where you couldn't change the HTML, but it was intended to support diverse themeing (whether that actually succeeded is another discussion...) and the worst of the supported browsers at that time didn't support very much CSS and which therefore required more classes and ids, to one where you have (some) control over (some) of the HTML that is being written and fancy CSS can let you target almost anything without someone having to have specifically designated that item as being themeable.

        In the older model you find vast numbers of #ids, the majority of which are never used, and the ones that are used are used inconsistently so you can find 20 or 30 CSS rules setting subtly different paddings on the ids of large tables e.g. 100% wide, 95% wide, 100% wide with 10px padding etc. Each individual activity developer doing whatever they feel looks nicest at that time, with that theme, on their screen.

        I'd prefer the new model to adopt a small number of classes that are used consistently across Moodle. In my renderers I basically delete every id I see, and consider them guilty until proven innocent, and with almost the same level of suspicion for overly-specific classes. Of course, since they're renderers I can add them back in if necessary, without it having to be something that concerns core Moodle or anyone using it.

        So my immediate response would be that these should have some widely used class. Looking at the My Moodle page which performs almost the same function and is themed to be visually similar I see that it re-uses the code for blocks and so has a class='block' and a further class="block_course_overview" (which is a class rather than an id because sometimes, though not always, you can have two blocks on the same page.

        I note that currently the default theme seems to be going to some trouble to theme these differently marked up areas to look the same (though not succeeding perfectly) e.g. the header text and background gradient are the same on those two pages, yet the markup is very different:

        .block .header h2 vs h2.headingblock.header

        Where it all starts to diverge is the "content" of each block, where everyone goes their own way:

        ul.unlist for available courses, nothing (just three divs at the same level as the header) for site news, div.box.generalbox.categorybox for course categories, and a div.course_category_tree#course_category_tree50d42674f02f32 for the combo display.

        So while either a class or id on the wrapper would solve the problem for anyone only wanting to style the wrapper itself but not, for example, the padding around the content, if you want things to just pick up appropriate styles as people theme without them having to do each and every item individually, it would be better for the whole structure and naming to be relatively standard across similar components. In this case the appropriate choice appears to be the Moodle block.

        Show
        David Scotson added a comment - Since you've added divs to wrap these items, you could remove line 298 which is currently being used to space them out by outputting a br tag between them. Regarding the class vs. ids discussion, it's worth bearing in mind the fact that Moodle is currently moving from a model where you couldn't change the HTML, but it was intended to support diverse themeing (whether that actually succeeded is another discussion...) and the worst of the supported browsers at that time didn't support very much CSS and which therefore required more classes and ids, to one where you have (some) control over (some) of the HTML that is being written and fancy CSS can let you target almost anything without someone having to have specifically designated that item as being themeable. In the older model you find vast numbers of #ids, the majority of which are never used, and the ones that are used are used inconsistently so you can find 20 or 30 CSS rules setting subtly different paddings on the ids of large tables e.g. 100% wide, 95% wide, 100% wide with 10px padding etc. Each individual activity developer doing whatever they feel looks nicest at that time, with that theme, on their screen. I'd prefer the new model to adopt a small number of classes that are used consistently across Moodle. In my renderers I basically delete every id I see, and consider them guilty until proven innocent, and with almost the same level of suspicion for overly-specific classes. Of course, since they're renderers I can add them back in if necessary, without it having to be something that concerns core Moodle or anyone using it. So my immediate response would be that these should have some widely used class. Looking at the My Moodle page which performs almost the same function and is themed to be visually similar I see that it re-uses the code for blocks and so has a class='block' and a further class="block_course_overview" (which is a class rather than an id because sometimes, though not always, you can have two blocks on the same page. I note that currently the default theme seems to be going to some trouble to theme these differently marked up areas to look the same (though not succeeding perfectly) e.g. the header text and background gradient are the same on those two pages, yet the markup is very different: .block .header h2 vs h2.headingblock.header Where it all starts to diverge is the "content" of each block, where everyone goes their own way: ul.unlist for available courses, nothing (just three divs at the same level as the header) for site news, div.box.generalbox.categorybox for course categories, and a div.course_category_tree#course_category_tree50d42674f02f32 for the combo display. So while either a class or id on the wrapper would solve the problem for anyone only wanting to style the wrapper itself but not, for example, the padding around the content, if you want things to just pick up appropriate styles as people theme without them having to do each and every item individually, it would be better for the whole structure and naming to be relatively standard across similar components. In this case the appropriate choice appears to be the Moodle block.
        Hide
        Amy Groshek added a comment - - edited

        The current model that we have for blocks is a great model. We do not assign individual IDs to our blocks. We give them a .block class to indicate type, and we give them a class which indicates which block they are.

        ID's are unique, so they don't need a tag name to go along with it. Doing so makes the selector less efficient.

        That's not a very strong argument. Classes don't need a tag either.

        Don't do it with class names either, if you can avoid it. Classes aren't unique, so theoretically you could have a class name do something that could be useful on multiple different elements. And if you wanted to have that styling be different depending on the element, you might need to tag-qualify (e.g. li.first), but that's pretty rare, so in general, don't.

        The fact that classes aren't unique is their strength, and allows for the implementation of simpler, more maintainable CSS. Once again, I'll reassert the idea of technical debt.

        If we do not start to move away from proliferation of IDs vs systematic, structured use of classnames, we are basically encouraging theme developers to do as David has done, and use renderers to basically rewrite most of the HTML printed to the page. Any efficiency we might have gained by pinpointing a couple hundred IDs is, at that point, far outweighted by the additional development time to write and maintain the overriding renderers.

        How in the world did we even get the idea that some aspects of CSS were good and others evil? Who decided and what data did they use to judge? Did their goals fit our goals? There is nothing wrong with using classes. In almost every case, classes work well and have fewer unintended consequences than either IDs or element selectors.

        You should style almost everything with classes. The goal is to find a balance between classes that are too broad and include everything and the kitchen sink and classes that are too narrow. Generally speaking, you don’t want your classes to be so narrow that each one applies a single property value pair. It becomes extremely hard to evolve your design if every item is composed of mini-mixins.

        On the other hand, if classes are too broad, you will have duplication. Try to find the middle ground where all the repeating visual patterns can be abstracted. This is hard, but very worthwhile. If you do it, your code will stay clean. You will finally see results from trying harder.

        Classes are our friends. Seeing a lot of IDs is actually very bad.

        http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/

        Show
        Amy Groshek added a comment - - edited The current model that we have for blocks is a great model. We do not assign individual IDs to our blocks. We give them a .block class to indicate type, and we give them a class which indicates which block they are. ID's are unique, so they don't need a tag name to go along with it. Doing so makes the selector less efficient. That's not a very strong argument. Classes don't need a tag either. Don't do it with class names either, if you can avoid it. Classes aren't unique, so theoretically you could have a class name do something that could be useful on multiple different elements. And if you wanted to have that styling be different depending on the element, you might need to tag-qualify (e.g. li.first), but that's pretty rare, so in general, don't. The fact that classes aren't unique is their strength, and allows for the implementation of simpler, more maintainable CSS. Once again, I'll reassert the idea of technical debt. If we do not start to move away from proliferation of IDs vs systematic, structured use of classnames, we are basically encouraging theme developers to do as David has done, and use renderers to basically rewrite most of the HTML printed to the page. Any efficiency we might have gained by pinpointing a couple hundred IDs is, at that point, far outweighted by the additional development time to write and maintain the overriding renderers. How in the world did we even get the idea that some aspects of CSS were good and others evil? Who decided and what data did they use to judge? Did their goals fit our goals? There is nothing wrong with using classes. In almost every case, classes work well and have fewer unintended consequences than either IDs or element selectors. You should style almost everything with classes. The goal is to find a balance between classes that are too broad and include everything and the kitchen sink and classes that are too narrow. Generally speaking, you don’t want your classes to be so narrow that each one applies a single property value pair. It becomes extremely hard to evolve your design if every item is composed of mini-mixins. On the other hand, if classes are too broad, you will have duplication. Try to find the middle ground where all the repeating visual patterns can be abstracted. This is hard, but very worthwhile. If you do it, your code will stay clean. You will finally see results from trying harder. Classes are our friends. Seeing a lot of IDs is actually very bad. http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/
        Hide
        Mary Evans added a comment -

        If you don't mind me saying, but all this should have been discussed in 2010 when Moodle 2.0 made it Début, and Patrick Malley was struggling with a layout that was decided for him. At that time Moodle was moving away from tables to a more 'table-less' design. Most of the early 'test' themes were written by developers, not web designers. It was Patrick who got things to look pretty, and it was not easy.

        The fact I am now Component Lead for Themes is because I volunteered to do the job of fixing Moodle bugs in themes, of which there were a backlog which is ever increasing. So please don't feel I have the authority to make decisions, I don't. As far as I know Patrick is still Themes manager. I just do this job for the love of it. I have the time and a certain amount of know-how, learned mainly by doing, but I am by no means an expert. If you really feel classes are the way to go, with this then tell me what you want putting in and I'll oblige.

        I'm tired of pointless discussions, they never really go anywhere, they just drive you insane!

        What we do need is a good set of design guidelines, based on what works best in Moodle, not Twitter or Facebook or any other site for that matter. We need to keep Moodle unique, but at the same time keeping it simple, which will in the long run make it easier to design Moodle themes. But a lot, and I mean a LOT of work needs to be addressed in Moodle core for this to become a reality.

        Show
        Mary Evans added a comment - If you don't mind me saying, but all this should have been discussed in 2010 when Moodle 2.0 made it Début, and Patrick Malley was struggling with a layout that was decided for him. At that time Moodle was moving away from tables to a more 'table-less' design. Most of the early 'test' themes were written by developers, not web designers. It was Patrick who got things to look pretty, and it was not easy. The fact I am now Component Lead for Themes is because I volunteered to do the job of fixing Moodle bugs in themes, of which there were a backlog which is ever increasing. So please don't feel I have the authority to make decisions, I don't. As far as I know Patrick is still Themes manager. I just do this job for the love of it. I have the time and a certain amount of know-how, learned mainly by doing, but I am by no means an expert. If you really feel classes are the way to go, with this then tell me what you want putting in and I'll oblige. I'm tired of pointless discussions, they never really go anywhere, they just drive you insane! What we do need is a good set of design guidelines, based on what works best in Moodle, not Twitter or Facebook or any other site for that matter. We need to keep Moodle unique, but at the same time keeping it simple, which will in the long run make it easier to design Moodle themes. But a lot, and I mean a LOT of work needs to be addressed in Moodle core for this to become a reality.
        Hide
        Amy Groshek added a comment -

        Hi Mary,

        Thank you for providing that history. I'm well aware of the difficulties, and don't mean to add extra stress, conflict, or work for you. I agree that we need a good set of design guidelines. I surveyed all of the activities when preparing for submitting MDL-37264, and I agree that a lot of work needs to be done in core to make Moodle easier to theme. We unearthed some of that when looking at that simple generalbox issue as well: MDL-36576. Hopefully we can get closer to that with some of the changes in MDL-37264.

        We're smack in the middle of many folks' holiday vacations right now. We might not get the input we need from other interested parties for several days. But let's start to think through this and hopefully we can get some input from some others as well?

        From my perspective, writing renderers is a pretty high-level challenge for many theme designers. I see theme layouts and config file as an easier skill to learn. So I consider theme designer first-order control over markup as being in the layouts, the config file, and the CSS. So it seems like what your average theme designer can't change using those tools, we should get as standardized as reasonable. It seems like that's your goal too. I don't think we need to make Moodle look like something it's not. Moodle has some pretty specific features and we want to make decisions about them that serve our end-users.

        With regard to this particular problem, I think what you've done is fine. What I would do differently is to use your IDs as classes, and remove the frontpage from them where it occurs (since we have the body class to tell us that). It might also be worth considering adding a section class to the same wrapper element. And, since M2.4 is now using the HTML5 doctype, we might consider whether we want to use the section tag instead of the div tag. But that last is not a big deal.

        Cheers and happy holidays! It has been a great pleasure working more closely with you these last few months, and I look forward to more collaboration in the coming year.

        Warm regards,
        Amy

        Show
        Amy Groshek added a comment - Hi Mary, Thank you for providing that history. I'm well aware of the difficulties, and don't mean to add extra stress, conflict, or work for you. I agree that we need a good set of design guidelines. I surveyed all of the activities when preparing for submitting MDL-37264 , and I agree that a lot of work needs to be done in core to make Moodle easier to theme. We unearthed some of that when looking at that simple generalbox issue as well: MDL-36576 . Hopefully we can get closer to that with some of the changes in MDL-37264 . We're smack in the middle of many folks' holiday vacations right now. We might not get the input we need from other interested parties for several days. But let's start to think through this and hopefully we can get some input from some others as well? From my perspective, writing renderers is a pretty high-level challenge for many theme designers. I see theme layouts and config file as an easier skill to learn. So I consider theme designer first-order control over markup as being in the layouts, the config file, and the CSS. So it seems like what your average theme designer can't change using those tools, we should get as standardized as reasonable. It seems like that's your goal too. I don't think we need to make Moodle look like something it's not. Moodle has some pretty specific features and we want to make decisions about them that serve our end-users. With regard to this particular problem, I think what you've done is fine. What I would do differently is to use your IDs as classes, and remove the frontpage from them where it occurs (since we have the body class to tell us that). It might also be worth considering adding a section class to the same wrapper element. And, since M2.4 is now using the HTML5 doctype, we might consider whether we want to use the section tag instead of the div tag. But that last is not a big deal. Cheers and happy holidays! It has been a great pleasure working more closely with you these last few months, and I look forward to more collaboration in the coming year. Warm regards, Amy
        Hide
        Mary Evans added a comment -

        Thanks for that Amy, now I know we are both thinking alike, although perhaps from different perspectives.

        I'll keep this brief, as I am tired after spending an afternoon flower arranging in church ready for the festivities. So yes the holidays are on us, and the countdown to Christmas has started!

        I'm looking forward to learning more about Moodle, as I am sure I will do, if we manage to get all the changes you have set out in MDL-37264 done before M25 is rolled out! LOL

        Have a Happy Christmas and New Year...

        Kind regards
        Mary

        Show
        Mary Evans added a comment - Thanks for that Amy, now I know we are both thinking alike, although perhaps from different perspectives. I'll keep this brief, as I am tired after spending an afternoon flower arranging in church ready for the festivities. So yes the holidays are on us, and the countdown to Christmas has started! I'm looking forward to learning more about Moodle, as I am sure I will do, if we manage to get all the changes you have set out in MDL-37264 done before M25 is rolled out! LOL Have a Happy Christmas and New Year... Kind regards Mary
        Hide
        Mary Evans added a comment - - edited

        @Amy Groshek
        I have been reading up about Object Oriented CSS and now see where you were coming from with all the classes. What you were saying makes perfect sense, and I can see it will work better. Now that I am a bit wiser, I shall have a little play with this again and see if I can utilise some classes from Bootstrap CSS.

        Mind you to change Moodle to OO-CSS will be one mammoth task, but what a learning curve that would be!

        Show
        Mary Evans added a comment - - edited @ Amy Groshek I have been reading up about Object Oriented CSS and now see where you were coming from with all the classes. What you were saying makes perfect sense, and I can see it will work better. Now that I am a bit wiser, I shall have a little play with this again and see if I can utilise some classes from Bootstrap CSS. Mind you to change Moodle to OO-CSS will be one mammoth task, but what a learning curve that would be!
        Hide
        Amy Groshek added a comment - - edited

        Mary Evans "Mammoth task" indeed, knowing where we are and where we'd have to get to. But theme versioning would help a ton, since we wouldn't have to get it all done at once. And I think once theme designers started to see the difference we'd have lots of help spotting the weak points. Cheers!

        Show
        Amy Groshek added a comment - - edited Mary Evans "Mammoth task" indeed, knowing where we are and where we'd have to get to. But theme versioning would help a ton , since we wouldn't have to get it all done at once. And I think once theme designers started to see the difference we'd have lots of help spotting the weak points. Cheers!
        Hide
        Sam Hemelryk added a comment -

        Hi Mary,

        The changes look fine, if you're still happy with them feel free to push them up for integration when you are ready.

        It's an interesting read this issue. Just to offer a passing thought on renderers, I don't disagree that they are high level things that many a designer will never tinker with.
        But for Moodle, at the moment, they perhaps offer us an escape route from the design madness we currently have.
        Renderers are about separating logic and design. By converting more of core to renderers we are better separating our code.
        If/When we decide to change how we handle our design, and have created guidelines etc it will be a much easier job to implement if things are wrapped up nicely in renderers as we will only need to alter the renderers code rather than work through scripts trying to separate at the time.
        Of course we don't need things to be in renderers, I just saying things that are in renderers will be easier to convert.

        Anyway, just a passing thought.

        Cheers
        Sam

        Show
        Sam Hemelryk added a comment - Hi Mary, The changes look fine, if you're still happy with them feel free to push them up for integration when you are ready. It's an interesting read this issue. Just to offer a passing thought on renderers, I don't disagree that they are high level things that many a designer will never tinker with. But for Moodle, at the moment, they perhaps offer us an escape route from the design madness we currently have. Renderers are about separating logic and design. By converting more of core to renderers we are better separating our code. If/When we decide to change how we handle our design, and have created guidelines etc it will be a much easier job to implement if things are wrapped up nicely in renderers as we will only need to alter the renderers code rather than work through scripts trying to separate at the time. Of course we don't need things to be in renderers, I just saying things that are in renderers will be easier to convert. Anyway, just a passing thought. Cheers Sam
        Hide
        Mary Evans added a comment - - edited

        Thanks Sam, I'll push this for integration so that we can see how it works and how we can style it and what other classes need adding. I don't want to loose this opportunity.

        It does not need any CSS adding to base as yet so will not affect anything stylewise.

        Show
        Mary Evans added a comment - - edited Thanks Sam, I'll push this for integration so that we can see how it works and how we can style it and what other classes need adding. I don't want to loose this opportunity. It does not need any CSS adding to base as yet so will not affect anything stylewise.
        Hide
        Eloy Lafuente (stronk7) added a comment -

        The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

        TIA and ciao

        Show
        Eloy Lafuente (stronk7) added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
        Hide
        Mary Evans added a comment -

        RE-BASED

        Show
        Mary Evans added a comment - RE-BASED
        Hide
        Dan Poltawski added a comment -

        Integrated to master. Thanks Mary.

        Show
        Dan Poltawski added a comment - Integrated to master. Thanks Mary.
        Hide
        Michael de Raadt added a comment -

        Test result: Not successful.

        Sorry. The custom CSS changes did not appear for me.

        Show
        Michael de Raadt added a comment - Test result: Not successful. Sorry. The custom CSS changes did not appear for me.
        Hide
        Mary Evans added a comment -

        Sorry, I forgot to say Purge all caches after adding CSS. Either that or enable theme Designer Mode. I do this all the time and never think others might not know!!!

        Show
        Mary Evans added a comment - Sorry, I forgot to say Purge all caches after adding CSS. Either that or enable theme Designer Mode. I do this all the time and never think others might not know!!!
        Hide
        Mary Evans added a comment -

        I've just testing this branch and found it works OK (see attached image). So can someone please test this again?

        Thanks

        Show
        Mary Evans added a comment - I've just testing this branch and found it works OK (see attached image). So can someone please test this again? Thanks
        Hide
        Sam Hemelryk added a comment -

        Moving back to waiting for testing.

        Show
        Sam Hemelryk added a comment - Moving back to waiting for testing.
        Hide
        Mary Evans added a comment -

        Oh goody!

        Show
        Mary Evans added a comment - Oh goody!
        Hide
        Michael de Raadt added a comment -

        Retesting... (thanks for the themeing lesson)

        Show
        Michael de Raadt added a comment - Retesting... (thanks for the themeing lesson)
        Hide
        Michael de Raadt added a comment -

        Test result: Success!

        Tested in Master only.

        Thanks for working on this.

        Show
        Michael de Raadt added a comment - Test result: Success! Tested in Master only. Thanks for working on this.
        Hide
        Eloy Lafuente (stronk7) added a comment -

        A brilliant future is awaiting us out there, better with your code. Let's look towards the future together, this is now closed.

        (and won't be revisiting it unless some regression is found)

        Thanks and ciao

        Show
        Eloy Lafuente (stronk7) added a comment - A brilliant future is awaiting us out there, better with your code. Let's look towards the future together, this is now closed. (and won't be revisiting it unless some regression is found) Thanks and ciao

          People

          • Votes:
            2 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: