New less organization

[bouks]

I suggest we organize less files better, then we can change and/or optimize easily each part.

• one folder for each component (base, formedit, inlineedit, modal, subgrid, treegrid...)
• in each folder, separation of colors, fonts, positionning and sizes rules.

Here's a proposal (it can be improved)

https://github.com/bouks/jsgrid/tree/master/less_proposal

[meh-uk]

Doesn't this add complexity due to more files?

[bouks]

On the contrary, it is simpler when working css due to separation... maybe like Single Responsability or MVC patterns in coding.

[meh-uk]

That's a good point, moving to 2.0 as I'd quite like to make a release and this can wait :).

[bouks]

I think if we agree with this, we can implement now. There is no changes in the rules, on separation.
But need to adapt the build and why not the download builder to reduce css file size.

[bouks]

Fast and simple optimization :
bouks@e9fed03

[flack]

I must admit I've never been a fan of the philosophy of separating CSS rules into different "roles" like colors, positioning etc. I've seen this used on some (mostly quite old) projects, but it always ended up making things more confusing.

Usually, people say that this makes e.g. theming easier, because all the font stuff and all the colors are in one place and so on. While this may be true, it does not apply to our situation for a number of reasons:

• we do not want people to customize the look by changing our CSS file. They should do their customizations in a separate file, to avoid problems when updating
• the standard CSS file we ship does not really define colors, fonts etc. anyways, but mostly uses inherit to get the correct ones from the jquery ui theme
• grouping rules by function is only necessary in CSS because it doesn't support variables. So you put all places that have the same color next to each other so that you don't miss one when changing it. With LESS, we don't need that workaround, because we can simply define the color (or font size, etc.) in a variable. Usually, all variables are in a file called variables.less (for example: https://github.com/twbs/bootstrap/blob/master/less/variables.less), which gives you one convenient place to change everything at once.

It is a matter of taste of course, but for me, having five different files named pos.less and potentially four different files where each selector is defined ({color|font|pos|size}.less) does not sound simpler to maintain

[flack]

To give you an example:

CSS separated by roles:

/* color */
a
{
    color: red;
}
h1, p, button
{
    color: black
}
button
{
    border-color: black;
}

/* font */
a
{
    text-decoration: none;
}
h1, p, button
{
    font-family: Arial
}

The same in LESS with variables:

/* define variables */
@link-color: red;
@default-color: black;
@default-font: Arial;

/* apply rules */
a
{
    color: @link-color;
    text-decoration: none;
}
h1, p, button
{
    color: @default-color;
    font-family: @default-font;
}
button
{
    border-color: @default-color;
}

[bouks]

• we do not want people to customize the look by changing our CSS file. They should do their customizations in a separate file, to avoid problems when updating

But... people could contribute by proposing themes Some of them would like to change color or only fonts stuffs. It's, then, easier to do.

• the standard CSS file we ship does not really define colors, fonts etc. anyways, but mostly uses inherit to get the correct ones from the jquery ui theme

We talked about abandon of jqueryui theming, so we'll have to implement colors and fonts.
Also separation would easily permit to use others css frameworks for all OR only "one stuff". For example, jqueryui for colors and bootstrap for placing... or other combination.

• About grouping rules and less variables, it's not the same usage. I talk about readability and independency.

[bouks]

These are principles we apply in real coding (not really in this project but...), why not apply these in css ?

[bouks]

With this organization, i could fastly detect some redondances in css rules and remove them. Here :

bouks@e9fed03

So it can avoid easily useless overcharging rules.

[flack]

But... people could contribute by proposing themes Some of them would like to change color or only fonts stuffs. It's, then, easier to do.

But it would be even easier if they can do all their changes in one file, i.e. variables.less

We talked about abandon of jqueryui theming, so we'll have to implement colors and fonts.
Also separation would easily permit to use others css frameworks for all OR only "one stuff". For example, jqueryui for colors and bootstrap for placing... or other combination.

AFAIK, no other css framework uses the separation you propose. For example jquery ui and bootstrap both have one file per component, not separated colors/fonts/etc.

About grouping rules and less variables, it's not the same usage. I talk about readability and independency.

But don't you think that reading @default-color gives you a better explanation of what it does than black in my example? It is also easier to grep, and adds some semantic information.

These are principles we apply in real coding (not really in this project but...), why not apply these in css ?

I'm not sure that the MVC paradigm is a good model for CSS, since this is already inside the "V" layer. I would go more with the Single Responsibility Principle, i.e. one "class" (i.e. file) contains one piece of functionality (e.g. subgrid.less) and exposes an "interface" (i.e. variables) with which the functionality can be customized. With your separation proposal, the implementation of each piece of functionality will be spread out across multiple files, and have no interface.

I think reducing redundancies is a good thing, and I know that the files are currently not very well structured (because they still correspond a lot to Tony's CSS structure), but I'm still not convinced multiple files per module is the answer.

[bouks]

But it would be even easier if they can do all their changes in one file, i.e. variables.less

Sure, but what i propose doesn't exclude variables items. The conjonction of the two stuff is good.

AFAIK, no other css framework uses the separation you propose.

I'm not conducted by others doing or not doing a thing. Hope there's people thinking and doing different. I'm not a sheep. I'm not praying lords of frameworks. :) Today we talk about abandon jqueryui, so is it a good example ? Bootstrap is fashionable today, but tomorrow ?

But don't you think that reading @default-color gives you a better explanation of what it does than black in my example? It is also easier to grep, and adds some semantic information.

Like i said above : "what i propose doesn't exclude variables items". It's not the same purpose.

the implementation of each piece of functionality will be spread out across multiple files, and have no interface

Yes. But it permits to have a global and large view of the project (in css part of course)