Geez you really take heart at defending your solution don't you?
But you're not going to convince anyone that "find & replace" is good
programming practice. In a hopefully not far future CSS will allow
something like this:
#myPreciousWidget {
.title {
color:#FFF
}
.content {
padding: 5px;
margin: 20px;
float: yesplease;
}
}
and then all our problems will be solved.
I promise I'm actually leaving this thread now :)
On Jan 20, 5:34 pm, johny why <johny...@gmail.com> wrote:
> there is another well-established programming principle-- modularity.
> the idea is the less tightly-coupled components are, the easier it is
> to upgrade any one of them, or switch it out with a replacement. one
> technique to achieve modularity is to reduce the scope of variables--
> keep the variable-name within the procedure or module where it's used,
> rather than making it a global variable. those who want me to debug
> conflicts between the widget and site (rather than make the widget
> self-contained) would have me keep all my variables global. why not
> outlaw id's and classes while we're at it? that's really cheating,
> isn't it? only a non-programmer would use a cheap work-around like
> id's and classes!
>
> if the widget is self-contained, then i can upgrade or replace the
> widget without worrying about style conflicts. !important is like a
> modular variable-- it says 'hey website css, you can't mess with me.'
> that's in-keeping with the principle of modularity. what if tomorrow i
> want to switch to AListApart, or MenuMatic, or Uvumi, or LavaLamp?
> what if tomorrow i want to add a thermometer or calendar widget? would
> you have me open up firebug all over again, and work out the css
> conflicts every time i switch to a different widget? jeez, i wish i
> was getting paid by the hour for that!
>
> isn't jQuery itself based on the concept of encapsulating
> functionality in self-contained units? it would be quite a mess if
> individual jQuery plugins broke each other, would it not?
>
> i wonder if this is a cultural-gap? javascript does not support
> modularity very easily, as described in Haverbeke's "Eloquent
> JavaScript". he provides some techniques for achieving modularity in
> javascript here:http://eloquentjavascript.net/chapter9.html
