How should we organise less in a plugin

How should we organise less in a plugin

le Sam Hemelryk -
Number of replies: 3

There are a lot of advantages to less over CSS, and its adoption into the Moodle core themes has been well received. As a plugin developer I want to be able to use less in my plugins, I am particularly keen on the organisation it provides as I believe it better conveys my design intentions during development.
Of course I am well aware that I can use less within my own plugin any which way I want. The purpose of this post is to perhaps generate a bit of discussion about how it could best be done so that we can ask Moodle HQ to include it in the coding style docs as a convention.

Personally I think its really important that we don't start discussing whether less should be automatically compiled into styles.css or anything along those lines as at that point there are a lot of questions and technical discussions.
I think the focus should be on simply where to put it so that we can start including it with confidence.

At present Moodle has no conventions for including less within a plugin.
This means that:

  • No less can be added to any core plugin. Without a properly discussed and documented convention that would be a hard sell.
  • I can't be sure how to add less to our own plugins because we want to take Moodles approach so as to have consistency of knowledge.

Personally I think that we should use a less directory within the plugin root directory that contains any less the plugin has and most importantly a styles.less file that is the build point for all of the plugins less.
If a plugin wishes to have theme specific styles then there should also be styles_themename.less to generate the corresponding styles_themename.css.
There should be no importation of less from outside of the plugin. This could not be considered safe as it adds dependencies for the plugin.
As mentioned above I don't think plugin less files should be automatically compiled by Moodle when generating the full CSS. This can be discussed on MDL-45482.
Mitigating the risk of an unknowning developer/designer modifying the styles.css file for a plugin with less I think is an important consideration. My feeling on it are that compiling in the same way Moodle compiles the bootstrap less is going to be enough as the compressed CSS should be a giveaway that there is a build process. From there we would just rely on institutional knowledge that if a less directory exists the CSS is generated.
That raising one more point, under no circumstances should a plugin use less to generate part only part of the CSS. It should be all less generated or not.

Cheers
Sam

Average of ratings: -
In reply to Sam Hemelryk

Re: How should we organise less in a plugin

le Sam Hemelryk -
For reference my interest in this came about through MDL-36296 wherein I have reorganised the CSS in the navigation block making it simpler and fixing a few bugs.
I did so using less, that will will not land to core because of a lack of convention. I feel this won't be the last time it comes up and would like to see a convention established for the future.
In reply to Sam Hemelryk

Re: How should we organise less in a plugin

le Brian Barnes -

Hi Sam,

In general I like the idea, but there are some potential issues with IE. IE9 and below will only support 4095 selectors per file (and I expect some of the sites with a large number of plugins are likely to come across this issue - I'm not opposed to dropping support of IE9 :D), whereas IE10 and up support 65534 selectors per file (possible, but highly unlikely to exceeded). The source for this is at http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/internet-explorer-stylesheet-rule-selector-import-sheet-limit-maximum.aspx

As an extension to this, it's been crossing my mind whether it is worth using less in our themes, but haven't devoted too much time to it as it appears that Moodle combines and minifies them anyway when in production mode.

In reply to Sam Hemelryk

Re: How should we organise less in a plugin

le Dan Poltawski -

An interesting thought is that if we go for grunt I think that we would be able to support this kind of thing quite nicely with the use of distributed gruntfiles (assuming you can do that!) for relevant plugins. I think this would work well for core - because we would be able to verify programmatically  if someone modified the built file but not the source file.