2 Feb
2010
2 Feb
'10
9:42 p.m.
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/