Moodle
  1. Moodle
  2. MDL-41973

POLICY: Improvements to Moodle do not require testing in old unsupported browsers

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Deferred
    • Affects Version/s: 2.5
    • Fix Version/s: None
    • Labels:
      None
    • Affected Branches:
      MOODLE_25_STABLE
    • Rank:
      53157

      Description

      There's some confusion about whether we support IE6 and IE7, and what it means in concrete terms if we do or if we don't.

      It would be good to agree explicitly on what it means if we "support" a browser version, what it means if we don't "support" a browser version, and agree on a timetable for when these transitions happen.

      Note that if we use a graduated definition of "support" (e.g. "core functionality will work in IE8 but not look as nice or miss a few addition features") then we should probably be explicit about that and timetable when that transitions to full on "unsupported" in the sense of, "it won't work" or "we'll actively prevent you logging in with that browser to prevent you having a poor experience of our software".

      This was sparked by the presence of hundreds of lines of CSS that are there only for the benefit of IE6 and IE7 users. There were also some webkit and moz prefixes that are only needed for old versions of those browsers, which is a similar issue.

        Issue Links

          Activity

          Hide
          David Scotson added a comment -

          Some relevant links/quotes:

          http://docs.moodle.org/dev/Moodle_2.0_release_notes

          System requirements

          Since Moodle 2.0 is such a major release, we are allowing ourselves some increases in the requirements.

          Any standards-supporting browser from the past few years, for example:

          Firefox 3 or later
          Safari 3 or later
          Google Chrome 4 or later
          Opera 9 or later
          MS Internet Explorer 7 or later (Even Google doesn't support IE6 any more)
          etc

          http://docs.moodle.org/dev/Moodle_2.4_release_notes

          Requirements

          Recommended minimum browser: Firefox 4, Internet Explorer 8 (IE 10 required for drag and drop of files from outside the browser into Moodle), Safari 5, Google Chrome 11
          Moodle upgrade: Moodle 2.2 or later (if upgrading from earlier versions, you must upgrade to 2.2 as a first step)
          Minimum DB versions: PostgreSQL 8.3, MySQL 5.1.33 (MDL-33984), MSSQL 2005 or Oracle 10.2
          Minimum PHP version: PHP 5.3.2

          NOTE: We will drop support for IE8 after Moodle 2.5 (June 2013). This means IE8 will probably still work for 2.6, but developers will not be required to test their new code on that browser. Moodle, like most of the world's web sites and browser producers, encourages you to keep your browsers current to improve security and functionality while saving us valuable time. (For example see what Google is doing)

          http://docs.moodle.org/dev/Moodle_2.5_release_notes

          Requirements

          These are just minimums. We recommend keeping all your software updated.

          Recommended minimum browser: Google Chrome 11, Firefox 4, Safari 5, Internet Explorer 8 (IE 10 required for drag and drop of files from outside the browser into Moodle)
          Moodle upgrade: Moodle 2.2 or later (if upgrading from earlier versions, you must upgrade to 2.2.9 as a first step)
          Minimum DB versions: PostgreSQL 8.3, MySQL 5.1.33, MariaDB 5.2, MSSQL 2005 or Oracle 10.2 (oci_native_moodle_package.sql needs to be executed before upgrade on Oracle servers)
          Minimum PHP version: PHP 5.3.3
          New PHP extension requirements: GD

          NOTE: We will drop support for IE8 in Moodle 2.6 (to be released November 2013). This means IE8 will probably still work for 2.6, but developers will not be required to test their new code on that browser. Moodle, like most of the world's web sites and browser producers, encourages you to keep your browsers current to improve security and functionality while saving us valuable time. (For example see what Google is doing)

          I just noticed that although it's in a section titled "Requirements" and in a list of other things which are hard requirements (presumably you get warned if you use a DB or PHP version that's too old) it actually only says "Recommended minimum" which is a bit vague about whether the emphasis is on "minimum" or "recommended".

          Show
          David Scotson added a comment - Some relevant links/quotes: http://docs.moodle.org/dev/Moodle_2.0_release_notes System requirements Since Moodle 2.0 is such a major release, we are allowing ourselves some increases in the requirements. Any standards-supporting browser from the past few years, for example: Firefox 3 or later Safari 3 or later Google Chrome 4 or later Opera 9 or later MS Internet Explorer 7 or later (Even Google doesn't support IE6 any more) etc http://docs.moodle.org/dev/Moodle_2.4_release_notes Requirements Recommended minimum browser: Firefox 4, Internet Explorer 8 (IE 10 required for drag and drop of files from outside the browser into Moodle), Safari 5, Google Chrome 11 Moodle upgrade: Moodle 2.2 or later (if upgrading from earlier versions, you must upgrade to 2.2 as a first step) Minimum DB versions: PostgreSQL 8.3, MySQL 5.1.33 ( MDL-33984 ), MSSQL 2005 or Oracle 10.2 Minimum PHP version: PHP 5.3.2 NOTE: We will drop support for IE8 after Moodle 2.5 (June 2013). This means IE8 will probably still work for 2.6, but developers will not be required to test their new code on that browser. Moodle, like most of the world's web sites and browser producers, encourages you to keep your browsers current to improve security and functionality while saving us valuable time. (For example see what Google is doing) http://docs.moodle.org/dev/Moodle_2.5_release_notes Requirements These are just minimums. We recommend keeping all your software updated. Recommended minimum browser: Google Chrome 11, Firefox 4, Safari 5, Internet Explorer 8 (IE 10 required for drag and drop of files from outside the browser into Moodle) Moodle upgrade: Moodle 2.2 or later (if upgrading from earlier versions, you must upgrade to 2.2.9 as a first step) Minimum DB versions: PostgreSQL 8.3, MySQL 5.1.33, MariaDB 5.2, MSSQL 2005 or Oracle 10.2 (oci_native_moodle_package.sql needs to be executed before upgrade on Oracle servers) Minimum PHP version: PHP 5.3.3 New PHP extension requirements: GD NOTE: We will drop support for IE8 in Moodle 2.6 (to be released November 2013). This means IE8 will probably still work for 2.6, but developers will not be required to test their new code on that browser. Moodle, like most of the world's web sites and browser producers, encourages you to keep your browsers current to improve security and functionality while saving us valuable time. (For example see what Google is doing) I just noticed that although it's in a section titled "Requirements" and in a list of other things which are hard requirements (presumably you get warned if you use a DB or PHP version that's too old) it actually only says "Recommended minimum" which is a bit vague about whether the emphasis is on "minimum" or "recommended".
          Hide
          Martin Dougiamas added a comment -

          I'm not seeing the problem...

          As it says in the release notes, developers are not supporting old browsers.

          That does not means Moodle does not, it may well work fine, but as we are not explicitly writing for them or testing on them we don't know and can't say.

          It would be stupid to actively prevent poor users who might be using an older version for whatever reason, and likewise dumb to remove perfectly working older code.

          I'm not sure what else you are looking for here.

          Show
          Martin Dougiamas added a comment - I'm not seeing the problem... As it says in the release notes, developers are not supporting old browsers. That does not means Moodle does not, it may well work fine, but as we are not explicitly writing for them or testing on them we don't know and can't say. It would be stupid to actively prevent poor users who might be using an older version for whatever reason, and likewise dumb to remove perfectly working older code. I'm not sure what else you are looking for here.
          Hide
          David Scotson added a comment -

          So I can add features in a way that affects IE6/Firefox3, and I can fix bugs in a way that affects IE6/Firefox3, and no-one will know anyway because no testing will be done on IE6/Firefox3, and this has been the case for the last three years, but if I know that IE6/Firefox3 is going to be impacted by a performance improvement then it's not allowed, even if it's only a minor visual change? Doesn't that seem a bit Catch-22?

          Because, to be clear, I'm not proposing these changes out of some abstract desire for neatness or a blood vendetta against IE6 and Firefox 3. These lines of CSS have a direct impact on Moodle's performance. We've got code in Moodle that removes unnecessary spaces and semi-colons from the CSS before we send it to users in order to wring out every last possible size reduction and therefore performance increase, while at the same time we've got lines of CSS that do nothing (literally: https://github.com/moodle/moodle/blob/master/blocks/tags/styles.css) and hundreds of lines targeting IE6, Firefox 3, Safari 5.0 etc. often for minor visual flair like rounded corners or box shadows, or making a drop-down box take up the full width of its container.

          I would have thought many of these kind of changes would be an acceptable trade-off for even currently supported browsers like IE8, and just obvious low-hanging performance improvements for browsers that are no longer supported.

          Show
          David Scotson added a comment - So I can add features in a way that affects IE6/Firefox3, and I can fix bugs in a way that affects IE6/Firefox3, and no-one will know anyway because no testing will be done on IE6/Firefox3, and this has been the case for the last three years, but if I know that IE6/Firefox3 is going to be impacted by a performance improvement then it's not allowed, even if it's only a minor visual change? Doesn't that seem a bit Catch-22? Because, to be clear, I'm not proposing these changes out of some abstract desire for neatness or a blood vendetta against IE6 and Firefox 3. These lines of CSS have a direct impact on Moodle's performance. We've got code in Moodle that removes unnecessary spaces and semi-colons from the CSS before we send it to users in order to wring out every last possible size reduction and therefore performance increase, while at the same time we've got lines of CSS that do nothing (literally: https://github.com/moodle/moodle/blob/master/blocks/tags/styles.css ) and hundreds of lines targeting IE6, Firefox 3, Safari 5.0 etc. often for minor visual flair like rounded corners or box shadows, or making a drop-down box take up the full width of its container. I would have thought many of these kind of changes would be an acceptable trade-off for even currently supported browsers like IE8, and just obvious low-hanging performance improvements for browsers that are no longer supported.
          Hide
          Marina Glancy added a comment -

          Martin, I asked David to create the policy issue because he submitted for integration the issues removing '.ie6', '.ie7', etc. from core CSS. I asked in devchat if this change was discussed by frontend team and it turned out that it was not.
          https://moodle.org/local/chatlogs/index.php?conversationid=13851#c482125

          It is obvious that we do not promise everything working smooth in ie6 and ie7 and even ie8 but the question is - does FRONTEND team agree to remove existing CSS. If yes, should we remove it from core/plugins only or from core/plugins AND themes.

          There was suggestion from Andrew Nicols that I personally liked - to move all such code to the separate css file.

          P.S. I'm not biased to any decision, I never use Windows and don't care about IE of any version. If you give green light to removing this CSS I will gladly integrate all those issues

          P.P.S. I don't think the title of the issue is correct, it's not about supporting, it's about removing CSS.

          Show
          Marina Glancy added a comment - Martin, I asked David to create the policy issue because he submitted for integration the issues removing '.ie6', '.ie7', etc. from core CSS. I asked in devchat if this change was discussed by frontend team and it turned out that it was not. https://moodle.org/local/chatlogs/index.php?conversationid=13851#c482125 It is obvious that we do not promise everything working smooth in ie6 and ie7 and even ie8 but the question is - does FRONTEND team agree to remove existing CSS . If yes, should we remove it from core/plugins only or from core/plugins AND themes. There was suggestion from Andrew Nicols that I personally liked - to move all such code to the separate css file. P.S. I'm not biased to any decision, I never use Windows and don't care about IE of any version. If you give green light to removing this CSS I will gladly integrate all those issues P.P.S. I don't think the title of the issue is correct, it's not about supporting, it's about removing CSS.
          Hide
          Martin Dougiamas added a comment - - edited

          Ok so if there really is a performance improvement (and this data should be MEASURED and PUBLISHED to justify this) then I'm all for it.

          The existing policy says you don't have to worry about testing on those old browsers. Ideally I would still hope the impact on them is minimized if possible, but no support means no support and old browsers will just degrade, bit by bit.

          If the performance improvements are very tiny then I would say it's not worth it. If it's not broken don't fix it.

          Show
          Martin Dougiamas added a comment - - edited Ok so if there really is a performance improvement (and this data should be MEASURED and PUBLISHED to justify this) then I'm all for it. The existing policy says you don't have to worry about testing on those old browsers. Ideally I would still hope the impact on them is minimized if possible, but no support means no support and old browsers will just degrade, bit by bit. If the performance improvements are very tiny then I would say it's not worth it. If it's not broken don't fix it.
          Hide
          David Scotson added a comment -

          I don't think I can justify the effort involved to prove a performance increase beyond an unspecified lower limit every time I delete a line of CSS intended for unsupported browsers. As I mention in the parent of the linked bugs (MDL-39094), I don't think there's any one change that'll make a massive difference on its own, but the reduction in CSS sizes are cumulative, so I'll move onto other issues.

          If there's some planned cutoff date in the future when particular browser versions (in particular IE6, IE7, Firefox 3.6, Chrome4/Safari 4.0, Chrome9/Safari 5.0) move into the region where you can delete their CSS without having to make a case for it then let me know and I'll mark the bugs to be revisited at that point, or at the end of each dev cycle.

          Show
          David Scotson added a comment - I don't think I can justify the effort involved to prove a performance increase beyond an unspecified lower limit every time I delete a line of CSS intended for unsupported browsers. As I mention in the parent of the linked bugs ( MDL-39094 ), I don't think there's any one change that'll make a massive difference on its own, but the reduction in CSS sizes are cumulative, so I'll move onto other issues. If there's some planned cutoff date in the future when particular browser versions (in particular IE6, IE7, Firefox 3.6, Chrome4/Safari 4.0, Chrome9/Safari 5.0) move into the region where you can delete their CSS without having to make a case for it then let me know and I'll mark the bugs to be revisited at that point, or at the end of each dev cycle.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: