Zoe wrote: >Well, we have no way of correcting you without seeing the page. :-)
Thanks Zoe. Since my question was in re: the resources, below, if you or anyone knows of more updated material which invalidates the claims made in the links below, then sure: such links would correct me. One link is to Eric Meyers' site, so maybe he has some thoughts. As for showing the page, I'd have to kill you. :) It's an in-house Web application. >You >can correct yourself, however. Does your proposed fix work? If so, >you're not all washed up. If not, then you are. ;-) I'm a contractor working on an upgrade to a standards-based design. And with that comes all the wonderful social dynamics that come with walking into a worksite where the salaried personnel are annoyed they hired an "outsider". Hence, when I propose a solution, I do my homework first, with links to back it up. I'd also like to add the information to the company wiki. I think it's great to have fixes for problems, but I also think it's important to know _why_ a problem exists. E.g., dealing with the flicker bug for CSS mouse overs. I found it helped during management page review last week that, when they saw the problem, I could explain to them why it happened. What typically happens is that it goes into that black box, "Oh, it's an IE thang" and everyone nods and QA checks it off as in progress while everyone goes back to try to fix the problem. But after awhile, you can tell that management gets suspicious of this claim. Since this is a company where, even the CEO does his homework and research first, they appreciate documentation and real explanations. (This is especially true b/c most of the time, they get their design ideas from researching what the supposed benchmark standards do and, if their sites don't display the problem, then they know there's a solution. Or think they know.) >FWIW, I've never seen the need to specify each link pseudo-class >separately. Of course, I've never seen the need to specify font sizes on >the "a" element either -- the body and heading elements get font sizes, >and occasionally a footer or sidebar div, but that's it. I've found that >declaring font sizes on paragraphs, links, list items, etc, just causes >undue complication and problems. It typically happens when you have several different elements on a page where the links are quite different. We're using a complex drop down top nav with three hiearchies, ajax accordions in one quadrant of the page, popovers (like the one in the second top nav tab at amazon.com), and more. In such cases, link styles inherit unless you specify otherwise and you may not want them inheriting the styles elsewhere. For reference, the issue I'm discussing comes up in the links I posted earlier. >>http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes >> >>http://antone.geckotribe.com/alpha-gecko/2005/01/12/how-to-avoid-using-classes-in-too-many-places/ >> >>http://class.thefactoryfactory.com/docs/interm_css_selectors.html >> >>http://www.ericmeyeroncss.com/bonus/proj04-excerpt.html >> >>http://locusoptimus.com/css-trickery/ie7-hover-bug.php >> >>http://css-discuss.incutio.com/?page=IE7 >> >>http://carpe.ambiprospect.com/buttons/links.htm > Kelley= ______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7 information -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
