[jQuery] Re: Solution To Many Of Your CSS Nightmares!
sadly, i doubt any other group will participate as passionately as the you geeks.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
From: johny why sadly, i doubt any other group will participate as passionately as the you geeks. You haven't met the css-discuss crowd. We're mild mannered milquetoasts compared to them. Wait until you see how *they* handle off-topic threads. :-) -Mike
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
thanks ricardo. you definitely understand specificity. your links confirm: A style that is designated as important will win out over contradictory styles of otherwise equal weight. and, if styles of equal weight both use !important, the last rule specified wins. http://www.htmlhelp.com/reference/css/structure.html#cascade but, as this thread has shown, id's + !important ensure the widget-css will almost always win (in the widget), and NEVER affect the site. no response i've seen in this thread has swayed me from my view that, in most cases, !important in widget-css is safe for the site, simple to use, and nearly infallible. 'nuff said. p.s. your link offers a scenario in which you might want to AVOID ! important: !important rules will override normal rules (in the browser-css), so authors are advised to use normal rules almost exclusively to ensure that users with special style needs are able to read the page. i don't agree-- i'm not going to sacrifice site richness and functionality for normal readers to accommodate special readers-- instead, i would provide alternate accessible pages for special readers, and go to town on my normal pages. (but that's a chat for another day).
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
--rendering problems of a widget, in my experience, could involve many, indeed EVERY attribute of every element in the widget. you declare your default stylesheet, then you declare your widget's sheet. if the widget is inheriting incorrectly from a parent element you've got a couple of ways around it. making every single line of the widget's CSS !important is probably the longest (not in terms of a find replace in n++, rather in terms of physical size). a nicer change would just be to give the widget's parent element an appropriate attribute val to reign in the -999px left-margin you originally gave it. --this solution is for cases where changing your default css, which will of course affect your main site rendering, is undesirable or impossible. for me, doing a global replace of ; with !important; takes about 1/2 a second. on the other hand, fine-tuning my main site css so that the widget and the site both look right could potentially take hours of trouble-shooting, trial-and-error, and juggling precedence, including specificity, order of declaration, id's and classes, and so on. the inheritance path really isn't that complicated, and if your stylesheet to that complex you don't fully understand it, inspecting an element in firebug to see where it's getting it's style from takes a couple of seconds. it's an ugly hack that has so many potential problems it's barely worth considering for anything but the simplest widget, and at that point why not just fix the widget's CSS properly. !important does not 'break' css-- it's part of the css language, intended to be used where appropriate. the last part of that sentence is the important bit! ;)
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
To me, 'important' is the 'goto' of CSS. On Jan 20, 6:22 am, ryan.joyce...@googlemail.com ryan.joyce...@googlemail.com wrote: --rendering problems of a widget, in my experience, could involve many, indeed EVERY attribute of every element in the widget. you declare your default stylesheet, then you declare your widget's sheet. if the widget is inheriting incorrectly from a parent element you've got a couple of ways around it. making every single line of the widget's CSS !important is probably the longest (not in terms of a find replace in n++, rather in terms of physical size). a nicer change would just be to give the widget's parent element an appropriate attribute val to reign in the -999px left-margin you originally gave it. --this solution is for cases where changing your default css, which will of course affect your main site rendering, is undesirable or impossible. for me, doing a global replace of ; with !important; takes about 1/2 a second. on the other hand, fine-tuning my main site css so that the widget and the site both look right could potentially take hours of trouble-shooting, trial-and-error, and juggling precedence, including specificity, order of declaration, id's and classes, and so on. the inheritance path really isn't that complicated, and if your stylesheet to that complex you don't fully understand it, inspecting an element in firebug to see where it's getting it's style from takes a couple of seconds. it's an ugly hack that has so many potential problems it's barely worth considering for anything but the simplest widget, and at that point why not just fix the widget's CSS properly. !important does not 'break' css-- it's part of the css language, intended to be used where appropriate. the last part of that sentence is the important bit! ;)
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
Uh... you realize that !important has no function in IE6, right? And
that it doesn't retain the same functionality in IE7? It's also an
extreme misuse of the tool. This is the situation !important was
designed for:
.tab_link {
width: 35px;
height: 20px;
color: white;
background: black;
cursor: pointer;
}
div class=tab_linkClick me!/div
Now, lets say I want to disable the tab. I can do so easily by
applying a single class with the important rule:
div class=tab_link disableClick me!/div
.disable {
opacity: 0.3;
filter: alpha(opacity=0.3);
cursor: none !important;
}
The method I showed there is the right style of usage for the !
important keyword. Your method is, in essence, only further
complicating your code. By throwing !important's everywhere, you're
not only increasing the size of the css files (which is the opposite
of the goal for net scripts/stylesheets), you're also making them
neigh unmaintainable.
The solution to many of your css nightmares is spending the extra hour
to go through and properly design/class your html instead of some
cheap hack.
On Jan 19, 10:55 am, ryan.joyce...@googlemail.com
ryan.joyce...@googlemail.com wrote:
but unless you've declared some of your default styles as !important,
the widget *will* take precedence if it's called after the default
CSS.
the only issues i can see are relative vs. explicit pixel sizes - for
ex. if you've declared pixel sizes for your fonts with some especially
broad selectors (globally stating that all paragraphs in divs have a
font size of 10px or whatever) whilst the widget author has used
relative % sizes. Even in those cases it's be quicker, easier and
neater to just change your default CSS rather than replacing every
instance of ; with !important; in your imported stylesheet.
the long and the short of it it that it's a very inelegant solution to
a problem that isn't so much a 'problem' as 'the whole point of
cascading stylesheets'. it's like looking for a solution to grass
being green!
On Jan 19, 3:32 pm, johny why johny...@gmail.com wrote:
i don't see it as a problem. With or without !important, the site-css
will cascade into the widget for elements undeclared in the widget--
the widget designer expects that. The important thing is for the
widget's declared styles to take precedence, which !important achieves
in most cases. (if i'm integrating the jQuery widget into a cms like,
say, WordPress, i may or may not have control over exactly when the
widget-css is declared.)
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
On Jan 20, 6:15 am, johny why johny...@gmail.com wrote: p.s. your link offers a scenario in which you might want to AVOID ! important: !important rules will override normal rules (in the browser-css), so authors are advised to use normal rules almost exclusively to ensure that users with special style needs are able to read the page. i don't agree-- i'm not going to sacrifice site richness and functionality for normal readers to accommodate special readers-- instead, i would provide alternate accessible pages for special readers, and go to town on my normal pages. (but that's a chat for another day). Rather have it today :] You don't need to sacrifice anything for your 'normal' readers. Some people might have a larger font-size or high-contrast colors in their browser stylesheets because of a visual disability. You don't need to do anything for them, less anything that affects the other readers, you just need to follow the guidelines. You may feel hammered down here, but any programmer with reasonable experience knows that adding !important to every declaration is not a practical long-term solution. It's like, in Gmail, marking with a star every message you *don't* want to read. Well, we're talking a lot here about these conflicts, but in practice it shouldn't be that common - it's common sense not to use double ID declarations, or ID prefixed declarations for tags that affect the whole page.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
(wow. and i thought there was nothing left to say on this topic! :) SIZE ryan, SIZE has not yet been mentioned in the thread-- glad you mentioned it. with superfish, at least, the extra !important rules have no noticeable effect on my page-load time, in IE, firefox, or chrome. page-performance is important to me, so if the stylesheet was so huge that performance suffered, i WOULD take the time to find and apply ! important only to those specific widget-rules which really need veto- power. i think load-time is more of a concern with javascript, not css. at the moment, even with all those !important rules, superfish loads faster than my png's (and they ARE optimized). jQuery compressed, on the other hand, is 10 times larger than my css. these are the files required by superfish: superfish.css (with !important on every element): 5K remaining superfish files (such as images): 13K jquery-1.2.6.min.js: 55K perhaps your concern about size comes from your javascript perspective? i think this response effectively answers the 'size' issue.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
EFFORT the reason i don't want to CHANGE the css is because my site-css was designed to display my site properly, the widget-css was designed to display the widget properly. if i make changes in either, it's opening a can of worms. inspecting an element in firebug to see where it's getting it's style from takes a couple of seconds --inspecting the element in firebug is the the start of the job. you have to figure out which styles are causing the issue, then figure out the right fix for each of them. that won't take a couple of seconds. i'm approaching this as a company who needs to get my website up and running quickly. i'm bolting together wordpress, a bunch of plugins, some widgets (like superfish), and some of my own custom programming. these disparate pieces were not designed for each other. i welcome any opportunity to make them play nice together with a minimum of effort. i love programming, but i don't love spending time on programming tasks which could be simplified or eliminated, giving me more time to focus on running my business.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
it's an ugly hack --people who take pride in the purity of their code might take offense at a solution which is based on expediency, rather than programming dexterity. this debate seems partly to be about programming pride vs. expediency. i wish i had the resources to hire one of you gurus, but i have to wear all hats. to me, an example of an ugly hack is hard- coding values where constants should be used, or applying patch upon patch rather than fixing the whole system. has so many potential problems --such as? every potential issue mentioned in this thread is the rare exception. no one has yet presented a serious or probable problem from !important. and in the rare cases where any of the potential problems occur, then you get to apply your expert programming skills. and of course some programmers, like some auto-mechanics or doctors, who get paid more for doing more work, love to find more problems requiring their expert skills to solve. i prefer finding solutions to prevent more work. if i could hire one of you gurus i would hire the ones who find more efficient solutions, rather than more reasons to show off their skills.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
because none of the proposed functional problems have proven truly significant, the debate has become one of principle. Eric Garside's critique is that you're not SUPPOSED to use !important this way. my one strict rule is to never strictly follow strict rules. i believe a wise programmer understands the reasons for particular rules, follows them when it makes sense, and breaks them when it makes sense. never use GOTO is a guideline meant to prevent spaghetti-code, is one of those strict rules. it's an old debate. i myself have written ridiculously-deep, impenetrable conditional nests and other programming gymnastics to avoid the dreaded goto, resulting in code that was harder to maintain. as steve mcconnell, author of the fantastic programmers bible code complete, writes (in support of judicious use of GOTO), If you have your rain boots on, it's not worth walking around the block to avoid a mud puddle. http://www.stevemcconnell.com/ccgoto.htm i have not yet found any chorus of css-authorities warning against ! important.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
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
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
Eric Garside, thanks for the cross-browser alert. that's new issue. researching..
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
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
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
You can do that now...
#myPreciousWidget.title // Matches div id=myPreciousWidget
class=title
or
#myPreciousWidget .title // Matches div id=myPreciousWidgetdiv
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
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
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=myPreciousWidgetdiv
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
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
Oh, I see what you're saying. You're talking about internal classing.
Yea, that would be nice. :)
On Jan 20, 4:22 pm, Ricardo Tomasi ricardob...@gmail.com wrote:
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=myPreciousWidgetdiv
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
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
I'm not the topic police, but I'll try playing one on TV... Does this lengthy discussion have *anything* to do with jQuery at all? It's purely a CSS issue - wouldn't the CSS list be a more suitable place to talk about it? http://www.css-discuss.org/mailman/listinfo/css-d -Mike
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
what does this have to do with jQuery? --this topic is on the jquery forum, because problems with a jQuery component, Superfish, caused me to devise this method. The superfish support page directed me to this forum for support. the author of the plugin has not spoken up yet. (I imagine this technique might be useful for other jQuery candy.) Support for the Superfish plugin is available through the jQuery Mailing List. http://users.tpg.com.au/j_birch/plugins/superfish/#download (the css forum is apparently closed. i tried to join, and never got a reply) http://groups.google.com/group/css-design?lnk=srg
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
On Jan 20, 2009, at 10:31 PM, johny why wrote: what does this have to do with jQuery? --this topic is on the jquery forum, because problems with a jQuery component, Superfish, caused me to devise this method. Yes, but this thread has long since moved far, far away from any discussion of the Superfish plugin. This has been a CSS discussion. I second Mike's request for you to continue it in a more appropriate forum. Thanks, --Karl Karl Swedberg www.englishrules.com www.learningjquery.com
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
One hour. I am betting that an individual with beginner to intermediate skill could find and replace the conflicting class names in the HTML, CSS and js. That is the cleanest, most logical and most professional solution in my opinion. It makes sense to make sense out of one's code especially if one is going to reactor it or make any changes.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
On the other hand - I've seen much worse offtopic threads here. And yes, I've been annoyed by them. That said, sorry for putting fuel into the discussion. --Klaus On 21 Jan., 05:25, Karl Swedberg k...@englishrules.com wrote: On Jan 20, 2009, at 10:31 PM, johny why wrote: what does this have to do with jQuery? --this topic is on the jquery forum, because problems with a jQuery component, Superfish, caused me to devise this method. Yes, but this thread has long since moved far, far away from any discussion of the Superfish plugin. This has been a CSS discussion. I second Mike's request for you to continue it in a more appropriate forum. Thanks, --Karl Karl Swedbergwww.englishrules.comwww.learningjquery.com
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
surely declaring the css you want to take priority after your site's default stylesheet, this will solve the problem? On Jan 18, 10:59 pm, johny why johny...@gmail.com wrote: ricardo, you're right that styles undeclared in the widget-css will cascade from the site-css into the widget, even if you use !important in the widget. that's an important point.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
i don't see it as a problem. With or without !important, the site-css will cascade into the widget for elements undeclared in the widget-- the widget designer expects that. The important thing is for the widget's declared styles to take precedence, which !important achieves in most cases. (if i'm integrating the jQuery widget into a cms like, say, WordPress, i may or may not have control over exactly when the widget-css is declared.)
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
but unless you've declared some of your default styles as !important, the widget *will* take precedence if it's called after the default CSS. the only issues i can see are relative vs. explicit pixel sizes - for ex. if you've declared pixel sizes for your fonts with some especially broad selectors (globally stating that all paragraphs in divs have a font size of 10px or whatever) whilst the widget author has used relative % sizes. Even in those cases it's be quicker, easier and neater to just change your default CSS rather than replacing every instance of ; with !important; in your imported stylesheet. the long and the short of it it that it's a very inelegant solution to a problem that isn't so much a 'problem' as 'the whole point of cascading stylesheets'. it's like looking for a solution to grass being green! On Jan 19, 3:32 pm, johny why johny...@gmail.com wrote: i don't see it as a problem. With or without !important, the site-css will cascade into the widget for elements undeclared in the widget-- the widget designer expects that. The important thing is for the widget's declared styles to take precedence, which !important achieves in most cases. (if i'm integrating the jQuery widget into a cms like, say, WordPress, i may or may not have control over exactly when the widget-css is declared.)
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
ryan.joyce wrote: unless you've declared some of your default styles as !important, the widget *will* take precedence if it's called after the default CSS. --if you mean the widget styles will affect the main site rendering, not if the widget styles are correctly declared with unique id's or classes. the only issues i can see are relative vs. explicit pixel sizes... --rendering problems of a widget, in my experience, could involve many, indeed EVERY attribute of every element in the widget. Even in those cases it's be quicker, easier and neater to just change your default CSS rather than replacing every instance of ; with !important; in your imported stylesheet. --this solution is for cases where changing your default css, which will of course affect your main site rendering, is undesirable or impossible. for me, doing a global replace of ; with !important; takes about 1/2 a second. on the other hand, fine-tuning my main site css so that the widget and the site both look right could potentially take hours of trouble-shooting, trial-and-error, and juggling precedence, including specificity, order of declaration, id's and classes, and so on. it's a very inelegant solution to a problem that isn't so much a 'problem' as 'the whole point of cascading stylesheets'. --one point of cascading stylesheets is to ensure site-uniformity and styling flexibility with minimum effort and redundancy. Which is awesome, where you have control over everything. but a 3rd-party widget was not designed to work with your site css, and your site was not designed to work with that widget. if you're designing a custom widget from scratch in concert with your site, then tightly- integrating it with your site css makes more sense. but it makes less sense, to me, to devote frustrating hours to making a 3rd-party widget css to cooperate with your site css, when a simple rule does the trick. choosing the path of greatest effort seems to me to defeat one of the benefits of css-- to reduce effort. besides, as ricardo pointed out, !important does not eliminate all cascading-- undeclared elements will still get cascaded into the widget. For example, my superfish menu still inherits the font-family and font-size from my site-css, which is great--i'm getting the benefit of desirable cascade, while eliminating the undesirable cascades with !important. !important does not 'break' css-- it's part of the css language, intended to be used where appropriate.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
wileyluxe wrote: Depending on how the rest of the selectors are written, a Body ID will do overwrite it. wileyluxe, can you give an example of how a site-css Body ID can overwrite the widget-css, if the widget employs !important + id's/ classes?
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
!important makes the the widget's styles take precedence, but you also have to take specificity into account. I created a test page to demonstrate the issue: http://ff6600.org/j/specificity.htm There are ways to calculate specificity, take a look at these very nice articles about it: http://www.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/ http://www.stuffandnonsense.co.uk/archives/css_specificity_wars.html http://juicystudio.com/article/selector-specificity.php - ricardo On Jan 19, 4:13 pm, johny why johny...@gmail.com wrote: wileyluxe wrote: Depending on how the rest of the selectors are written, a Body ID will do overwrite it. wileyluxe, can you give an example of how a site-css Body ID can overwrite the widget-css, if the widget employs !important + id's/ classes?
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
Although I love CSS, it is interesting how it leads to some of the same spaghetti problems that people complained about by applying formatting to html. I try to keep my CSS to a minimum but over time on a large site it can get quite messy. Most CSS guru's relate their CSS to little blogs or wiki's versus a large content site.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
Amen to that, JIMD. !important easily eliminates spaghetti problems, with 3rd-party components. (Although, i would counter that CSS applied judiciously, ESPECIALLY to very large sites, can vastly reduce the effort to apply global formats site-wide. But some CSS-fanatics say never, ever use inline-styling, which is fanatical.) UWE, using unique identifiers in the candy is not enough to isolate candy-html from your site-css: -unique identifiers mean that the candy-css will only affect the candy html, and not the rest of your site. that's a GOOD thing. -but your site-css, most-likely NOT using identifiers or classes in many places, will ALSO affect the candy-html, messing up the candy. BAD thing. RICARDO, I would not call this bad coding-- the main-site css rightfully assumes that it is the god-css for your site, so it should not have to bother with any kind of class=MyWebsite on every tag. But this does put the burden on the candy to insulate itself from the site-css. The combination of unique id's, classes, and !important does the trick.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
Sorry johnny, but you're the one who seems to not understand the nature of CSS. I'm pretty sure of my reasonings in this field ;) They're named **Cascading** Style Sheets for a reason. Third party CSS Candy that is supposed to be inserted in other's pages should be coded with this issue in mind, protecting all it's styles in it's own container, or writing styles in-line (if it's not meant to be altered). If this has not been done it is indeed badly written code. I realize you're not aware of the issues that arise from your solution. There is also a reason why !important is seldomly used: because it makes a mess of figuring out which style is being applied by overriding the cascading - eased by the use of firebug inspection or similar of course, but a mess nonetheless. The second suggestion you posted, surrounding the thing with a div and prepending the unique ID to every style is much better. Or putting in an in-line style tag, which overrides external stylesheets but without the mess of !important. That's what should have been done by the CSS author in the first place, with ID or classes. cheers, - ricardo ps: what does this have to do with jQuery? On Jan 18, 2:12 am, johny why johny...@gmail.com wrote: ricardo, no offense-- the only part of this thread you need to worry about is the first post: to insulate your 3rd-party candy (such as a suckerfish menu) from your site's css, globally replace: ; with !important; in the candy's css. that's it. the rest of this thread is geeks debating hypothetical scenarios and solutions, which beginners and people with hangovers can ignore ;)
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
On 18 Jan., 19:16, Ricardo Tomasi ricardob...@gmail.com wrote: They're named **Cascading** Style Sheets for a reason. Third party CSS Candy that is supposed to be inserted in other's pages should be coded with this issue in mind, protecting all it's styles in it's own container, or writing styles in-line (if it's not meant to be altered). If this has not been done it is indeed badly written code. Inline styles are not a guarantee that a websites CSS would not cascade into that widget. Although inline styles have highest specificity, declarations with !important will still override those inline styles. They do not in IE but that is a different story. I realize you're not aware of the issues that arise from your solution. There is also a reason why !important is seldomly used: because it makes a mess of figuring out which style is being applied by overriding the cascading - eased by the use of firebug inspection or similar of course, but a mess nonetheless. I tend to agree. When I do write CSS I almost always try to avoid ! important and consider it bad practice. Most of the time it turned out to cause you more problems than do any good. I think the solution for a 3rd party widget though should be to use a unique identifier plus important declarations to 1. protect messing up the site's CSS where it's included in while 2. at the same time maintaining its own styles. Nevertheless there is no guarantee that the site's CSS will not override styles unless you use an iframe or object element to include that widget. --Klaus
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
ricardo: what does this have to do with jQuery? --this topic is on the jquery forum, because problems with a jQuery component, Superfish, caused me to devise this method. The superfish support page directed me to this forum for support. the author of the plugin has not spoken up yet. (I imagine this technique might be useful for other jQuery candy.) Support for the Superfish plugin is available through the jQuery Mailing List. http://users.tpg.com.au/j_birch/plugins/superfish/#download Third party CSS Candy that is supposed to be inserted in other's pages should be coded with this issue in mind, protecting all it's styles in it's own container --i believe that's incorrect, if by container you mean unique classes and id's. as i describe above, unique id's will NOT protect the component's style from the main site-css, if the site-css cascades into the candy. Which is exactly what what messed up my superfish menu. writing styles in-line (if it's not meant to be altered). If this has not been done it is indeed badly written code. --i don't agree. one of the principals of best-practice web- styling is to NOT use inline styles, but to separate formatting out to a css file. that way, the web developer can tweak the formatting without touching the html structure. There is also a reason why !important is seldomly used: because it makes a mess of figuring out which style is being applied by overriding the cascading --i dont agree. the mess is what you have without !important. it instantly clears up that mess, because then you know exactly which css is controlling the candy-- the one with !important. override the cascading is exactly the benefit of using !important. The site-css was not designed to be compatible with your 3rd-party candy. i think the reason !important is seldom used, is because it's little- known, and because it's usually described as a way to resolve conflicts between web-page and browser-css (aka author vs user). prepending the unique ID to every style is much better. --Superfish does indeed use a unique ID. as Klaus points out, that does not insulate Superfish from the site-css. for me, the proof is in the pudding. My silverfish displayed all wrong without !important. It displays beautifully WITH !important. That's all the proof i need! klaus: a 3rd party widget...should...use...important declarations. Nevertheless there is no guarantee that the site's CSS will not override styles. --why? unless the site css ALSO uses !important, how else could it override the candy-css?
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
johny why: --why? unless the site css ALSO uses !important, how else could it override the candy-css? Depending on how the rest of the selectors are written, a Body ID will do overwrite it. Sean On Jan 18, 12:45 pm, johny why johny...@gmail.com wrote: ricardo: what does this have to do with jQuery? --this topic is on the jquery forum, because problems with a jQuery component, Superfish, caused me to devise this method. The superfish support page directed me to this forum for support. the author of the plugin has not spoken up yet. (I imagine this technique might be useful for other jQuery candy.) Support for the Superfish plugin is available through the jQuery Mailing List.http://users.tpg.com.au/j_birch/plugins/superfish/#download Third party CSS Candy that is supposed to be inserted in other's pages should be coded with this issue in mind, protecting all it's styles in it's own container --i believe that's incorrect, if by container you mean unique classes and id's. as i describe above, unique id's will NOT protect the component's style from the main site-css, if the site-css cascades into the candy. Which is exactly what what messed up my superfish menu. writing styles in-line (if it's not meant to be altered). If this has not been done it is indeed badly written code. --i don't agree. one of the principals of best-practice web- styling is to NOT use inline styles, but to separate formatting out to a css file. that way, the web developer can tweak the formatting without touching the html structure. There is also a reason why !important is seldomly used: because it makes a mess of figuring out which style is being applied by overriding the cascading --i dont agree. the mess is what you have without !important. it instantly clears up that mess, because then you know exactly which css is controlling the candy-- the one with !important. override the cascading is exactly the benefit of using !important. The site-css was not designed to be compatible with your 3rd-party candy. i think the reason !important is seldom used, is because it's little- known, and because it's usually described as a way to resolve conflicts between web-page and browser-css (aka author vs user). prepending the unique ID to every style is much better. --Superfish does indeed use a unique ID. as Klaus points out, that does not insulate Superfish from the site-css. for me, the proof is in the pudding. My silverfish displayed all wrong without !important. It displays beautifully WITH !important. That's all the proof i need! klaus: a 3rd party widget...should...use...important declarations. Nevertheless there is no guarantee that the site's CSS will not override styles. --why? unless the site css ALSO uses !important, how else could it override the candy-css?
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
On Jan 18, 6:45 pm, johny why johny...@gmail.com wrote: Third party CSS Candy that is supposed to be inserted in other's pages should be coded with this issue in mind, protecting all it's styles in it's own container --i believe that's incorrect, if by container you mean unique classes and id's. as i describe above, unique id's will NOT protect the component's style from the main site-css, if the site-css cascades into the candy. Which is exactly what what messed up my superfish menu. There's no difference between adding an unique ID or using important, it's just different specificity levels. !important won't protect the component's style either, undeclared styles will cascade anyway. What will protect the CSS is using widget-specific IDs and classnames, with a prefix or whatever, to lessen the chance of overriding it. It will never be fully protected. writing styles in-line (if it's not meant to be altered). If this has not been done it is indeed badly written code. --i don't agree. one of the principals of best-practice web- styling is to NOT use inline styles, but to separate formatting out to a css file. that way, the web developer can tweak the formatting without touching the html structure. I said if it's not meant to be altered. If it's a copy paste thing there's no harm. There is also a reason why !important is seldomly used: because it makes a mess of figuring out which style is being applied by overriding the cascading --i dont agree. the mess is what you have without !important. it instantly clears up that mess, because then you know exactly which css is controlling the candy-- the one with !important. override the cascading is exactly the benefit of using !important. The site-css was not designed to be compatible with your 3rd-party candy. i think the reason !important is seldom used, is because it's little- known, and because it's usually described as a way to resolve conflicts between web-page and browser-css (aka author vs user). It's not little known unless to those who are not web developers/ designers, that's basic stuff. If your widget declares !important on a common class name that is used elsewhere in your page, there goes your 'solution'. prepending the unique ID to every style is much better. --Superfish does indeed use a unique ID. as Klaus points out, that does not insulate Superfish from the site-css. Nothing will insulate it. You must have noticed that all of Superfish styles are prefixed by sf-. They will only be overriden if you're not sensible with your own CSS, I bet your page has lots of ID specified styles for containers. for me, the proof is in the pudding. My silverfish displayed all wrong without !important. It displays beautifully WITH !important. That's all the proof i need! Good to know. Just don't go out shouting that your solution is perfect for every situation - I'm sure you'll find that out by yourself. a 3rd party widget...should...use...important declarations. Nevertheless there is no guarantee that the site's CSS will not override styles. --why? unless the site css ALSO uses !important, how else could it override the candy-css? exactly. over and out, - ricardo
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
On 18 Jan., 21:45, johny why johny...@gmail.com wrote: a 3rd party widget...should...use...important declarations. Nevertheless there is no guarantee that the site's CSS will not override styles. --why? unless the site css ALSO uses !important, how else could it override the candy-css? Yes, that's exactly it. You obviously cannot prevent a site author to use !important as well and thus all I was saying is that - especially from the standpoint of the 3rd party developer - there is no guarantee the 3rd party's CSS will not be overridden unless an iframe is used for such widget. Yet another reason to avoid !important for your site - at least if you know you want to include 3rd party stuff. --Klaus
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
ricardo, you're right that styles undeclared in the widget-css will cascade from the site-css into the widget, even if you use !important in the widget. that's an important point.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
yes, uwe, as i mentioned, if your 3rd-party css does not use unique id's or classes, then 'important' in the 3rd-party css could affect your main site-rendering. but in most cases, 3rd-party candy DOES use unique classes or id's, in which case there's no problem.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
if your 3rd-party css does not use unique id's or classes, then you
could create your own (which will enable you to use !important):
1. locate the html for the candy, in your site's html pages.
2. surround it with a div with an id that does not appear anyplace in
the rest of your site:
div id=candy.../div
3. open each of the candy's css files, and precede every element with
#candy:
#candy ul li { width: 100% !important; }
DONE!
If the candy appears throughout the site, then you can use a class-
name instead of an id name.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
if your 3rd-party css does not use unique id's or classes, then you
could create your own (which will enable you to use !important):
1. locate the html for the candy, in your site's html pages.
2. surround it with a div with an id that does not appear anyplace in
the rest of your site:
div id=candy.../div
3. open each of the candy's css files, and precede every element with
that same id:
#candy ul li { width: 100% !important; }
DONE!
If the candy appears more than once on your site, then do the same
thing with a class-name instead of an id name, and use .candy instead
of #candy in the css files.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
One thing to keep in mind: If two declarations use !important! the
conflict is solved by specificity again, e.g. as if there were no !
important:
div id=foo class=bar
#foo {
width: 200px !important; /* higher specificity */
}
.bar {
width: 300px !important;
}
Applied width will be 200px.
--Klaus
On 17 Jan., 06:31, johny why johny...@gmail.com wrote:
trying to integrate a 3rd party css candy into your site may result in
conflicts between the candy's css and your site's css, resulting in a
rendering mess. stuff that works beautifully by itself blows up when
you put it into your website. this trick may not find you a new
girlfriend, or butter your bread on both sides, !BUT¡ it may
instantly eliminate your css conflicts. it instantly eliminated ALL of
the rendering conflicts i was having with superfish (and other css
menus), when trying to integrate them into my site.
SOLUTION:
open all your css files, and globally replace: ; with !important;
THAT'S IT!
(don't forget the space before !important;)
for example, this:
top: -999em;
will become:
top: -999em !important;
HOW IT WORKS:
the !important property forces that style to override all other css,
whether style-sheets, inline-css, header-styles, and whether above or
below in the css hierarchy.
badabing!
http://users.tpg.com.au/j_birch/plugins/superfish/http://inyourear.org
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
right, Klaus, specificity resolves conflicts. which could be an issue, if your main site css uses !important on any element which conflicts with your candy css. fortunately, !important seems to be used rarely, so that's probably not going to be an issue. if, by rare chance, your site's css has a conflicting !important, then you might be able to override it with some javascript or runtimeStyle. but, if your candy's css has conflicting declarations WITHIN ITSELF, then, unless it's a bug in the candy, it's a conflict intended to be resolved by specificity-- and applying !important to all elements within the candy will have no effect on the intended behavior of the candy.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
On 1/17/09, Klaus Hartl klaus.ha...@googlemail.com wrote:
One thing to keep in mind: If two declarations use !important! the
conflict is solved by specificity again, e.g. as if there were no !
important:
div id=foo class=bar
#foo {
width: 200px !important; /* higher specificity */
}
.bar {
width: 300px !important;
}
Applied width will be 200px.
--Klaus
On 17 Jan., 06:31, johny why johny...@gmail.com wrote:
trying to integrate a 3rd party css candy into your site may result in
conflicts between the candy's css and your site's css, resulting in a
rendering mess. stuff that works beautifully by itself blows up when
you put it into your website. this trick may not find you a new
girlfriend, or butter your bread on both sides, !BUT¡ it may
instantly eliminate your css conflicts. it instantly eliminated ALL of
the rendering conflicts i was having with superfish (and other css
menus), when trying to integrate them into my site.
SOLUTION:
open all your css files, and globally replace: ; with !important;
THAT'S IT!
(don't forget the space before !important;)
for example, this:
top: -999em;
will become:
top: -999em !important;
HOW IT WORKS:
the !important property forces that style to override all other css,
whether style-sheets, inline-css, header-styles, and whether above or
below in the css hierarchy.
badabing!
http://users.tpg.com.au/j_birch/plugins/superfish/http://inyourear.org
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
right, Klaus, specificity resolves conflicts. if your main site css uses !important on any element which conflicts with your candy css, that could create a conflict in your candy, which would resolve in favor of the site's css-- causing your candy to display wrong! (even though you used !important). fortunately, !important seems to be used rarely, so such a conflict is unlikely to arise. if, by rare chance, your site's css has a conflicting !important, then you might be able to override it with some javascript and getOverrideStyle. (or, runtimeStyle is an IE-only option) w3.org states: getOverrideStyle method provides a mechanism through which a DOM author could effect immediate change to the style of an element without modifying the explicitly linked style sheets of a document or the inline style of elements in the style sheets. This style sheet comes after the author style sheet in the cascade algorithm and is called override style sheet. The override style sheet takes precedence over author style sheets. An !important declaration still takes precedence over a normal declaration. Override, author, and user style sheets all may contain !important declarations. User !important rules take precedence over both override and author !important rules, and override !important rules take precedence over author ! important rules. http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-DocumentCSS in other words, an override style marked !important is the CSS of highest-precedence, in the CSS-hierarchy. if your candy's css has conflicting declarations WITHIN ITSELF, then, unless it's a bug in the candy, it's a conflict intended, by the candy designer, to be resolved by specificity-- and applying !important to ALL elements within the candy will have no effect on the intended behavior of the candy.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
right, Klaus, specificity resolves conflicts. if your main site css uses !important on any element which conflicts with your candy css, that could create a conflict in your candy, which would resolve in favor of the site's css-- causing your candy to display wrong! (even though you used !important). fortunately, !important seems to be used rarely, so such a conflict is unlikely to arise. if, by rare chance, your site's css has a conflicting !important, then you might be able to override it with some javascript and getOverrideStyle. (or, runtimeStyle is an IE-only option) w3.org states: getOverrideStyle method provides a mechanism through which a DOM author could effect immediate change to the style of an element without modifying the explicitly linked style sheets of a document or the inline style of elements in the style sheets. This style sheet comes after the author style sheet in the cascade algorithm and is called override style sheet. The override style sheet takes precedence over author style sheets. An !important declaration still takes precedence over a normal declaration. Override, author, and user style sheets all may contain !important declarations. User !important rules take precedence over both override and author !important rules, and override !important rules take precedence over author ! important rules. http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS... in other words, an override style marked !important is the CSS of highest-precedence, in the CSS-hierarchy. if your candy's css has conflicting declarations WITHIN ITSELF, then, unless it's a bug in the candy, it's a conflict intended, by the candy designer, to be resolved by specificity-- and applying !important to ALL elements within the candy will have no effect on the intended behavior of the candy—other than the joyful benefit of insulating your candy from the site’s css!
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
right, Klaus, specificity resolves conflicts. if your main site css uses !important on any element which conflicts with your candy css, that would create a conflict in your candy, which MIGHT resolve in favor of the site's css-- causing your candy to display wrong! fortunately, !important seems to be used rarely, so such a conflict is unlikely to arise—and even then, there’s a 50% chance the candy css will win! if, by rare chance, your site's css has a conflicting !important which overpowers the candy css, then you might be able to override it with some javascript and getOverrideStyle. (or, runtimeStyle is an IE-only option) w3.org states: getOverrideStyle method provides a mechanism through which a DOM author could effect immediate change to the style of an element without modifying the explicitly linked style sheets of a document or the inline style of elements in the style sheets. This style sheet comes after the author style sheet in the cascade algorithm and is called override style sheet. The override style sheet takes precedence over author style sheets. An !important declaration still takes precedence over a normal declaration. Override, author, and user style sheets all may contain !important declarations. User !important rules take precedence over both override and author !important rules, and override !important rules take precedence over author ! important rules. http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS... in other words, an override style marked !important is the CSS of highest-precedence, in the CSS-hierarchy. if your candy's css has conflicting declarations WITHIN ITSELF, then, unless it's a bug in the candy, it's a conflict intended, by the candy designer, to be resolved by specificity-- and applying !important to ALL elements within the candy will have no effect on the intended behavior of the candy—other than the joyful benefit of insulating your candy from the site’s css!
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
OFFTOP: Johny, just let it go already... :))) Read jQuery HowTo Resource - http://jquery-howto.blogspot.com On Sun, Jan 18, 2009 at 12:07 AM, johny why johny...@gmail.com wrote: right, Klaus, specificity resolves conflicts. if your main site css uses !important on any element which conflicts with your candy css, that would create a conflict in your candy, which MIGHT resolve in favor of the site's css-- causing your candy to display wrong! fortunately, !important seems to be used rarely, so such a conflict is unlikely to arise—and even then, there's a 50% chance the candy css will win! if, by rare chance, your site's css has a conflicting !important which overpowers the candy css, then you might be able to override it with some javascript and getOverrideStyle. (or, runtimeStyle is an IE-only option) w3.org states: getOverrideStyle method provides a mechanism through which a DOM author could effect immediate change to the style of an element without modifying the explicitly linked style sheets of a document or the inline style of elements in the style sheets. This style sheet comes after the author style sheet in the cascade algorithm and is called override style sheet. The override style sheet takes precedence over author style sheets. An !important declaration still takes precedence over a normal declaration. Override, author, and user style sheets all may contain !important declarations. User !important rules take precedence over both override and author !important rules, and override !important rules take precedence over author ! important rules. http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS... in other words, an override style marked !important is the CSS of highest-precedence, in the CSS-hierarchy. if your candy's css has conflicting declarations WITHIN ITSELF, then, unless it's a bug in the candy, it's a conflict intended, by the candy designer, to be resolved by specificity-- and applying !important to ALL elements within the candy will have no effect on the intended behavior of the candy—other than the joyful benefit of insulating your candy from the site's css!
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
right, Klaus, specificity resolves conflicts. if your main site css uses !important on any element which conflicts with your candy css, it MIGHT resolve in favor of the site's css-- causing your candy to display wrong! fortunately, !important seems to be used rarely, so such a conflict is unlikely to arise—and even then, there’s a 50% chance the candy css will win! if, by rare chance, your site's css has a conflicting !important, then you might be able to override it with some javascript and getOverrideStyle. (or, runtimeStyle is an IE-only option) w3.org states: getOverrideStyle method provides a mechanism through which a DOM author could effect immediate change to the style of an element without modifying the explicitly linked style sheets of a document or the inline style of elements in the style sheets. This style sheet comes after the author style sheet in the cascade algorithm and is called override style sheet. The override style sheet takes precedence over author style sheets. An !important declaration still takes precedence over a normal declaration. Override, author, and user style sheets all may contain !important declarations. User !important rules take precedence over both override and author !important rules, and override !important rules take precedence over author ! important rules. http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-DocumentCSS in other words, an override style marked !important is the CSS of highest-precedence, in the CSS-hierarchy. if your candy's css has conflicting declarations WITHIN ITSELF, then, unless it's a bug in the candy, it's a conflict intended, by the candy designer, to be resolved by specificity-- and applying !important to ALL elements within the candy will have no effect on the intended behavior of the candy—other than the joyful benefit of insulating your candy from the site’s css!
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
jquery Lover, let go of what? this technique? this thread? or my repeatedly removing and reposting the same post, because you get an email alert every time? On Jan 17, 11:10 am, jQuery Lover ilovejqu...@gmail.com wrote: OFFTOP: Johny, just let it go already... :))) Read jQuery HowTo Resource - http://jquery-howto.blogspot.com On Sun, Jan 18, 2009 at 12:07 AM, johny why johny...@gmail.com wrote: right, Klaus, specificity resolves conflicts. if your main site css uses !important on any element which conflicts with your candy css, that would create a conflict in your candy, which MIGHT resolve in favor of the site's css-- causing your candy to display wrong! fortunately, !important seems to be used rarely, so such a conflict is unlikely to arise—and even then, there's a 50% chance the candy css will win! if, by rare chance, your site's css has a conflicting !important which overpowers the candy css, then you might be able to override it with some javascript and getOverrideStyle. (or, runtimeStyle is an IE-only option) w3.org states: getOverrideStyle method provides a mechanism through which a DOM author could effect immediate change to the style of an element without modifying the explicitly linked style sheets of a document or the inline style of elements in the style sheets. This style sheet comes after the author style sheet in the cascade algorithm and is called override style sheet. The override style sheet takes precedence over author style sheets. An !important declaration still takes precedence over a normal declaration. Override, author, and user style sheets all may contain !important declarations. User !important rules take precedence over both override and author !important rules, and override !important rules take precedence over author ! important rules. http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS... in other words, an override style marked !important is the CSS of highest-precedence, in the CSS-hierarchy. if your candy's css has conflicting declarations WITHIN ITSELF, then, unless it's a bug in the candy, it's a conflict intended, by the candy designer, to be resolved by specificity-- and applying !important to ALL elements within the candy will have no effect on the intended behavior of the candy—other than the joyful benefit of insulating your candy from the site's css!
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
repeatedly reposting the same comment And the idea is clear already. Use !important, but use it with care... Simple and clear... Read jQuery HowTo Resource - http://jquery-howto.blogspot.com On Sun, Jan 18, 2009 at 12:16 AM, johny why johny...@gmail.com wrote: jquery Lover, let go of what? this technique? this thread? or my repeatedly removing and reposting the same post, because you get an email alert every time? On Jan 17, 11:10 am, jQuery Lover ilovejqu...@gmail.com wrote: OFFTOP: Johny, just let it go already... :))) Read jQuery HowTo Resource - http://jquery-howto.blogspot.com On Sun, Jan 18, 2009 at 12:07 AM, johny why johny...@gmail.com wrote: right, Klaus, specificity resolves conflicts. if your main site css uses !important on any element which conflicts with your candy css, that would create a conflict in your candy, which MIGHT resolve in favor of the site's css-- causing your candy to display wrong! fortunately, !important seems to be used rarely, so such a conflict is unlikely to arise—and even then, there's a 50% chance the candy css will win! if, by rare chance, your site's css has a conflicting !important which overpowers the candy css, then you might be able to override it with some javascript and getOverrideStyle. (or, runtimeStyle is an IE-only option) w3.org states: getOverrideStyle method provides a mechanism through which a DOM author could effect immediate change to the style of an element without modifying the explicitly linked style sheets of a document or the inline style of elements in the style sheets. This style sheet comes after the author style sheet in the cascade algorithm and is called override style sheet. The override style sheet takes precedence over author style sheets. An !important declaration still takes precedence over a normal declaration. Override, author, and user style sheets all may contain !important declarations. User !important rules take precedence over both override and author !important rules, and override !important rules take precedence over author ! important rules. http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS... in other words, an override style marked !important is the CSS of highest-precedence, in the CSS-hierarchy. if your candy's css has conflicting declarations WITHIN ITSELF, then, unless it's a bug in the candy, it's a conflict intended, by the candy designer, to be resolved by specificity-- and applying !important to ALL elements within the candy will have no effect on the intended behavior of the candy—other than the joyful benefit of insulating your candy from the site's css!
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
jQuery Lover, i'm a programmer. i'm a perfectionist when it comes to wording. Unfortunately, google groups does not provide a draft feature, OR preview feature, OR edit-after-posting feature, which i find galling and irritating. i'll try to get my wording right before posting. secondly, the idea is not clear-- this is a conversation between several people, and we are extending the discussion with new ideas and new observations with each post. for example, my last post, if you actually read and understood, introduced the idea of resolving a conflict... i'm not going to repeat myself. no one here has been repeating themselves. are you just telling us all to shut up? that's totally out of line. this is a discussion thread. how about if your remove your unproductive, off-topic, discussion- blocking flames, and i'll remove this post, and we can both prevent this thread from turning into an infantile flame war. and next time you have an off-topic comment to make, i suggest you click reply to author instead of reply
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
You made a good point, I should have replied to you personally! PS. Please don't take it personal. That was (kinda) a joke. I guess we are in a better mood here and all of my friends that I MADE TO look through the the thread said 'Good one' : PSS. Nothing personal Johny... just a sunny day and a freaking good mood (she is not pregnant) :) Read jQuery HowTo Resource - http://jquery-howto.blogspot.com On Sun, Jan 18, 2009 at 12:34 AM, johny why johny...@gmail.com wrote: how about if your remove your unproductive, off-topic, discussion- blocking flames, and i'll remove this post, and we can both prevent this thread from turning into an infantile flame war. and next time you have an off-topic comment to make, i suggest you click reply to author instead of reply
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
so let's both remove our off-topic threads, ok? and no hard feelings, and glad she's not preggo - Original Message - From: jQuery Lover To: jquery-en@googlegroups.com Sent: Saturday, January 17, 2009 11:45 AM Subject: [jQuery] Re: Solution To Many Of Your CSS Nightmares! You made a good point, I should have replied to you personally! PS. Please don't take it personal. That was (kinda) a joke. I guess we are in a better mood here and all of my friends that I MADE TO look through the the thread said 'Good one' : PSS. Nothing personal Johny... just a sunny day and a freaking good mood (she is not pregnant) :) Read jQuery HowTo Resource - http://jquery-howto.blogspot.com On Sun, Jan 18, 2009 at 12:34 AM, johny why johny...@gmail.com wrote: how about if your remove your unproductive, off-topic, discussion- blocking flames, and i'll remove this post, and we can both prevent this thread from turning into an infantile flame war. and next time you have an off-topic comment to make, i suggest you click reply to author instead of reply
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
That's way too much fuss for badly written CSS :) On Jan 17, 5:10 pm, johny why johny...@gmail.com wrote: right, Klaus, specificity resolves conflicts. if your main site css uses !important on any element which conflicts with your candy css, it MIGHT resolve in favor of the site's css-- causing your candy to display wrong! fortunately, !important seems to be used rarely, so such a conflict is unlikely to arise—and even then, there’s a 50% chance the candy css will win! if, by rare chance, your site's css has a conflicting !important, then you might be able to override it with some javascript and getOverrideStyle. (or, runtimeStyle is an IE-only option) w3.org states: getOverrideStyle method provides a mechanism through which a DOM author could effect immediate change to the style of an element without modifying the explicitly linked style sheets of a document or the inline style of elements in the style sheets. This style sheet comes after the author style sheet in the cascade algorithm and is called override style sheet. The override style sheet takes precedence over author style sheets. An !important declaration still takes precedence over a normal declaration. Override, author, and user style sheets all may contain !important declarations. User !important rules take precedence over both override and author !important rules, and override !important rules take precedence over author ! important rules.http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS... in other words, an override style marked !important is the CSS of highest-precedence, in the CSS-hierarchy. if your candy's css has conflicting declarations WITHIN ITSELF, then, unless it's a bug in the candy, it's a conflict intended, by the candy designer, to be resolved by specificity-- and applying !important to ALL elements within the candy will have no effect on the intended behavior of the candy—other than the joyful benefit of insulating your candy from the site’s css!
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
hi Ricardo i think you're not understanding the nature of css conflicts (has nothing to do with badly written code), or you're not understanding how super-simple this technique is (no fuss, it's a simple 2-second tweak), or i'm not understanding you (are you just trying to be cute?)
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
ricardo, no offense-- the only part of this thread you need to worry about is the first post: to insulate your 3rd-party candy (such as a suckerfish menu) from your site's css, globally replace: ; with !important; in the candy's css. that's it. the rest of this thread is geeks debating hypothetical scenarios and solutions, which beginners and people with hangovers can ignore ;)
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
This might work for Superfish but isn't it also a possibility by doing this you could do the exact opposite of what you're trying to accomplish, as this could also override any other third party CSS you're trying to use? While I guess it's not technically incorrect, there's no reason to include !important in every one of your properties. If you must, it should only be done on elements that require it to function correctly. Ideally, you should just modify your CSS to not even use this on your properties (via unique names, inheritance, etc)... Cheers- Nic http://www.twitter.com/nicluciano On Sat, Jan 17, 2009 at 12:31 AM, johny why johny...@gmail.com wrote: trying to integrate a 3rd party css candy into your site may result in conflicts between the candy's css and your site's css, resulting in a rendering mess. stuff that works beautifully by itself blows up when you put it into your website. this trick may not find you a new girlfriend, or butter your bread on both sides, !BUT¡ it may instantly eliminate your css conflicts. it instantly eliminated ALL of the rendering conflicts i was having with superfish (and other css menus), when trying to integrate them into my site. SOLUTION: open all your css files, and globally replace: ; with !important; THAT'S IT! (don't forget the space before !important;) for example, this: top: -999em; will become: top: -999em !important; HOW IT WORKS: the !important property forces that style to override all other css, whether style-sheets, inline-css, header-styles, and whether above or below in the css hierarchy. badabing! http://users.tpg.com.au/j_birch/plugins/superfish/ http://inyourear.org
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
IMPORTANT: make the above change to the 3rd-party candy css, NOT the css of your website
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
nic, i don't understand what you mean by modify your CSS to not even use this on your properties
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
this could also override any other third party CSS --i don't think so, Nic, as you apply the important property to the 3rd-party css, not your site's css. however, if the 3rd-party css does not use unique class or id names, to target JUST their candy, then applying the 'important' property the 3rd-party css might affect the rendering of the rest of your site.
[jQuery] Re: Solution To Many Of Your CSS Nightmares!
HOW IT WORKS:
the !important property forces that style to override all other css,
whether style-sheets, inline-css, header-styles, and whether above or
below in the css hierarchy.
Yes, important will override, but only for the one property using it.
Let's assume you have to css files both containing a selector:
.doesntwork {
float: right;
width: 240px;
}
and in the other file
.doesntwork {
width: 300px;
}
So if the file you're changing is the second, you'd end up with
.doesntwork {
width: 300px !important;
}
which is fine, however the browser will apply
.doesntwork {
float: right;
width: 300px;
}
and I bet you didn't want the float in there :-)
Best is to just use things with unique identifiers.
Uwe
