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
