Dave Sherohman wrote:
> I changed the style from
>
> div.nav a:hover { color: #e4923f; background-image:
> url(imgs/nav_over.gif); }
>
> to
>
> div.nav a:hover { color: #e4923f; background-image:
> url(imgs/nav_over.gif); background-position : 0 0; }
>
> and saw no apparent effect, even after a browser restart.
Which is as expected since 'background-position : 0 0;' is the same as
not declaring background-position at all - "0 0" is the default.
May be a bit difficult to comprehend, but 'background-position : 0 50%;'
will "automagically" place the image's vertical center exactly at the
link's vertical center, and that will show.
To exemplify: I use 'background-position : 0 50%;' on nav-links on this
page...
<http://www.gunlaug.no/travel-07/travel-051.html>
...which reveals the left part of a a background-image vertically
centered, and then switches to 'background-position : 100% 50%;' on
hover to use the right part of the same background-image to show that
state. Same, but static, background-positioning on the headlines down
the page.
Now, if you resize fonts in your browser you'll see that the
background-image still stays vertically centered, and this will not
change even if you resize well beyond the point where my design can no
longer cope.
>> Also, many factors change when such constructions are subjected to
>> some form/degree of font-resizing - in all browsers, so it isn't
>> only the background on hover that needs improved alignment in your
>> page. FWIW: pixel-sized fonts don't impress any of my browsers.
>
> Any better suggestions for getting the height of the menu row and the
> items to match up instead of specifying the heights of everything in
> pixels? I'm a programmer, not a graphic designer, so when I want
> things to line up cleanly, my first instinct is to specify everything
> using (what should be) an invariant unit: the pixel. You seem to be
> saying that this isn't the best choice, but haven't said what the
> better option would be.
As a programmer you can calculate "relative and inherited values", and
the flexibility elements on a web page need is to a large degree based
on allowing browsers to recalculate "relative and inherited values".
A bit simplified: the 'em' and '%' units gives us relative values, and
those are calculated by browsers based on values inherited from an
element's parents.
Pixels are absolute values that breaks "relative and inherited". Once
you throw in pixels you "fix" dimensions, and browsers can no longer
recalculate - even if there's a need for it - as they are locked to
those pixel-values.
In most cases we don't declare 'height' on elements at all, and simply
leave it to the browsers to figure out how high an element must be to
hold its content - whatever it is. Declaring an element's width is
usually more than enough.
------
Font-size and line-height are treated a bit different. Most browsers
recompute pixel-sized fonts by default - scale the font-size, and IE/win
can be set to simply ignore font-sizes.
Not all browsers will recompute line-height though, so serious
text-overlapping and other "disasters" may occur in IE/win and Opera if
line-height is declared in pixels.
- Font-size is best declared in relative values - with relative units
like 'em' or '%', like 'font-size: .85em' or 'font-size: 85%'.
Actual font-size on an element is then calculated from font-size on the
element's parent, which means you don't have to declare anything if the
inherited font-size is ok - 'font-size: 1em' or 'font-size: 100%' means
"no change" so there's no need to declare those values.
- Line-height is in most cases best declared in unit-less numbers, like
'line-height: 1.3', while in rare cases '%' or 'em' may be best.
It depends on what you want the line-height calculated from, as
unit-less line-height values means the line-height is calculated from
font-size on the element itself, while '%' and 'em' means the
line-height is calculated from font-size on the element's parent.
Also: not declaring a line-height means line-height is inherited from
the element's parent.
> It does make sense to me that the pixel-specified heights may be the
> culprit, though, because I've never been able to figure out why a
> 14px font + 9px top padding + 9px bottom padding = 30px total (the
> height of the ul) instead of 32px...
Case please - and I would like to know the line-height at play. Numerous
ways to intentionally or unintentionally "mess up" an element's actual
dimensions. I do it intentionally all the time.
>>> Also, side question... Where can I find a good explanation of
>>> doing 'clipped' corners (as on the right sidebar) in css?
>> Don't understand what you're trying to achieve.
> [...]
> There are a ton of articles out there on doing rounded corners, each
> apparently using a completely different technique, but a) none of
> those which I've looked at directly address arbitrary custom corners
> and b) if I need to adapt one of the rounded corner examples to
> produce a straight diagnonal division rather than a curve, I would
> prefer to start from the accepted 'best' technique if one exists.
There isn't any "best". We tend to invent, or rather reinvent, methods
as we go, as we all try to create something a bit "different".
Using a prepared background-image for the edges and adding them by
setting a class on the actual elements, is what I see most often. Often
combined with a form of "css sprites"[1][2], so all link-states are in
one image which is moved around using 'background-position: (values);'
to reflect each state without having to load new images. Same as in my
example above.
regards
Georg
[1]http://alistapart.com/articles/sprites/
[2]http://css-tricks.com/css-sprites-what-they-are-why-theyre-cool-and-how-to-use-them/
--
http://www.gunlaug.no
______________________________________________________________________
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
