> 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
sadly, i doubt any other group will participate as passionately as the
you geeks.
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 wrote:
> On Jan 20, 2009, at 10:31 PM, johny why wrote:
>
>
>
> > "what does this have to do with
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 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
discussio
"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 th
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
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 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
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 wrote:
> You can do that now...
>
> #myPreciousWidget.title // Matches class="title">
>
> or
>
> #myPreciousWidget .title // Mat
You can do that now...
#myPreciousWidget.title // Matches
or
#myPreciousWidget .title // Matches
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
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 {
padd
Eric Garside, thanks for the cross-browser alert. that's new issue.
researching..
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-n
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 understan
"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
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
(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
On Jan 20, 6:15 am, johny why 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 nee
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: po
To me, 'important' is the 'goto' of CSS.
On Jan 20, 6:22 am, "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
> --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 a
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/refer
!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.
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?
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 o
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 selector
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
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 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 !importan
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.
On 18 Jan., 21:45, johny why 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 exac
On Jan 18, 6:45 pm, johny why 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
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 wrote:
> ricardo:
>
> "what does this have to do with jQuery?
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
On 18 Jan., 19:16, Ricardo Tomasi 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 (
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
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
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
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 hy
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?)
That's way too much fuss for badly written CSS :)
On Jan 17, 5:10 pm, johny why 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 cand
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
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 a
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
> 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 wrote:
>
> jquery Lover, let go of what? this
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 wrote:
> OFFTOP:
>
> Johny, just let it go already... :)))
>
>
> Read jQuery HowTo Resource - htt
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
unlike
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 wrote:
>
> right, Klaus, specificity resolves conflicts.
>
> if your main site css uses !important on any element which conflicts
> w
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
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 !importan
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 !importan
On 1/17/09, Klaus Hartl 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":
>
>
>
> #foo {
> width: 200px !important; /* higher specificity */
> }
> .bar {
> width: 300px !impo
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
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":
#foo {
width: 200px !important; /* higher specificity */
}
.bar {
width: 300px !important;
}
Applied width will be 200px.
--Klaus
On
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:
...
3. o
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:
...
3. o
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.
> 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
"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 t
nic, i don't understand what you mean by "modify your CSS to not even
use this on your properties"
IMPORTANT:
make the above change to the 3rd-party candy css, NOT the css of your
website
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
!im
61 matches
Mail list logo
