- From: Bruno <bruno5544@gmail.com>
- Date: Wed, 26 Jan 2011 21:58:27 +0100
- To: www-style@gtalbot.org
- Cc: Alan Gresley <alan@css-class.com>, W3C style mailing list <www-style@w3.org>
[Sorry for my bad French] Salut Gérard, Le problème est déjà résolu avec l'un de ces échantillons donnés. Appréciez l'aide, Bruno 2011/1/26 "Gérard Talbot" <www-style@gtalbot.org>: > > Le Mer 26 janvier 2011 4:48, Bruno a écrit : >> In this sample :hover doesn't work properly, it moves down for 1px, > > In which browser and browser version do you see this vertical 1px offset? > Can you upload your example somewhere and give us an url? > >> what would be solution to this? >> >> <!DOCTYPE HTML> >> <html> >> <head> >> <style type="text/css"> >> #css { >> text-align:center; >> font-size:20px; >> background-color:white; >> width:400px; >> height:100px; >> border: 1px solid red; >> -moz-border-radius:20px; >> } >> #css a { > > If you want to make parsing faster, then often it is better to use the > child selector instead of the descendant selector. > >> text-align:center; > > text-align is inherited > http://www.w3.org/TR/CSS21/text.html#alignment-prop > So, there is no need to redeclare again text-align: center since you set > it on your #css container. > >> font-size:20px; > > font-size is inherited > http://www.w3.org/TR/CSS21/fonts.html#font-size-props > So, here too, there is no need to redeclare again font-size:20px; since > you already set it on your #css container.. > >> text-decoration:none; >> color:blue; > > blue is best for unvisited links because it is the default color in > browsers for unvisited links. Here, your design will change override the > normal, default color for visited links. > > " > 8. Non-standard link colors (score: severe) > (...) users rely on the link colors to understand what parts of the site > they have visited. I often see users bounce repeatedly among a small set > of pages, not knowing that they are going back to the same page again and > again. (Also, because non-standard link colors are unpleasantly frequent, > users are now getting confused by any underlining of text that is not a > link.) > " > "Top Ten Mistakes" Revisited Three Years Later > http://www.useit.com/alertbox/990502.html > > Change the Color of Visited Links > http://www.useit.com/alertbox/20040503.html > > >> } >> >> #css a:hover { >> display:inline-block; >> text-align:center; >> font-size:20px; >> background-color:yellow; >> width:400px; > > Setting a width on an inline-block is not always best or required. By > default, inline-block "shrink-to-fit" the content. Here, I bet you would > be better with display: block and then not declare width at all, not set > width at all. > > E.g.: In this testpage > http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/CSSColumnarLayoutThatFails1.html > the links in the navigation menu in the left column are styled as display: > block, not as display: inline-block. > >> height:100px; >> text-decoration:none; > > Setting text-decoration: none for links is, in my opinion, not a good > user-friendly decision. It's not a pro-accessibility design choice in my > opinion. > >> border: 1px solid red; >> -moz-border-radius:20px; >> } > > IMO (just a hunch but a strong one), you are most likely over-declaring > and over-defining. > >> >> </style> >> </head> >> >> <body> >> <div id="css"><a href="#">test</a></div> >> >> </body> >> </html> > > If we knew exactly for what you are doing this (say, a vertical navigation > menu of links, non-DHTML, not javascript driven), then we would be able to > better help you. Knowing that, we could then realize that inline-block may > not be what would be best for your webpage goals/requirements. > > regards, Gérard > -- > CSS 2.1 Test suite RC5 (January 11th 2011) > http://test.csswg.org/suites/css2.1/20110111/html4/toc.html > > Contributions to CSS 2.1 test suite > http://www.gtalbot.org/BrowserBugsSection/css21testsuite/ > > Web authors' contributions to CSS 2.1 test suite > http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html > >
Received on Wednesday, 26 January 2011 21:08:38 UTC