LessPHP

Hey all,

I have created a new branch on Github, where I am experimenting with LessPHP for the CSS rendering. There is still a lot to work to do in terms of how much we lock down in the mandatory file names like the current css system. Also files from Core etc. may/will need updating. Potentially Admin too...

For now, if you are requesting styles.css and the new option under CSS is set to yes, use Less, the css class will cycle through all installed plugins. If it finds a less directory, it will grab all the files in there and adds them to the file (note this happens in alphabetical order, more on this in sec), if it doesn't then it grabs the standard style.css. It then parses the Less code and outputs the files with the usual caching mechanisms in place.

Points of note:
It current doesn't work on Less' @import function, to bring in nested files. This has to do with Less, seemingly, only dealing with relative file paths and braking on absolute ones. I have an idea on how to tackle this but wondering it is needed, as I suspect the best course of action will be to just use specific file names in the future like standard css does.
Also it doesn't seem to remove duplicate declarations like the current CSS optimiser does.

I am keen for some feedback as to whether this is a good direction for us to head in.

I started this, this weekend as I am using Twitter's Bootstrap (loving it btw) on a project and the Github files use Less. I like the way they have a Variables file that sets all the colors, fonts etc. Also the use of grids and responsive grids as variable based stuff. (I'm actually thinking of making the bootstrap stuff options to include in a project like we did with boilerplate, as it gives you a great headstart on a new project)

Please any comment on the above ramblings would be appreciated.

Hey all, I have created a new branch on Github, where I am experimenting with LessPHP for the CSS rendering. There is still a lot to work to do in terms of how much we lock down in the mandatory file names like the current css system. Also files from Core etc. may/will need updating. Potentially Admin too... For now, if you are requesting styles.css and the new option under CSS is set to yes, use Less, the css class will cycle through all installed plugins. If it finds a less directory, it will grab all the files in there and adds them to the file (note this happens in alphabetical order, more on this in sec), if it doesn't then it grabs the standard style.css. It then parses the Less code and outputs the files with the usual caching mechanisms in place. Points of note: It current doesn't work on Less' @import function, to bring in nested files. This has to do with Less, seemingly, only dealing with relative file paths and braking on absolute ones. I have an idea on how to tackle this but wondering it is needed, as I suspect the best course of action will be to just use specific file names in the future like standard css does. Also it doesn't seem to remove duplicate declarations like the current CSS optimiser does. I am keen for some feedback as to whether this is a good direction for us to head in. I started this, this weekend as I am using Twitter's Bootstrap (loving it btw) on a project and the Github files use Less. I like the way they have a Variables file that sets all the colors, fonts etc. Also the use of grids and responsive grids as variable based stuff. (I'm actually thinking of making the bootstrap stuff options to include in a project like we did with boilerplate, as it gives you a great headstart on a new project) Please any comment on the above ramblings would be appreciated.

Nice... it'd be great if we could just filter the CSS content through a LessPHP filter before output/cache but best practice has the Less files having their own extension and Jojo's pluginFiles function can't wildcard.

Nice... it'd be great if we could just filter the CSS content through a LessPHP filter before output/cache but best practice has the Less files having their own extension and Jojo's pluginFiles function can't wildcard.

Interesting concept and would be possible. Though we would have to fix a few bug with CSS optimiser.

Interesting concept and would be possible. Though we would have to fix a few bug with CSS optimiser.

It needs tweaked anyway to allow some CSS3 things through I think. Maybe font and media queries, I can't remember. I can't remember what the optimiser is like but if it was summer I'd happily set aside a weekend and a few beers to mingle with oh-crap-why-did-I-sign-up-for-this regular expressions.

I think I'm gate crashing GHWeb late next month for a day or two and was wondering what to do with my time. I had thought about general code cleanup or starting a plugin manifesto/dependencies system, but I could have a look at this. Either that or I'll throw paper darts at everyone. Eyes will be lost.

I thought about Less ages ago but never got past this issue... I didn't want to simply push all files through the filtering because that'd be against best practice of letting less files have their own extension. But I wanted to offer less processing to every file, whether combined or called separately (eg hook into the end of css.php). I didn't have an immediate need for it and had even less time so I put it on my "come back to later" list and forgot about it. It's getting to be a very long list :(

It needs tweaked anyway to allow some CSS3 things through I think. Maybe font and media queries, I can't remember. I can't remember what the optimiser is like but if it was summer I'd happily set aside a weekend and a few beers to mingle with oh-crap-why-did-I-sign-up-for-this regular expressions. I think I'm gate crashing GHWeb late next month for a day or two and was wondering what to do with my time. I had thought about general code cleanup or starting a plugin manifesto/dependencies system, but I could have a look at this. Either that or I'll throw paper darts at everyone. Eyes will be lost. I thought about Less ages ago but never got past this issue... I didn't want to simply push all files through the filtering because that'd be against best practice of letting less files have their own extension. But I wanted to offer less processing to every file, whether combined or called separately (eg hook into the end of css.php). I didn't have an immediate need for it and had even less time so I put it on my "come back to later" list and forgot about it. It's getting to be a very long list :(

In regards to integrating Bootstrap, I like the idea. But does it conflict with Boilerplate?

I even thought about rebuilding Jojo's back end with Bootstrap but I'd like to keep the back end so that it can be completely modified just by CSS and putting it into a grid system wouldn't do that. Though we could just use the components and not the grid.

What we need to do is integrate Boilerplate and Bootstrap in such a way that they're both easily updatable with changes from upstream and so that we can toggle extras on and off (eg Bootstrap's Javascript plugins and their CSS, except for any required by the core). Do we make them plugins? Ideally Bootstrap would be configurable in regards to what components get included and I thought there were hooks in jojo_core/classes/Jojo/Plugin/Core/Css.php and Js.php to pragmatically attach files to styles.css and common.js but there aren't. We could add these easily but before I do I'd like to fully assess the needs.

Ultimately I (I say I because nobody else has mentioned anything, feel free to chip in) would like to make it flexible enough so that via Options or Plugins we could INDEPENDENTLY enable or disable:

• HTML5 doctype
• Modernizr
• Boilerplate Reset

Now that I think about it, Bootstrap might be a good one to base Jojo on. If we don't use the grid styles but still use all the others across the core and plugins then we'll have a nice consistent set of styles that we can still override in an even and consistent way. This could standardise the (possibly html5) markup across the core and plugins and mean we don't have to override similar styles from multiple plugins.

It sounds like a goal for a future major release since it would break compatibility and as such would require an "all-in" approach so we don't end up still focussing on the old version like we did with mikec's trunk updates. Is HTML5 and CSS3 (along with the required shims) ready?

[Edit:] I'm happy to work through the core and plugins doing this, though it'll take time and could save Tom a dart in the ear.

In regards to integrating Bootstrap, I like the idea. But does it conflict with Boilerplate? I even thought about rebuilding Jojo's back end with Bootstrap but I'd like to keep the back end so that it can be completely modified just by CSS and putting it into a grid system wouldn't do that. Though we could just use the components and not the grid. What we need to do is integrate Boilerplate and Bootstrap in such a way that they're both easily updatable with changes from upstream and so that we can toggle extras on and off (eg Bootstrap's Javascript plugins and their CSS, except for any required by the core). Do we make them plugins? Ideally Bootstrap would be configurable in regards to what components get included and I thought there were hooks in jojo_core/classes/Jojo/Plugin/Core/Css.php and Js.php to pragmatically attach files to styles.css and common.js but there aren't. We could add these easily but before I do I'd like to fully assess the needs. Ultimately I (I say I because nobody else has mentioned anything, feel free to chip in) would like to make it flexible enough so that via Options or Plugins we could INDEPENDENTLY enable or disable: [list] [*]HTML5 doctype [*]Modernizr [*]Boilerplate Reset[/list] Now that I think about it, Bootstrap might be a good one to base Jojo on. If we don't use the grid styles but still use all the others across the core and plugins then we'll have a nice consistent set of styles that we can still override in an even and consistent way. This could standardise the (possibly html5) markup across the core and plugins and mean we don't have to override similar styles from multiple plugins. It sounds like a goal for a future major release since it would break compatibility and as such would require an "all-in" approach so we don't end up still focussing on the old version like we did with mikec's trunk updates. Is HTML5 and CSS3 (along with the required shims) ready? [Edit:] I'm happy to work through the core and plugins doing this, though it'll take time and could save Tom a dart in the ear.

With regards to how I've currently implemented Less:

Standard CSS files are being parsed through Less. I just realized that reading through everything above. Basically going through the list of plugins, if there isn't a less folder, it grabs the css file. After concatenating the files, it runs it through the parser so it would be possible to have less syntax in a css file. Potentially meaning a simpler idea would be to just use the standard CSS scripts and just parsing the Less pre optimisation.

The thing I think that is important with less is the order the files are grabbed. I can see docs on this currently but I think all your variables need to be at the top of the list so they can be applied later. At least this is the way the less projects I have looked at are structured. Creating a variables.less (or .css for that mater) that can sit in your theme and gets pulled first would be the best solution. Bootstrap has about 3 files it pulls first to set variables, mixins etc.

With regards to boilerplate/bootstrap intgration:

They actually both base there reset code on normalize.css so which ever you use is pretty much OK. Though CSS optimize in Jojo currently strips a good deal of normalize.css when it parses it. I'll talk current optimizer bugs that I know of in a sec.

Both Boilerplate and Bootstrap have a customize build processes for their download, though bootstrap includes more since it is trying to do more than boilerplate. My idea is when implementing bootstrap integration is to setup lots of options that basically mimic the bootstrap custom download, check it out here. This way you can just include what you need for each project. Including the Carousel for example would include both the JS and CSS/Less required.

CSS optimiser bugs I know of:

As mentioned above, nesting of styles inset a media query or other CSS3 rule set breaks. It appears that the final closing } is being stripped as it is seeing }} as a mistake.
The other thing is in some CSS hacks that normalize.css employs. In particular the asterisk hacks for IE7 and below are stripped. To see this in action at the top of the boilerplate_reset.css file in Jojo_Core has a block:
audio,
canvas,
video {
display: inline-block;
*display: inline;
*zoom: 1;
}
this renders after optimisation as (magnification removed):
audio,
canvas,
video {
display: inline-block;
}

If I can I'd be very keen to sit down for a hack session on it at GHWeb while your here but I potentially might be on a full time contract by then. Though I might have to make my regex skills become existent by then. Either way, we need to catch up for a beer.

I think that is about it for my extended two cents.

ps. yes! session timed out before I submitted this. Glad I learnt the lesson of copying everything before hitting submit.

With regards to how I've currently implemented Less: Standard CSS files are being parsed through Less. I just realized that reading through everything above. Basically going through the list of plugins, if there isn't a less folder, it grabs the css file. After concatenating the files, it runs it through the parser so it would be possible to have less syntax in a css file. Potentially meaning a simpler idea would be to just use the standard CSS scripts and just parsing the Less pre optimisation. The thing I think that is important with less is the order the files are grabbed. I can see docs on this currently but I think all your variables need to be at the top of the list so they can be applied later. At least this is the way the less projects I have looked at are structured. Creating a variables.less (or .css for that mater) that can sit in your theme and gets pulled first would be the best solution. Bootstrap has about 3 files it pulls first to set variables, mixins etc. With regards to boilerplate/bootstrap intgration: They actually both base there reset code on normalize.css so which ever you use is pretty much OK. Though CSS optimize in Jojo currently strips a good deal of normalize.css when it parses it. I'll talk current optimizer bugs that I know of in a sec. Both Boilerplate and Bootstrap have a customize build processes for their download, though bootstrap includes more since it is trying to do more than boilerplate. My idea is when implementing bootstrap integration is to setup lots of options that basically mimic the bootstrap custom download, check it out [url=http://twitter.github.com/bootstrap/download.html]here[/url]. This way you can just include what you need for each project. Including the Carousel for example would include both the JS and CSS/Less required. CSS optimiser bugs I know of: As mentioned above, nesting of styles inset a media query or other CSS3 rule set breaks. It appears that the final closing } is being stripped as it is seeing }} as a mistake. The other thing is in some CSS hacks that normalize.css employs. In particular the asterisk hacks for IE7 and below are stripped. To see this in action at the top of the boilerplate_reset.css file in Jojo_Core has a block: [code] audio, canvas, video { display: inline-block; *display: inline; *zoom: 1; }[/code] this renders after optimisation as (magnification removed): [code] audio, canvas, video { display: inline-block; }[/code] If I can I'd be very keen to sit down for a hack session on it at GHWeb while your here but I potentially might be on a full time contract by then. Though I might have to make my regex skills become existent by then. Either way, we need to catch up for a beer. I think that is about it for my extended two cents. ps. yes! session timed out before I submitted this. Glad I learnt the lesson of copying everything before hitting submit.

Awesome, your ideas for a full raft of options for Bootstrap mimic what I was thinking. And for variables/mixins etc files we could make those get pulled in and stitched in styles.css after the reset but before the rest. Another reason to make nestable Options categories (my ideas list is very long).

The optimiser sounds like a good project, and the beer too. I'm flat tack busy at the moment but am looking forward to taking a break and working on Jojo itself when I come up in June. If you're free at the time then that'd be great, but perfectly understandable if you're not.

Also, I've been meaning to find where the session timeout is set and have come across two possible fixes, implemented one on my server then forgot about it. Will keep you updated. I think it's the session garbage collection rather than the cookie expiring.

Awesome, your ideas for a full raft of options for Bootstrap mimic what I was thinking. And for variables/mixins etc files we could make those get pulled in and stitched in styles.css after the reset but before the rest. Another reason to make nestable Options categories (my ideas list is very long). The optimiser sounds like a good project, and the beer too. I'm flat tack busy at the moment but am looking forward to taking a break and working on Jojo itself when I come up in June. If you're free at the time then that'd be great, but perfectly understandable if you're not. Also, I've been meaning to find where the session timeout is set and have come across two possible fixes, implemented one on my server then forgot about it. Will keep you updated. I think it's the session garbage collection rather than the cookie expiring.

Just a quick question that occurred to me last night.

The CSS optimizer appears to be partially trying to correct CSS syntax mistakes, hence stripping a double }} etc. Do we really need it to do that? Could it not just take it that we know what we are doing and just look for duplicate style declarations?

If we make a mistake in our code then we should be able to find it in testing right?

Just a quick question that occurred to me last night. The CSS optimizer appears to be partially trying to correct CSS syntax mistakes, hence stripping a double }} etc. Do we really need it to do that? Could it not just take it that we know what we are doing and just look for duplicate style declarations? If we make a mistake in our code then we should be able to find it in testing right?

It used to do even more... Eg change "colour" to "color" but that broke image paths sometimes. Those fixes were added with the best of intentions but I don't mind them being removed and the optimiser trusting us a little more. Can't speak for the others though. It'll be stripping the "*property" IE hacks like you said, too.

It used to do even more... Eg change "colour" to "color" but that broke image paths sometimes. Those fixes were added with the best of intentions but I don't mind them being removed and the optimiser trusting us a little more. Can't speak for the others though. It'll be stripping the "*property" IE hacks like you said, too.

Hi Jai, what method did you use for the externals when migrating? I'm still learning Git and found modules/submodules but it doesn't look like that.

I've integrated CSSTidy (new branch) but haven't done the external.

CSSTidy compresses slightly further than the old optimizer and respects CSS3 features (including @media) and hacks.

Hi Jai, what method did you use for the externals when migrating? I'm still learning Git and found modules/submodules but it doesn't look like that. I've integrated CSSTidy (new branch) but haven't done the external. CSSTidy compresses slightly further than the old optimizer and respects CSS3 features (including @media) and hacks.

Well found on the CSSTidy lib. I was wondering if there was a script out there that we could use.

I used submodules. Great article on how it works here.

The Jojo Plugins repo you created is using the same thing.

Well found on the CSSTidy lib. I was wondering if there was a script out there that we could use. I used submodules. [url=http://git-scm.com/book/en/Git-Tools-Submodules]Great article on how it works here[/url]. The Jojo Plugins repo you created is using the same thing.

Actually, I just realized that CSSTidy doesn't have a git hosting to pull in as a submodule. In these instances I have just been adding a version directly into the repo and it doesn't dynamically pull in updates.

Though theoretically it could be done as it does have an SVN repo...

Actually, I just realized that CSSTidy doesn't have a git hosting to pull in as a submodule. In these instances I have just been adding a version directly into the repo and it doesn't dynamically pull in updates. Though theoretically it could be done as it does have an SVN repo...

Hehe, Rick it appears we're working on this at the same time. AND you found a github repo for it.

Hehe, Rick it appears we're working on this at the same time. AND you found a github repo for it.

I did lots of searching for CSS minifiers then found everyone was using "compressor." I tried a few and CSSTidy performed the best. I feel kind of bad for replacing a section of Jojo, but if there's an existing project that focuses on that one task and does it better then why not.

I got myself confused with submodules... I had thought that there were submodules in the /externals/ folder after the migration but there isn't. What confused me further was that submodules aren't automatically downloaded when you clone a repo. I'm slowly getting the hang of it now.

I did lots of searching for CSS minifiers then found everyone was using "compressor." I tried a few and CSSTidy performed the best. I feel kind of bad for replacing a section of Jojo, but if there's an existing project that focuses on that one task and does it better then why not. I got myself confused with submodules... I had thought that there were submodules in the /externals/ folder after the migration but there isn't. What confused me further was that submodules aren't automatically downloaded when you clone a repo. I'm slowly getting the hang of it now.

And I had that post sitting there but forgot to post it until I went back to my browser. Was fighting with/testing Git.

Yeah I was fiddling round with it at the time. Slowly. I can't remember how I found its Github repo but it was more up-to-date than the SVN repo I found.

Feel free to try it out or merge it with your LessPHP branch and let me know what you think.

And I had that post sitting there but forgot to post it until I went back to my browser. Was fighting with/testing Git. Yeah I was fiddling round with it at the time. Slowly. I can't remember how I found its Github repo but it was more up-to-date than the SVN repo I found. Feel free to try it out or merge it with your LessPHP branch and let me know what you think.

Actually I merged your csstidy branch with my lessphp one. Another interesting learning curve with git. The learning curves are frustrating but feels like it is worth it with the power of us trying different things in a transparent way.

Anyway, it seems pretty good though misses one thing that Jojo's optimize does really well. It removes duplicated properties from within a single rule but not across multiple declarations of the rule.

Classic example I come across often is the contact plugin declares this:
form.contact-form label {
float: left;
width: 150px;
display: block;
text-align: right;
margin-right: 5px;
margin-bottom: 3px;
}
But I often over ride the width the theme:
form.contact-form label {
width: 200px;
}
The result is that form.contact-form label is declared twice but the width property is removed from the first contact plugin declaration. None of the other optimisers seem to do this.

Maybe it isn't important?

Actually I merged your csstidy branch with my lessphp one. Another interesting learning curve with git. The learning curves are frustrating but feels like it is worth it with the power of us trying different things in a transparent way. Anyway, it seems pretty good though misses one thing that Jojo's optimize does really well. It removes duplicated properties from within a single rule but not across multiple declarations of the rule. Classic example I come across often is the contact plugin declares this: [code]form.contact-form label { float: left; width: 150px; display: block; text-align: right; margin-right: 5px; margin-bottom: 3px; }[/code] But I often over ride the width the theme: [code]form.contact-form label { width: 200px; }[/code] The result is that [code]form.contact-form label[/code] is declared twice but the width property is removed from the first contact plugin declaration. None of the other optimisers seem to do this. Maybe it isn't important?

That's odd, I'm sure it did, I'll play round again. I do the same thing so it's going to be a feature I'm keen to keep. Might need to look at updating the old optimizer afterall, or maybe look at updating CSSTidy. It had various compression options, I'll look through those.

That's odd, I'm sure it did, I'll play round again. I do the same thing so it's going to be a feature I'm keen to keep. Might need to look at updating the old optimizer afterall, or maybe look at updating CSSTidy. It had various compression options, I'll look through those.

So it looks like the seemingly outdated SVN version of CSSTidy does remove duplicates, while the seemingly more current Git version does not.

Attached is a copy of a random stylesheet (with some random code added to test @media rules and multiple backgrounds.) I ran it through both the SVN and Git versions using default options then did some basic line-break formatting on them for readability.

The Git version
+ Removes the last ";" from each rule set
+ Allows multiple backgrounds
- Does NOT remove duplicate properties from separate selectors
? Semi orders the properties

The SVN version
+ Removes duplicate properties from separate selectors
- Does NOT allow multiple backgrounds
- Leaves spaces between fonts in font families
? Drops any brackets from @media selectors
? Moves @media rules to the end of the file

I'm comparing the code between the two now.

[Edit: Forgot to attach the files, was too busy comparing the source files]

So it looks like the seemingly outdated [url=http://csstidy.sourceforge.net/]SVN version[/url] of CSSTidy does remove duplicates, while the seemingly more current [url=https://github.com/Cerdic/CSSTidy]Git version[/url] does not. Attached is a copy of a random stylesheet (with some random code added to test @media rules and multiple backgrounds.) I ran it through both the SVN and Git versions using default options then did some basic line-break formatting on them for readability. The Git version [b]+[/b] Removes the last ";" from each rule set [b]+[/b] Allows multiple backgrounds [b]-[/b] Does NOT remove duplicate properties from separate selectors [b]?[/b] Semi orders the properties The SVN version [b]+[/b] Removes duplicate properties from separate selectors [b]-[/b] Does NOT allow multiple backgrounds [b]-[/b] Leaves spaces between fonts in font families [b]?[/b] Drops any brackets from @media selectors [b]?[/b] Moves @media rules to the end of the file I'm comparing the code between the two now. [Edit: Forgot to attach the files, was too busy comparing the source files]

FIXED

It took a while (read hours) to find the ONE LINE that made all the difference. In the end it was a throwaway line amongst the most re-written function I found.

Anyway, I forked/fixed the repo and since the current Git repo for CSSTidy hasn't pulled in a simple change pull request I changed the submodule in the csstidy-integration branch to the new repo.

Feel free to merge it into your LessPHP branch again, you'll probably hit a conflict on .gitmodules when you do though.

FIXED It took a while (read hours) to find the ONE LINE that made all the difference. In the end it was a throwaway line amongst the most re-written function I found. Anyway, I forked/fixed the repo and since the current Git repo for CSSTidy hasn't pulled in a simple change pull request I changed the submodule in the csstidy-integration branch to the new repo. Feel free to merge it into your LessPHP branch again, you'll probably hit a conflict on .gitmodules when you do though.

Rick FTW!

Going to go test now.

Rick FTW! Going to go test now.