sadly, i doubt any other group will participate as passionately as the
you geeks.
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
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.
--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
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,
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:
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
(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.
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
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
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
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
Eric Garside, thanks for the cross-browser alert. that's new issue.
researching..
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 {
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
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
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
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
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
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
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
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
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
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
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
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
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?
!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:
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
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
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,
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
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
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
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
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,
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.
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.
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
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
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
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
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 */
}
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
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
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
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
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
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
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
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
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
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
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--
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?)
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
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:
make the above change to the 3rd-party candy css, NOT the css of your
website
nic, i don't understand what you mean by modify your CSS to not even
use this on your properties
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
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
61 matches
Mail list logo
