What is the sense of this settings?
What is the functionality behind?
What is the definition a theme developer has to do to support the function?
I didn't found information at the docs.
In themes forum I've asked about the meaning of old/new browser themes in appearence theme selector. But we didn't found an answer. So I think dev forum can help. 
What is the sense of this settings?
What is the functionality behind?
What is the definition a theme developer has to do to support the function?
I didn't found information at the docs.
What is the sense of this settings?
What is the functionality behind?
What is the definition a theme developer has to do to support the function?
I didn't found information at the docs.
In my opinion the basic meaning of that setting makes a lot of sense:
Modern web browsers support standards-based HTML and XHTML (starting with HTML 4.01), which should display in the same way across all browsers.
It makes no sense to hack all themes using modern design, css and javascript just for IE6 - and that's the main reason why we need such a setting. To allow theme designers use different theme(s) for IE6 - the relic...
Like Ralf I am a little worried if it works - is it enought to select the legacy theme from theme selector or should we add something like $CFG->themelegacy = true; to legacy theme config.php ? Or is it actually built for IE5.5 and previous browsers (before IE6?)
I think it's basically for IE6, but there is some argument that frankly, IE7 also should be considered as an 'old browser' in terms of frequently needing CSS workarounds. Luckily, these are quite easy to apply thanks to the .ie7 class on body or whatever.
Tim and I were discussing this the other day and we think it would be nice if a similar mechanism could be used to select a 'mobile theme'. Here we have a bunch of customised stuff in our 1.9 to implement mobile display, but the theme is a rather more logical place to do it.
This will of course only work fully if modules properly use the new 'renderer' structure so that the theme can change things; basically our mobile theme removes the side columns and stuff like that, and it's better to do that in html rather than just css, especially if people might be using a slow (E)GPRS connection.
At the OU we have a complex mechanism that spots 'mobile' browsers because we wanted to standardise it (we use the same OU-wide cookies to store settings like if you're on a mobile device but you prefer the standard view). So it would be nice if this part were pluggable. But of course a standard implementation could fairly easily look in user agent for things like 'iPhone', 'Android', 'BlackBerry', 'Nokia', 'Samsung', etc.
Anyhow! In summary - it would be cool if there were three theme choices: standard, crap old browser, and mobile. Maybe in Moodle 2.1...
--sam
Tim and I were discussing this the other day and we think it would be nice if a similar mechanism could be used to select a 'mobile theme'. Here we have a bunch of customised stuff in our 1.9 to implement mobile display, but the theme is a rather more logical place to do it.
This will of course only work fully if modules properly use the new 'renderer' structure so that the theme can change things; basically our mobile theme removes the side columns and stuff like that, and it's better to do that in html rather than just css, especially if people might be using a slow (E)GPRS connection.
At the OU we have a complex mechanism that spots 'mobile' browsers because we wanted to standardise it (we use the same OU-wide cookies to store settings like if you're on a mobile device but you prefer the standard view). So it would be nice if this part were pluggable. But of course a standard implementation could fairly easily look in user agent for things like 'iPhone', 'Android', 'BlackBerry', 'Nokia', 'Samsung', etc.
Anyhow! In summary - it would be cool if there were three theme choices: standard, crap old browser, and mobile. Maybe in Moodle 2.1...
--sam
Its interesting to see that nobody explains the existing functionality, but we are starting to discuss what is interesting to develop in future.
I explained it, I think the other poster did too, maybe it was hard to spot the explanation among the discussion, but well, this is the developer forum so not surprising there's talk about development...
Here is the explanation again - as I understand it:
The old theme is used for IE6 and potentially any similar 'legacy' antique browsers which can't support the fancy stuff (CSS, JavaScript) in modern themes.
--sam
Here is the explanation again - as I understand it:
The old theme is used for IE6 and potentially any similar 'legacy' antique browsers which can't support the fancy stuff (CSS, JavaScript) in modern themes.
--sam
Hi Sam,
you're right. I'm not an developer, But a setting in website administration must be explained and should make sense also for non developers. Also if I'm not a developer Ie think that I understand a lot of functions in Moodle code. Before starting the discussions I tried to find information in the forums, in docs, in tracker and in code: without results.
I'd asked about the sense and expected that one of the developers can explain it. But your discussion was about future developments. The start of this discussion was in themes forum. The reason why I started it here was that we didn't found an explanation.
If I understand you correct: If the admin activates a theme as old theme the theme uses for all users only functions that are supported by IE6. Is this correct now? Is it also correct that this makes sense only if a Moodle system is used only internal in controlled environments where all users use the same old browser?
Why is this a setting that is theme related? If it is a system wide setting it should be a one time setting generally for all themes.
Or why isn't it a user setting in advanced profiles settings because mostly the use of browser is individually?
Why is a non developer asking this her? Because I'm responsible for the German translation. And if our translation team don't understand functionalities we can't translate it. An other issue is about usability. This also means that in our training we have to explain functionalities for admins.
It would be nice if you add the information to the docs. This would be helpfull for all theme developers and for admins. Theme developers also don't know about this functions.
Ralf Hilgenstock
Moodle Partner
Author of several Moodle books
you're right. I'm not an developer, But a setting in website administration must be explained and should make sense also for non developers. Also if I'm not a developer Ie think that I understand a lot of functions in Moodle code. Before starting the discussions I tried to find information in the forums, in docs, in tracker and in code: without results.
I'd asked about the sense and expected that one of the developers can explain it. But your discussion was about future developments. The start of this discussion was in themes forum. The reason why I started it here was that we didn't found an explanation.
If I understand you correct: If the admin activates a theme as old theme the theme uses for all users only functions that are supported by IE6. Is this correct now? Is it also correct that this makes sense only if a Moodle system is used only internal in controlled environments where all users use the same old browser?
Why is this a setting that is theme related? If it is a system wide setting it should be a one time setting generally for all themes.
Or why isn't it a user setting in advanced profiles settings because mostly the use of browser is individually?
Why is a non developer asking this her? Because I'm responsible for the German translation. And if our translation team don't understand functionalities we can't translate it. An other issue is about usability. This also means that in our training we have to explain functionalities for admins.
It would be nice if you add the information to the docs. This would be helpfull for all theme developers and for admins. Theme developers also don't know about this functions.
Ralf Hilgenstock
Moodle Partner
Author of several Moodle books
Hi Ralf,
I don't think that your description covers my understanding of how it works. The way I understand it:
* sites want to build themes that use the full array of browser capabilities - css3, etc. but...
* they still need to retain a *reasonable* experience for those with ancient browsers - ie6 in particular - and know that the theme is actually crafted for the peculiarities of those basic browsers, without deliberate hacks.
This setting lets the admin show one theme and its CSS etc for the majority of users, and another, specially crafted degraded experience for the others. Moodle will do browser detection and serve the appropriate theme for that browser- hence Sam's comment about extending this in future to be able to serve out a particular theme for mobile browsers. It's up to sites to decide whether or not they want to attempt to give all users a similar (lowest common denominator) experience.
http://dowebsitesneedtolookexactlythesameineverybrowser.com ?
Myles
I don't think that your description covers my understanding of how it works. The way I understand it:
* sites want to build themes that use the full array of browser capabilities - css3, etc. but...
* they still need to retain a *reasonable* experience for those with ancient browsers - ie6 in particular - and know that the theme is actually crafted for the peculiarities of those basic browsers, without deliberate hacks.
This setting lets the admin show one theme and its CSS etc for the majority of users, and another, specially crafted degraded experience for the others. Moodle will do browser detection and serve the appropriate theme for that browser- hence Sam's comment about extending this in future to be able to serve out a particular theme for mobile browsers. It's up to sites to decide whether or not they want to attempt to give all users a similar (lowest common denominator) experience.
http://dowebsitesneedtolookexactlythesameineverybrowser.com ?
Myles
Hi Myles,
this is the first explanation that makes sense for me. Thank you. It says that dependent from the users browser an alternative theme is used.
If I understand this correct Moodle defines what an old or new browser is. Is there a list which browser versions are detected as old or new? Or is this a theme related definition the theme designer has to do? How is this defined in the theme?
this is the first explanation that makes sense for me. Thank you. It says that dependent from the users browser an alternative theme is used.
If I understand this correct Moodle defines what an old or new browser is. Is there a list which browser versions are detected as old or new? Or is this a theme related definition the theme designer has to do? How is this defined in the theme?
Hi
I hope I understand all older postings in this discussion. Now I want to know if Moodle will see IE6 as an old browser or a modern browser. I am usually working with Mac OS X 10.6 and Safari 5 or Firefox 3.6 or Opera 10.6 ... and I think these are modern browsers.
For my experiment I started the VirtualBox with Windows 2000 and IE6 to see which theme my test server will show. My test server hosts Moodle 2.0 Preview 4+ (20100821) ... this is the today version. My theme setting in Moodle 2.0 is set to Splash for modern browsers and to Standard for older browsers.
Now I wanted to see different themes in Windows 2000 .... Standard in IE6 and Splash in Firefox 3.6.8 ... but both browsers are showing Splash. In IE6 it's looking not really nice!!
What do you think?
Ralf
I hope I understand all older postings in this discussion. Now I want to know if Moodle will see IE6 as an old browser or a modern browser. I am usually working with Mac OS X 10.6 and Safari 5 or Firefox 3.6 or Opera 10.6 ... and I think these are modern browsers.
For my experiment I started the VirtualBox with Windows 2000 and IE6 to see which theme my test server will show. My test server hosts Moodle 2.0 Preview 4+ (20100821) ... this is the today version. My theme setting in Moodle 2.0 is set to Splash for modern browsers and to Standard for older browsers.
Now I wanted to see different themes in Windows 2000 .... Standard in IE6 and Splash in Firefox 3.6.8 ... but both browsers are showing Splash. In IE6 it's looking not really nice!!
What do you think?
Ralf
Ralf H. originally asked the meaning of legacy browsers and legacy themes for translation in http://moodle.org/mod/forum/discuss.php?d=155987 and if you check for example code of pagelib.php or search "legacy" from files of moodle it obviously should work that way and we should see a different theme on IE6 - but like you said and like I noticed too in 2 of my previous posts that setting does not seem to work with plain selection of legacy theme in theme settings - not for pure IE6 and not for IE8 in Quirks mode. Something is probably missing from implementation of legacy themes - or none of us knows how to use them... 
Who knows why it does not seem to take action? What have we missed? Petr?
First of all, I was confused too when I saw the theme selection recently. You might have already noticed that I personally hate anything < IE8, because it is a huge pain for any web developer and I really hope IE9 will be the first standards compliant browser from Microsoft. Well for me the standards are not the holy grail of web development, I just want to write one markup that works the same way in all browsers.
Back to the topic, we (me and David) were discussing this yesterday and came with a potential UI+internal improvement that would solve some other issues too. It is obvious that one theme fits all browsers is not going to work, because devices such as iPhone, iPad, Android phones, etc. will not work properly with standard Moodle Themes due to screen size problems, multitouch, etc. Unlike PCs you can not easily upgrade your browser in a phone, we have to use what is there.
So the proposal is to define following device/browser types:
* standards compliant browsers (Firefox 2+ and higher, IE7+, Safari, etc.)
* legacy IE6 browser
* phones - iPhone, Android, etc.
* etc.
It might be better to make this class detection a bit more general.
And inside each theme config.php we would specify which classes of devices are supported. The actual selection could be two stage process - first page lists device classes with current selection, the next page would be used for selection of new theme for specified class.
Benefits:
# easier to explain to users - more room for class descriptions and examples
# developers my finally create themes for specific devices without hacking core or standard themes
Problems:
* It is recommended to not use browser detection hacks. Ideally CSS and JS should degrade gracefully...
BTW my MSDN subscription was renewed and I have found some time to install a few test VMs with different browsers for testing purposes. It should not be very difficult to implement a completely new theme selection page before the 2.0 release. We need to decide if we want browser/device classes proposed above and what the selection pages should look like to make them easy to use/understand. I do not remember writing the legacy selection code and I think I never tested it.
Petr Skoda
Back to the topic, we (me and David) were discussing this yesterday and came with a potential UI+internal improvement that would solve some other issues too. It is obvious that one theme fits all browsers is not going to work, because devices such as iPhone, iPad, Android phones, etc. will not work properly with standard Moodle Themes due to screen size problems, multitouch, etc. Unlike PCs you can not easily upgrade your browser in a phone, we have to use what is there.
So the proposal is to define following device/browser types:
* standards compliant browsers (Firefox 2+ and higher, IE7+, Safari, etc.)
* legacy IE6 browser
* phones - iPhone, Android, etc.
* etc.
It might be better to make this class detection a bit more general.
And inside each theme config.php we would specify which classes of devices are supported. The actual selection could be two stage process - first page lists device classes with current selection, the next page would be used for selection of new theme for specified class.
Benefits:
# easier to explain to users - more room for class descriptions and examples
# developers my finally create themes for specific devices without hacking core or standard themes
Problems:
* It is recommended to not use browser detection hacks. Ideally CSS and JS should degrade gracefully...
BTW my MSDN subscription was renewed and I have found some time to install a few test VMs with different browsers for testing purposes. It should not be very difficult to implement a completely new theme selection page before the 2.0 release. We need to decide if we want browser/device classes proposed above and what the selection pages should look like to make them easy to use/understand. I do not remember writing the legacy selection code and I think I never tested it.
Petr Skoda
Yes, all of those solutions sound neat. 
I tested about year ago a theme that had a one column default desing if javascript was disabled and otherwise it was using screen resolution detection (jquery) to select different layout and css for different screen widths. Using php and user_agent strings is just as nice - for example http://detectmobilebrowser.com/ gives php test like this to go on:
<?php
$useragent=$_SERVER['HTTP_USER_AGENT'];
if(preg_match('/android|avantgo|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino/i',$useragent)||preg_match('/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|e\-|e\/|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|xda(\-|2|g)|yas\-|your|zeto|zte\-/i',substr($useragent,0,4)))
header('Location: http://mysite_with_mobile_css');
?>
It is also possible that after a year or two we are talking about "legacy mobiles" and modern mobiles may be able to do the same things as current table PC:s - for example new Samsung Galaxy S mobiles can use 800px wide Display with 4.0” WVGA(480x800) 16M SUPER AMOLED,
Iphone 4 is using Retina display, 3.5-inch (diagonal) widescreen Multi-Touch display that can use 960-by-640-pixel resolution at 326 ppi.
+∞ - that sounds like a good interface. So you would start off with a screen like:
Current normal theme: Whatever [Change]
Current theme for old browsers (IE6): Whatever [Change]
Current theme for mobile browsers: Whatever [Change]
and then clicking change would take you to the normal theme selector- actually imo that selector is pretty awful - it would be nice if there was a sort of grid of themes each one showing a nice image preview, all on one page, instead of having to scroll through a massive list... but leaving that aside.
actually ideally you'd do it with JS/AJAX so that when you click on 'Change' it expands into a nice grid of theme previews w/ names so you can easily click one... no I'm not offering to code that...
For classes, I think smallscreen/mobile, normal, and legacy are enough. We can assign legacy (as needed) to any other browser that somebody dredges out of the ark.
It might be useful to detect which class is in use (other than just for the theme) so could this information be generally available as a function or whatever? For example, you might implement a custom renderer in a plugin which has support for both normal and mobile display, so that every mobile theme doesn't need to override your renderer.
In addition to these classes, it might be nice if there was an can_hover() method somewhere, or is_touch_screen(), whatever. So normal browsers would return true to can_hover(), but mobile browsers and ipad would return false because you can't hover with a touchscreen. (Even though ipad would presumably return 'normal' for the browser type/class above.)
Just throwing in some opinions - I'm interested in this (as is Anthony Forth here) particularly regarding mobile themes as noted. If there are some ideas here which you think are good but there isn't time for you to implement them, please ask me as we may well be able to spend a day or two on it. (I have not cleared this with my boss so can't actually promise but.)
--sam
Current normal theme: Whatever [Change]
Current theme for old browsers (IE6): Whatever [Change]
Current theme for mobile browsers: Whatever [Change]
and then clicking change would take you to the normal theme selector- actually imo that selector is pretty awful - it would be nice if there was a sort of grid of themes each one showing a nice image preview, all on one page, instead of having to scroll through a massive list... but leaving that aside.
actually ideally you'd do it with JS/AJAX so that when you click on 'Change' it expands into a nice grid of theme previews w/ names so you can easily click one... no I'm not offering to code that...
For classes, I think smallscreen/mobile, normal, and legacy are enough. We can assign legacy (as needed) to any other browser that somebody dredges out of the ark.
It might be useful to detect which class is in use (other than just for the theme) so could this information be generally available as a function or whatever? For example, you might implement a custom renderer in a plugin which has support for both normal and mobile display, so that every mobile theme doesn't need to override your renderer.
In addition to these classes, it might be nice if there was an can_hover() method somewhere, or is_touch_screen(), whatever. So normal browsers would return true to can_hover(), but mobile browsers and ipad would return false because you can't hover with a touchscreen. (Even though ipad would presumably return 'normal' for the browser type/class above.)
Just throwing in some opinions - I'm interested in this (as is Anthony Forth here) particularly regarding mobile themes as noted. If there are some ideas here which you think are good but there isn't time for you to implement them, please ask me as we may well be able to spend a day or two on it. (I have not cleared this with my boss so can't actually promise but.)
--sam