Re: Hard-coded colors breaking custom CSS settings.
by chester (Hermit) on Nov 04, 2005 at 16:32 UTC
|
I would also be happy if there were no font tags. It's possible to work around it though; in the CSS I use, I resort to things like
font {
color: #000 !important;
}
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] [d/l] |
Re: Hard-coded colors breaking custom CSS settings.
by davidrw (Prior) on Nov 04, 2005 at 16:30 UTC
|
you can put this in your custom css (to make it black text) and it will override the color="white" html attribute .. might, of course, break other font tags that don't have explictl styles, though..
font { color: #000000 }
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
font {
color: inherit !important;
font: inherit !important;
}
Now font tags have exactly zero effect.
Makeshifts last the longest. | [reply] [Watch: Dir/Any] [d/l] [select] |
|
font { font-size: 100%; }
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] [Watch: Dir/Any] [d/l] |
Re: Hard-coded colors breaking custom CSS settings.
by Petruchio (Vicar) on Nov 05, 2005 at 16:35 UTC
|
Rest assured, I don't think anyone's hard-coding any new colors. There are just some old ones lingering.
I got rid of most of these a few years back, but I know I didn't get all of them; it's a big codebase.
If you find something like this, and it's causing you trouble, /msg me the details and I'll see about
getting rid of it. If, after a week or so, it's not fixed, and you haven't heard bad news from me,
/msg me again. I don't mind a bit of polite hassling. :-) You might also talk to the pmdev folks, who
might respond more quickly. If a patch is brought to my attention to do this sort of thing, I'll apply it.
| [reply] [Watch: Dir/Any] |
|
Searching the code for <font shows 120 hits, but a bunch of them are irrelevant, and I don’t know how many of them are dead. Even so, if each pmdevil patched one or two of those, they’d all be gone. It’s less work than meets the eye.
I’m in the process of patching all the poll stuff.
Makeshifts last the longest.
| [reply] [Watch: Dir/Any] |
|
<tr class="titlebar">
<td class="titlebar">
<form method="get" action="?"
enctype="application/x-www-form-urlencoded" >
<img src="./images/clearpixel.gif" width="5"
height="1" alt="" class="spacer" />
<input type="text" name="node"
size="20" maxlength="80" />
<input class="titlebar" type="submit"
value="Search" name="go_button" />
</form>
</td>
<td class="titlebar" id="mb2001titlebar" align="right" >
<a class="titlebar" href="?" >
Perl Monks
</a>
</td>
</tr>
And my CSS:
tr.titlebar , tr.monkquip {
color : #0000aa;
background-color : #ffffff;
}
The funny think is, the monkquip displays properly, but the titlebar does not.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
Try either less or more specifity. Either just .titlebar, so all elements with the class are addressed directly (instead of having to inherit their colours from the <tr>), or add a couple more specific ones like td.titlebar, input.titlebar.
Specificity is a pretty important concept in CSS, and if you don’t understand it, then the cascading and inheritance of things will occasionally snare you in baffling ways.
Makeshifts last the longest.
| [reply] [Watch: Dir/Any] [d/l] [select] |