HighDots Forums  

Problems with cascade in menus

Cascading Style Sheets Layout/presentation on the WWW (comp.infosystems.www.authoring.stylesheets)


Discuss Problems with cascade in menus in the Cascading Style Sheets forum.



Reply
 
Thread Tools Display Modes
  #41  
Old   
dorayme
 
Posts: n/a

Default Re: Problems with cascade in menus - 08-09-2008 , 10:32 PM






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

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

I think you have the idea. People do have trouble with this one. With a
unit, the line height is set in stone, imprinted by the circumstances of
the particular font size of the element referenced in its definition:

elementA {line-height: 1.3em;}

If elementA happens to have 2em font-size (twice "normal"), then a child
or grandchild of elementA that had a "normal" font-size will have an
inappropriate line-height. It will get, whether it likes it or not, the
one that was appropriate to the ancestor, namely the one calculated for
2em. (To see the calculation, best to look at the URL above)

Without a unit, the shackle is off. The pure number acts as a ratio or
proportion that takes its cue from the font-size of the element it finds
itself in.

An analogy might be two types of imaginary genes. One gives the bearer
the ability to adapt to circumstances, the other imposes something more
rigid.

Quote:
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.
I can only suggest to remove all reference to line height to begin
with.. To then carefully introduce one statement at the body level. See
the effect. You might might want a bigger line height for some sections
than others. So at the top level of those sections, enter the different
value. But be very sparing and operate at the highest levels and leave
off the units. You will find this easier to understand and maintain in
the long run.

It strikes me that if you are employing a complicated font decking out
scheme (clagnut), this could complicate things to do with line height
quite considerably. I have not gone into this. I prefer to avoid these
schemes in order to keep better track of what I am doing. But ymmv...

--
dorayme


Reply With Quote
  #42  
Old   
Felix Miata
 
Posts: n/a

Default Re: Problems with cascade in menus - 08-10-2008 , 04:05 PM






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

Quote:
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/


Reply With Quote
  #43  
Old   
David Morris
 
Posts: n/a

Default Re: Problems with cascade in menus - 08-10-2008 , 06:20 PM



Dr J R Stockton wrote:
Quote:
"(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.

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


Reply With Quote
  #44  
Old   
Dr J R Stockton
 
Posts: n/a

Default Re: Problems with cascade in menus - 08-11-2008 , 07:39 AM



In comp.infosystems.www.authoring.stylesheets message <1218406629.246129
@angel.amnet.net.au>, Mon, 11 Aug 2008 06:20:38, David Morris <dlmorrisD
ONTSPAM (AT) netwizDONTSPAM (DOT) com.au> posted:
Quote:
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.

Quote:
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.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)


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.