Yeah, but not with that short syntax. An ID in front of every declaration is ugly as hell and not very forgiving of file size either.
On Jan 20, 6:56 pm, Eric Garside <gars...@gmail.com> wrote: > You can do that now... > > #myPreciousWidget.title // Matches <div id="myPreciousWidget" > class="title"> > > or > > #myPreciousWidget .title // Matches <div id="myPreciousWidget"><div > class="title"></div></div> > > Also, I'm not sure I understand your issue exactly. How did you manage > to create site-specific CSS that has the same classes as the plugin's > css? > > And at the risk of sounding like those guys who say if you practiced a > real guitar instead of guitar hero you'd be good at a real guitar: In > the time it's taken you to defend your position, you could have > probably rewritten your CSS correctly. :\ > > On Jan 20, 3:02 pm, Ricardo Tomasi <ricardob...@gmail.com> wrote: > > > 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