21 Jan
2010
21 Jan
'10
9:04 p.m.
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 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.