Problems with cascade in menus

[Stan Brown]

Line-height (Re: Problems with cascade in menus)

Thu, 07 Aug 2008 14:46:40 +1000 from dorayme
<doraymeRidThis @optusnet.com.a u>:

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.a u/alt/line-height_demo.htm l>

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

[Bergamot]

Re: Problems with cascade in menus


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

[Dr J R Stockton]

Re: Problems with cascade in menus

In comp.infosystem s.www.authoring.stylesheets message <1218013495.564 458
@angel.amnet.ne t.au>, Wed, 6 Aug 2008 17:08:18, David Morris <dlmorrisDO
NTSPAM@netwizDO NTSPAM.com.auposted:

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.demo n.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)

[dorayme]

Re: Line-height (Re: Problems with cascade in menus)

In article <MPG.2304a92396 b10798b77a@news .individual.net >,
Stan Brown <the_stan_brown @fastmail.fmwro te:

Thu, 07 Aug 2008 14:46:40 +1000 from dorayme
<doraymeRidThis @optusnet.com.a u>:

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.a u/alt/line-height_demo.htm l>

>
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

[dorayme]

Re: Problems with cascade in menus

In article <1218087276.460 646@angel.amnet .net.au>,
David Morris <dlmorrisDONTSP AM@netwizDONTSP AM.com.auwrote:

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.a u/alt/line-height_demo.htm l>

>
>
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

[dorayme]

Re: Problems with cascade in menus

In article <ZfZ5j$K0cymIFw Iy@invalid.uk.c o.demon.merlyn. invalid>,
Dr J R Stockton <jrs@merlyn.dem on.co.ukwrote:

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

[BootNic]

OT: Problems with cascade in menus

On Thu, 7 Aug 2008 17:47:48 +0100
Dr J R Stockton <jrs@merlyn.dem on.co.ukwrote in:
<ZfZ5j$K0cymIFw Iy@invalid.uk.c o.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)

iEYEARECAAYFAki bvi0ACgkQylMUzZ O6jeL5IACgxscTg Wx9iKZQ9/qziKOPONMu
dEwAoML59gBWd8U HZwnTx8ssSqW8Ds Dj
=05tJ
-----END PGP SIGNATURE-----

[Stan Brown]

Re: Line-height (Re: Problems with cascade in menus)

Fri, 08 Aug 2008 09:14:29 +1000 from dorayme
<doraymeRidThis @optusnet.com.a u>:

In article <MPG.2304a92396 b10798b77a@news .individual.net >,
Stan Brown <the_stan_brown @fastmail.fmwro te:
>

Thu, 07 Aug 2008 14:46:40 +1000 from dorayme
<doraymeRidThis @optusnet.com.a u>:

<http://netweaver.com.a u/alt/line-height_demo.htm l>

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

[David Morris]

Re: Problems with cascade in menus

dorayme wrote:

In article <1218087276.460 646@angel.amnet .net.au>,
David Morris <dlmorrisDONTSP AM@netwizDONTSP AM.com.auwrote:
>

>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.a u/alt/line-height_demo.htm l>

>>
>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.

[Felix Miata]

Re: Problems with cascade in menus

On 2008/08/09 09:56 (GMT+0800) David Morris apparently typed:

Which would be nice if I fully grokked what is going on.

Maybe this will help grokability:

http://fm.no-ip.com/auth/line-height-inherit.html

--
"Love is not easily angered. Love does not demand
its own way." 1 Corinthians 13:5 NIV

Team OS/2 ** Reg. Linux User #211409

Felix Miata *** http://fm.no-ip.com/

[David Morris]

Re: Problems with cascade in menus

Dr J R Stockton wrote:

"(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 site was tested with the latest version of Opera at the time, which
was 9.2.

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

I am sure you meant 'unnecessarily' rather the than 'foolishly'. To be
foolish would be to include Javascript on a page that highlighted why
you shouldn't use Javascript.

[Dr J R Stockton]

Re: Problems with cascade in menus

In comp.infosystem s.www.authoring.stylesheets message <1218406629.246 129
@angel.amnet.ne t.au>, Mon, 11 Aug 2008 06:20:38, David Morris <dlmorrisD
ONTSPAM@netwizD ONTSPAM.com.auposted:

>Dr J R Stockton wrote:

>"(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 site was tested with the latest version of Opera at the time, which
>was 9.2.

Irrelevant. My comment referred ONLY to that in ".." above.

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

>
>I am sure you meant 'unnecessarily' rather the than 'foolishly'. To be
>foolish would be to include Javascript on a page that highlighted why
>you shouldn't use Javascript.

You may be sure; but your first sentence is wrong. So is your second,
as it would be eminently reasonable to include a demonstration on such a
page.

For an example of Web folly, consider a site intended to support the
purchase of new computers in which the essential details are
inaccessible to those with only a moderately old computer (it is of
course OK for part of the site to demonstrate what only a new machine
can handle).

--
(c) John Stockton, nr London, UK. ?@merlyn.demon. co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demo n.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)