If we want to have more comments in the CSS we should use a minimizer for the CSS, so that they are removed (along with the spaces) from the version we serve to the client. Some CSS files we have already do this. Another problem with CSS is that we add / modify some rules to assure compatibility with some specific browser. A solution would be to have specific files (just like the one we have for IE6) for the browsers that need those properties, so that we don't have to comment on every lines what compatibility is used for. Having multiple files that do the same thing can be hard to manage and sometimes browsers share behavior (depending on the engine). Ex: In the patch above the scrolling was only for Chrome and Safari. And the big problem in my opinion is that rules come in packages. To fix one bug you would need to comment a line in a class that is dependent to a line from another class, etc, etc. Ex: In the patch above the widths matter because of the float:left. Plus the cascading inheritance behavior of CSS. Right now we use comments in CSS to group properties, to specify overriding, to specify the browser that needs the property or to mark the hack.

On Jan 21, 2010, at 8:43 PM, Ecaterina Valica wrote:

Another observations is that even if we had comments in the CSS, the only way to see them is through a text editor, tools like Firebug don't even show them while inspecting.

Not sure I understand what you mean... Java comments are not seen by users either.... they're not meant for that. Thanks -Vincent

On 01/21/2010 09:04 PM, Vincent Massol wrote:

All I know is that I see regularly regressions when devs touch the CSS and one reason I believe is because CSS files are not commented so you don't know why something was done in a given way and you change it, thus breaking some other part.

I doubt that the lack of comments is the cause of more than 2% of all the skin regressions that occurred. To bring the problem on a more familiar ground, imagine that you would have to change some program made of global variables, and not just that, global structs with overlapping memory zones. And there are 300 such variables. What amount of comments would you think would be enough to guarantee that somebody new to the program won't accidentally break something? Commenting the 49% is like commenting that one of the variables of such a global overlapping minefield, called MAX_NUMBER, should have a positive value. This is how CSS works. The very nature of selectors make it almost impossible to know what exactly will be side-affected when applied to a real HTML.

I have touched the CSS several times too and I know I was very uncomfortable every time since I didn't know where what I was touching was used and what were the rules governing what I was touching.

Maybe there are ways to write unit tests for CSS and if that existed it would be even better than commenting I agree (even though comments would still be needed to explain why something is done in given manner).

Thanks -Vincent

On Jan 21, 2010, at 8:36 PM, Ecaterina Valica wrote:

...

If we want to have more comments in the CSS we should use a minimizer for the CSS, so that they are removed (along with the spaces) from the version we serve to the client. Some CSS files we have already do this.

Another problem with CSS is that we add / modify some rules to assure compatibility with some specific browser. A solution would be to have specific files (just like the one we have for IE6) for the browsers that need those properties, so that we don't have to comment on every lines what compatibility is used for. Having multiple files that do the same thing can be hard to manage and sometimes browsers share behavior (depending on the engine). Ex: In the patch above the scrolling was only for Chrome and Safari.

And the big problem in my opinion is that rules come in packages. To fix one bug you would need to comment a line in a class that is dependent to a line from another class, etc, etc. Ex: In the patch above the widths matter because of the float:left. Plus the cascading inheritance behavior of CSS.

Right now we use comments in CSS to group properties, to specify overriding, to specify the browser that needs the property or to mark the hack.

-- Sergiu Dumitriu http://purl.org/net/sergiu/

On 02/02/2010 09:53 PM, Vincent Massol wrote:

On Feb 2, 2010, at 9:42 PM, Sergiu Dumitriu wrote:

...

On 01/21/2010 09:04 PM, Vincent Massol wrote:

...

All I know is that I see regularly regressions when devs touch the CSS and one reason I believe is because CSS files are not commented so you don't know why something was done in a given way and you change it, thus breaking some other part.

I doubt that the lack of comments is the cause of more than 2% of all the skin regressions that occurred. To bring the problem on a more familiar ground, imagine that you would have to change some program made of global variables, and not just that, global structs with overlapping memory zones. And there are 300 such variables. What amount of comments would you think would be enough to guarantee that somebody new to the program won't accidentally break something? Commenting the 49% is like commenting that one of the variables of such a global overlapping minefield, called MAX_NUMBER, should have a positive value.

This is how CSS works. The very nature of selectors make it almost impossible to know what exactly will be side-affected when applied to a real HTML.

I'm not focused on comment. What I'd like is that we find ways to reduce regressions.

Whenever I see some CSS change I cringe since I have no clue what's going to break. For example JV changes some CSS today to fix an issue. I couldn't help but wonder in my head is this wasn't going to break some other place. It's probably due to the fact that I don't have a visual representation in my head about how the different parts of our CSS affects different parts of the default XE.

In java code we have found ways to cope with this: - comments - automated tests - compartimented design (OO design)

I wonder if there are ways to improve our resistance to regression on the CSS side, and that we could put as best practices.

Not all CSS is inherently unstable, just the one we have so far. This is the main reason why I'm pushing for a clean skin that doesn't inherit the fragility from Dodo + the fragility from Albatross + the fragility from Toucan. We're responsible for the degree of overlapiness. So far, we've made the CSS a jungle. The Colibri cleanup helped here. What can be done to ensure a side-effect free CSS: - make sure the selectors are specific enough not to have unpredicted side effects - make sure the selectors are generic enough so that they continue to work when the targeted content is in a slightly different position, and they allow a new element to reuse these styles - standardize and document z-indexes - try to reuse existing styles as much as possible (reusing classname, accepting inherited styles if they are good enough instead of always overriding everything just for a little touch of personality) - reduce hacks - use !important sparingly

I don't often change CSS but when I do (or anyone else for that matter), I'd like some assurance that I'm not breaking something elsewhere (that breaks through complex rules of inheritance or reuse of the same class id, etc).

Thanks -Vincent

...

...

I have touched the CSS several times too and I know I was very uncomfortable every time since I didn't know where what I was touching was used and what were the rules governing what I was touching.

Maybe there are ways to write unit tests for CSS and if that existed it would be even better than commenting I agree (even though comments would still be needed to explain why something is done in given manner).

Thanks -Vincent

On Jan 21, 2010, at 8:36 PM, Ecaterina Valica wrote:

...

If we want to have more comments in the CSS we should use a minimizer for the CSS, so that they are removed (along with the spaces) from the version we serve to the client. Some CSS files we have already do this.

Another problem with CSS is that we add / modify some rules to assure compatibility with some specific browser. A solution would be to have specific files (just like the one we have for IE6) for the browsers that need those properties, so that we don't have to comment on every lines what compatibility is used for. Having multiple files that do the same thing can be hard to manage and sometimes browsers share behavior (depending on the engine). Ex: In the patch above the scrolling was only for Chrome and Safari.

And the big problem in my opinion is that rules come in packages. To fix one bug you would need to comment a line in a class that is dependent to a line from another class, etc, etc. Ex: In the patch above the widths matter because of the float:left. Plus the cascading inheritance behavior of CSS.

Right now we use comments in CSS to group properties, to specify overriding, to specify the browser that needs the property or to mark the hack.

-- Sergiu Dumitriu http://purl.org/net/sergiu/