Problems with cascade in menus

dorayme wrote:

You might find that so much attention to font specification is a
maintenance worry in the long term. But your mileage might vary. What
worries me about the approach is that you seem commited to so much font
specification. Look at how many times font-size etc is repeated. It is
nice if you can get to the stage where you can rely on the natural
cascade to work for you. I can understand that you have travelled a long
road and would be reluctant to do wholesale changes at this point. But I
just mention for the future at least.

Yes, both situations are true. I did the menu first and then set the
font sizes as that was by far the easier change (though I had a pretty
quick and dirty approach by then!).

I am not sure if you know there is an issue with line height being
specified in units. There could be some circumstances where you might
consciously want units but for the most part it is safest to use line
height as a mere proportion without units. I see that I have something
on this that explains the idea a bit:

I thought 1.5em was proportional to the font-size of the parent element.
I was doing this because I had read somewhere that your eyes follow
text better if the line height is consistent, though I can't remember
where, and may have got in wrong in any event.

Thu, 07 Aug 2008 14:46:40 +1000 from dorayme
<doraymeRidThis (AT) optusnet (DOT) com.au>:

I am not sure if you know there is an issue with line height being
specified in units. There could be some circumstances where you might
consciously want units but for the most part it is safest to use line
height as a mere proportion without units. I see that I have something
on this that explains the idea a bit:

http://netweaver.com.au/alt/line-height_demo.html

Thanks for posting this. I don't specify text size in pixels, of
course, but I've been doing line heights in em or % rather than a
unitless proportion.

If I understand your page correctly, where problems come up in using
units for line-height is for inheritance nd not in the specific
selector where it's specified. Would that be an accurate summary?

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you

David Morris wrote:

Bergamot wrote:

Why do you think 64em should *ever* equal 768px? There is absolutely no
relationship between em and px. This is your downfall - expecting
everyone to use particular browser default text sizes.

The 'em' unit is equal to the computed value of the 'font-size' property

Which has nothing to do with px. 1em could be 10px or 30px.

The default size for
‘medium’ text in browsers is about 16px

So what? Not everyone uses those defaults, and that is where you are
failing. You are *depending* on your visitors using those defaults.

If we change font size to 62.6 % we make 0.1em ~ 1px in most browsers.

And what about the rest of us?

It all comes down to the insane desire to absolutely control the type
size of your visitors. Let that go and the web will be a happier place
for a lot of us.

If you insist on using smaller than 100% type for body text, there are
much better ways to do that without punishing those of us who need large
text.

--
Berg

In comp.infosystems.www.authoring.stylesheets message <1218013495.564458
@angel.amnet.net.au>, Wed, 6 Aug 2008 17:08:18, David Morris <dlmorrisDO
NTSPAM (AT) netwizDONTSPAM (DOT) com.au> posted:

I actually am not aware of anyone who says the page is unreadable.

IE7, default settings.

It overrides my preferred text font with one which, for equal legibility
to me, needs to be larger. The lists, while not actually unreadable,
are undesirably small-font.

"(One would expect most Opera users to be using the very latest
version)" - but Opera 9.5 has dropped (AFAICS) a useful feature present
in 9.2 - CtrlAltV.

The paragraph under "Comment on this page" is objectionably small. Its
last sentence only says that details will not be released in the manner
outlined : it needs a comma.

The comments textarea is foolishly narrow. BTW, one can add a button to
do rows++.



Antipodeans may - very briefly - be amused by my gullible.htm in IE.



GENERAL NOTE, UNRELATED TO THAT PAGE - It has occurred to me, a bad
typist who sometimes, for example, puts foe instead of for and fails to
notice, that it should be useful to read Google's French (etc.,)
translation, assuming that one knows some French. In my contexts, the
occurrence in the translation of "l'ennemi" is much easier to notice.
Granted, there will be false positives - the translation of that page
seems to mention fleas, for example.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

In article <MPG.2304a92396b10798b77a (AT) news (DOT) individual.net>,
Stan Brown <the_stan_brown (AT) fastmail (DOT) fm> wrote:

Thu, 07 Aug 2008 14:46:40 +1000 from dorayme
doraymeRidThis (AT) optusnet (DOT) com.au>:
I am not sure if you know there is an issue with line height being
specified in units. There could be some circumstances where you might
consciously want units but for the most part it is safest to use line
height as a mere proportion without units. I see that I have something
on this that explains the idea a bit:

http://netweaver.com.au/alt/line-height_demo.html

Thanks for posting this. I don't specify text size in pixels, of
course, but I've been doing line heights in em or % rather than a
unitless proportion.

I chose px only to keep the same units for both font-size, line height
and the ruler for the demo. I know you don't.

If I understand your page correctly, where problems come up in using
units for line-height is for inheritance nd not in the specific
selector where it's specified. Would that be an accurate summary?

Roughly so. Unless you have special requirements in mind (I can think of
one or two but I won't bore anyone with them unless they don't think
there could be such a cases), it is better practice to use unitless.
Why? Because for most purposes there are only downsides doing otherwise.

There are the downsides I demonstrated in the URL provided, and this can
spring out of nowhere in a complex site. It can trip authors when they
are adding descendant elements later. Better to play safe and engage the
built in safeguard of proportionality of setting as a pure number. Plus,
less typing! <g>

--
dorayme

In article <1218087276.460646 (AT) angel (DOT) amnet.net.au>,
David Morris <dlmorrisDONTSPAM (AT) netwizDONTSPAM (DOT) com.au> wrote:

dorayme wrote:

I am not sure if you know there is an issue with line height being
specified in units. There could be some circumstances where you might
consciously want units but for the most part it is safest to use line
height as a mere proportion without units. I see that I have something
on this that explains the idea a bit:
http://netweaver.com.au/alt/line-height_demo.html


I thought 1.5em was proportional to the font-size of the parent element.
I was doing this because I had read somewhere that your eyes follow
text better if the line height is consistent, though I can't remember
where, and may have got in wrong in any event.

Clearly, line height should be more or less consistent within a
paragraph of same sized text. But if you are relying on the actual (em
or px) line height of the parent element to dictate the line height of a
child or grandchild, then it will result in what no one would want as I
tried to example.

If you want consistent readability, you have two choices.

(1) Use units with line-height but watch your back all the time, and be
ready to hand code more line heights for the children and grandchildren
so readability and commonsense prevails.

(2) Don't use units and relax and let one (or very few) line height
declarations do the job for the trunk and branches.

--
dorayme

In article <ZfZ5j$K0cymIFwIy (AT) invalid (DOT) uk.co.demon.merlyn.invalid>,
Dr J R Stockton <jrs (AT) merlyn (DOT) demon.co.uk> wrote:

Antipodeans may - very briefly - be amused by my gullible.htm in IE.

Would non-Antipodeans find it amusing:

(1) Not at all?

(2) More than briefly?

--
dorayme

On Thu, 7 Aug 2008 17:47:48 +0100
Dr J R Stockton <jrs (AT) merlyn (DOT) demon.co.uk> wrote in:
<ZfZ5j$K0cymIFwIy (AT) invalid (DOT) uk.co.demon.merlyn.invalid>

[snip]

"(One would expect most Opera users to be using the very latest
version)" - but Opera 9.5 has dropped (AFAICS) a useful feature
present in 9.2 - CtrlAltV.

The feature is still there, just the keyboard shortcuts have changed.

http://snapshot.opera.com/950a1-keyboard.html

The old shortcuts are still available if you choose "Opera 9.2
Compatible" in Preferences > Advanced > Shortcuts.

http://help.opera.com/Windows/9.50/en/keyboard.html

[snip]

--

BootNic Thu Aug 7, 2008 11:31 pm
The human mind treats a new idea the same way the body treats a
strange protein; it rejects it.
*P. B. Medawar*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkibvi0ACgkQylMUzZO6jeL5IACgxscTgWx9iK ZQ9/qziKOPONMu
dEwAoML59gBWd8UHZwnTx8ssSqW8DsDj
=05tJ
-----END PGP SIGNATURE-----

Fri, 08 Aug 2008 09:14:29 +1000 from dorayme
<doraymeRidThis (AT) optusnet (DOT) com.au>:

In article <MPG.2304a92396b10798b77a (AT) news (DOT) individual.net>,
Stan Brown <the_stan_brown (AT) fastmail (DOT) fm> wrote:

Thu, 07 Aug 2008 14:46:40 +1000 from dorayme
doraymeRidThis (AT) optusnet (DOT) com.au>:
http://netweaver.com.au/alt/line-height_demo.html

If I understand your page correctly, where problems come up in using
units for line-height is for inheritance nd not in the specific
selector where it's specified. Would that be an accurate summary?

Roughly so. Unless you have special requirements in mind (I can think of
one or two but I won't bore anyone with them unless they don't think
there could be such a cases), it is better practice to use unitless.
Why? Because for most purposes there are only downsides doing otherwise.

Yes, I agree. The intent of my question was to make sure that I
understood the actual problem.

It's an easy enough change for me. I have a fair number of line-
heights in my CSS right now, but about half those are "normal" and
several of the others are redundant as I look at the cascade, so this
is a good opportunity to simplify.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you

dorayme wrote:

In article <1218087276.460646 (AT) angel (DOT) amnet.net.au>,
David Morris <dlmorrisDONTSPAM (AT) netwizDONTSPAM (DOT) com.au> wrote:

dorayme wrote:

I am not sure if you know there is an issue with line height being
specified in units. There could be some circumstances where you might
consciously want units but for the most part it is safest to use line
height as a mere proportion without units. I see that I have something
on this that explains the idea a bit:
http://netweaver.com.au/alt/line-height_demo.html

I thought 1.5em was proportional to the font-size of the parent element.
I was doing this because I had read somewhere that your eyes follow
text better if the line height is consistent, though I can't remember
where, and may have got in wrong in any event.

Clearly, line height should be more or less consistent within a
paragraph of same sized text. But if you are relying on the actual (em
or px) line height of the parent element to dictate the line height of a
child or grandchild, then it will result in what no one would want as I
tried to example.

I remember now, that part of this approach was to set padding or margin
to add up to the same value as line height. Just to make sure I have
understood this, ...by specifying 'ems' you are using the parent
containers font-size to specify the line height, where as just the
number is the font size of the text in the element.

The effect I wanted was to have everything based on a ratio of 1.5 of
the typical body text font (as displayed not the element). What ever I
actually got, I liked it enough, and so stuck with that. This means
that the spacing around heading and larger fonts 'should' add up to some
number that is an integer multiplier of the line-height of this basic
body text style -- I think.

If you want consistent readability, you have two choices.

(1) Use units with line-height but watch your back all the time, and be
ready to hand code more line heights for the children and grandchildren
so readability and commonsense prevails.

And this looks like what I have done.

(2) Don't use units and relax and let one (or very few) line height
declarations do the job for the trunk and branches.

Which would be nice if I fully grokked what is going on. I need to
revisit by quick and dirty approach and sort this out so I actually do
understand what is going on. A few changes to just 1.5 made things look
very odd.