Hi,
I always thought that "1em" equals one line height. But if I replace
<br><hr><br>
by
<hr style="margin: 1em 0;">
tables above and below the <hr> get closer in IE as well as FF.
This brings me to the question: What's a <br>, expressed in CSS*?
*) with no margins and padding defined elsewhere
Axel
PS: Here's the sample code I've been using to test the effect:
<html>
<body>
<table border=1><tr><td>a</td></tr></table>
<br><hr><br>
<table border=1><tr><td>b</td></tr></table>
</body>
</html>
---------------------------------------------
<html>
<body>
<table border=1><tr><td>a</td></tr></table>
<hr style="margin: 1em 0">
<table border=1><tr><td>b</td></tr></table>
</body>
</html> 16  8386 
"Axel Dahmen" <NO*****@NoOneKnows.invalid> wrote: I always thought that "1em" equals one line height.
No, it equals the height of the font. The line-height is normally a
little bit larger, typically about 1.15 times larger.
But if I replace
<br><hr><br>
by
<hr style="margin: 1em 0;">
tables above and below the <hr> get closer in IE as well as FF.
Of course as there are no lines of text to be broken by the <br>s the
first example it's possible that some browsers will ignore the <br>s
and hence the second example will create larger spaces. There's also
the possibility of different default margin sizes for <hr> in
different browsers. So you're not really comparing like with like.
This brings me to the question: What's a <br>, expressed in CSS*?
Nothing. <br> is a line break. There's CSS to control where an element
can insert line breaks but line breaks by definition have no size or
anything else that could be styled.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
On Mon, 31 Jan 2005 00:18:15 +0100, "Axel Dahmen"
<NO*****@NoOneKnows.invalid> wrote: I always thought that "1em" equals one line height.
No; that's wrong.
http://www.css.nu/articles/typograph1-en.html#Ch22
http://www.css.nu/articles/typograph1-en.html#Ch23
But if I replace
<br><hr><br>
by
<hr style="margin: 1em 0;">
tables above and below the <hr> get closer in IE as well as FF.
Yea; whatever "happens" is probably correct depending on various value
assignments to properties.
This brings me to the question: What's a <br>, expressed in CSS*?
markup as e.g.
<p>Hello<span>World</span></p>
style rule...
p>span:before { content: "\A" }
suggestst rendering of the text as...
Hello
World
http://www.w3.org/TR/CSS21/generate....ropdef-content
There is no box generated for the empty BR element, following that there
is nothing to suggest a style for. A BR element merely breaks a line at
it's location in markup, in exactly the same way as the line would have
been broken anyway had it been long enough not to fit in its containing
element.
PS: Here's the sample code I've been using to test the effect:
You are supposed to produce a URL for us where you have your test case.
--
Rex
Steve Pugh <st***@pugh.net> wrote: I always thought that "1em" equals one line height.
No, it equals the height of the font.
Indeed. What's difficult here is what the height of the font means, but we
can hopefully skip that in this discussion.
The line-height is normally a
little bit larger, typically about 1.15 times larger.
I would say 1.2 is closer to typical browser defaults. CSS 1 recommends 1.1
in its default style sheet for HTML, CSS 2 says 1.33, CSS 2.1 draft used to
say 1.12em (which is not the same as 1.12, really) but was then fixed to
1.12. Confusing, is it not? And for most fonts commonly used, 1.12 is too
small.
There's unfortunately no way to make line-height depend on the browser's
actual choice of font (which can be affected, but not controlled, by an
author style sheet). This makes me think line-height: 1.25 is generally the
least of evils.
But when setting the spacing between two consecutive tables, such
considerations don't need to play any role. Just set a suitable bottom
margin for the first table, or a suitable top margin for the second table.
If you absolutely must do your best to create _some_ space between the two
tables in non-CSS browsing situations, putting <p> </p> is probably
the simplest way. (By HTML specifications, browsers are required to ignore
that attempt - assuming we interpret the construct as an empty paragraph,
which is a little debatable - but we know they don't do anything that
sophisticated.)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote: Steve Pugh <st***@pugh.net> wrote:
The line-height is normally a
little bit larger, typically about 1.15 times larger.
I would say 1.2 is closer to typical browser defaults.
I set a font-size of 60px and took screenshots in IE6, FF1 and Opera
7.54. The distance between adjacent baselines was 67px in IE6 and
Opera and 69px in Firefox. That's a default line-height of (approx)
1.12 for IE and Opera and (exactly) 1.15 for Firefox.
(For the record: the font was Arial in each case, the page triggered
Standards mode, all three browsers were running on WinXP, no user
stylesheets that could affect line-height were in use, the top of
ascender to bottom of descender (using h and p) distance was 55px in
all three browsers.)
The last point may be important. If font-size: 60px gives text where
most characters fit inside a box 55px tall then the line-height will
_appear_ to be about 1.2
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Steve Pugh <st***@pugh.net> wrote: The line-height is normally a little bit larger, typically about 1.15
times larger.
I would say 1.2 is closer to typical browser defaults.
I set a font-size of 60px and took screenshots in IE6, FF1 and Opera
7.54. The distance between adjacent baselines was 67px in IE6 and
Opera and 69px in Firefox.
How did you measure the distance between baselines? I played a little with
testing the behavior of unstyled text with respect to the same text styled
with line-height.
That's a default line-height of (approx)
1.12 for IE and Opera and (exactly) 1.15 for Firefox.
I did a simple test with a paragraph of text, duplicated in two p elements,
with the style sheet
p { width: 40%; float: left; border: solid red 1px}
and with line-height set for the second p element explicitly. For 60px
Arial, on IE6, the paragraphs are identical when the setting for the second
paragraph is line-height: 1.12. But, for example,
- for Arial Unicode MS at 12pt size, line-height: 1.3 makes the paragraphs
appear similarly to each other
- for Times New Roman at 12pt size, line-height: 1.2 creates a match (and
so does 1.16).
So the situation really varies, by font family among other things.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote: Steve Pugh <st***@pugh.net> wrote:
The line-height is normally a little bit larger, typically about 1.15
times larger.
I would say 1.2 is closer to typical browser defaults.
I set a font-size of 60px and took screenshots in IE6, FF1 and Opera
7.54. The distance between adjacent baselines was 67px in IE6 and
Opera and 69px in Firefox.
How did you measure the distance between baselines?
I took screenshots and measured the distance in PhotoShop.
That's a default line-height of (approx)
1.12 for IE and Opera and (exactly) 1.15 for Firefox.
I did a simple test with a paragraph of text, duplicated in two p elements,
with the style sheet
p { width: 40%; float: left; border: solid red 1px}
and with line-height set for the second p element explicitly. For 60px
Arial, on IE6, the paragraphs are identical when the setting for the second
paragraph is line-height: 1.12. But, for example,
- for Arial Unicode MS at 12pt size, line-height: 1.3 makes the paragraphs
appear similarly to each other
One could hazard a guess that Arial Unicode, having a larger repetoire
of characters, has some glyphs that are "larger".
That implies that when the spec talks about line-height thus: "The
used value of the property is this number multiplied by the element's
font size" it is deliberately being vague when it says font size
(note, not font-size).
Which I think brings us back to the very good point you made about
1.12 and 1.12em not being the same.
- for Times New Roman at 12pt size, line-height: 1.2 creates a match (and
so does 1.16).
Assuming you're using a browser where 12pt = 16px then 1.2 = 19.2 and
1.16 = 18.56, so one would hope that they would both round off to
19px. That's one of the reasons I used a large font size for my tests.
So the situation really varies, by font family among other things.
So we can conclude that fonts vary. Who'd have guessed? ;-)
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
On Mon, 31 Jan 2005 13:33:30 +0000, Steve Pugh <st***@pugh.net> wrote: "Jukka K. Korpela" <jk******@cs.tut.fi> wrote:
Steve Pugh <st***@pugh.net> wrote: The line-height is normally a
little bit larger, typically about 1.15 times larger.
I would say 1.2 is closer to typical browser defaults.
I set a font-size of 60px and took screenshots in IE6, FF1 and Opera
7.54. The distance between adjacent baselines was 67px in IE6 and
Opera and 69px in Firefox. That's a default line-height of (approx)
1.12 for IE and Opera and (exactly) 1.15 for Firefox.
[...]...the top of ascender to bottom of descender (using h and p)
distance was 55px in all three browsers.
Maybe it should be noted that western typographical conventions calls
for the use of the char sequence Ép to determine the size of a font.
The last point may be important. If font-size: 60px gives text where
most characters fit inside a box 55px tall then the line-height will
_appear_ to be about 1.2
Does this following article have any influx on your studies? http://www.css.nu/articles/line-height.html
--
Rex
Jan Roland Eriksson <jr****@newsguy.com> wrote: On Mon, 31 Jan 2005 13:33:30 +0000, Steve Pugh <st***@pugh.net> wrote:
I set a font-size of 60px and took screenshots in IE6, FF1 and Opera
7.54. The distance between adjacent baselines was 67px in IE6 and
Opera and 69px in Firefox. That's a default line-height of (approx)
1.12 for IE and Opera and (exactly) 1.15 for Firefox.
[...]...the top of ascender to bottom of descender (using h and p)
distance was 55px in all three browsers.
Maybe it should be noted that western typographical conventions calls
for the use of the char sequence Ép to determine the size of a font.
Indeed. I measured that value as well and for font-size: 60px it was
66px in all three browsers. The last point may be important. If font-size: 60px gives text where
most characters fit inside a box 55px tall then the line-height will
_appear_ to be about 1.2
Does this following article have any influx on your studies?
http://www.css.nu/articles/line-height.html
It's something that I've read in the past (and Eric Meyer's much more
in depth study that it links to). I don't think anything there dirctly
adds to or contradicts what I stated but is good background material
on the subject of line-height in general.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Hi, Steve,
thanks for helping me!! :)
So there is no unit representing line-height? This brings me then to some
curious thought: How can a paragraph's margin possibly be defined to give a
straight layout in a two column text like:
asdjfök ajks öjklö
dsf dfs gaerh sadfas
fffd fd
dfas dfr jkgfh hjjkfg
fasf df fasdfdfasf
without such unit?
Axel
---------------------------------------
"Steve Pugh" <st***@pugh.net> schrieb im Newsbeitrag
news:i9********************************@4ax.com... "Axel Dahmen" <NO*****@NoOneKnows.invalid> wrote:
I always thought that "1em" equals one line height.
No, it equals the height of the font. The line-height is normally a
little bit larger, typically about 1.15 times larger.
But if I replace
<br><hr><br>
by
<hr style="margin: 1em 0;">
tables above and below the <hr> get closer in IE as well as FF.
Of course as there are no lines of text to be broken by the <br>s the
first example it's possible that some browsers will ignore the <br>s
and hence the second example will create larger spaces. There's also
the possibility of different default margin sizes for <hr> in
different browsers. So you're not really comparing like with like.
This brings me to the question: What's a <br>, expressed in CSS*?
Nothing. <br> is a line break. There's CSS to control where an element
can insert line breaks but line breaks by definition have no size or
anything else that could be styled.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Steve Pugh wrote: "Axel Dahmen" <NO*****@NoOneKnows.invalid> wrote:
I always thought that "1em" equals one line height.
No, it equals the height of the font. The line-height is normally a
little bit larger, typically about 1.15 times larger.
Well it's a fine point, but no 'em' does not equal the 'line-height' of
a font, but the 'width' of the font's capital 'M'. This can vary among
fonts of the same size depending on the font's characteristics. 1em for
a 12pt 'Wide Latin' will be different than a compressed font like 1em of
12pt 'Impact'.
em=width of 'M' character
en=width of 'N' character
px=1 pixel dependent on device resolution
pt=approx 1/72 of an inch, computers use 1/72 I believe***
cm=1 centimeters...
***Unfortunately at present I have found different OS's and browsers can
wildly 'disagree' on the size of the same font displayed at the same
resolution when specified in points! We can only hope in time... ;-)
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO http://www.LittleWorksStudio.com
On Thu, 3 Feb 2005, Jonathan N. Little wrote: Well it's a fine point, but no 'em' does not equal the 'line-height' of
a font, but the 'width' of the font's capital 'M'. This can vary among
fonts of the same size depending on the font's characteristics. 1em for
a 12pt 'Wide Latin' will be different than a compressed font like 1em of
12pt 'Impact'.
em=width of 'M' character
en=width of 'N' character
Sorry, but this is nonsense. It's only a *historical* explanation of
the terms "em" and "en". Today, em = font size and en = half font size.
Please refer to <news:comp.fonts> .
--
Mars, unlike Earth, has no atmosphere.
The Chicago manual of style, 15th ed., p. 362
"Jonathan N. Little" <lw*****@centralva.net> wrote: Steve Pugh wrote: "Axel Dahmen" <NO*****@NoOneKnows.invalid> wrote:
I always thought that "1em" equals one line height.
No, it equals the height of the font. The line-height is normally a
little bit larger, typically about 1.15 times larger.
Well it's a fine point, but no 'em' does not equal the 'line-height' of
a font,
I already said that it didn't. It equals the height of the font.
but the 'width' of the font's capital 'M'.
Not any more it doesn't. It originally did 2000 years ago but it
hasn't done so for some time.
This can vary among
fonts of the same size depending on the font's characteristics. 1em for
a 12pt 'Wide Latin' will be different than a compressed font like 1em of
12pt 'Impact'.
No, the em is dependent on the height of the font, not on the width of
any particular character (think of all the fonts that don't contain a
glyph for M).
The CSS definitions for the various length units can be found at
<http://www.w3.org/TR/CSS21/syndata.html#length-units>
For a more general explanation of what the em is in modern typography
see, for example, <http://en.wikipedia.org/wiki/Em_(typography)>
en=width of 'N' character
No such unit in CSS.
px=1 pixel dependent on device resolution
In CSS the px unit is defined differently but browsers ignore this and
treat 1px as one screen pixel.
pt=approx 1/72 of an inch, computers use 1/72 I believe***
In CSS 1pt is exactly 1/72 of an inch. Computers have different ways
of working out how many pixels 1 inch equals.
***Unfortunately at present I have found different OS's and browsers can
wildly 'disagree' on the size of the same font displayed at the same
resolution when specified in points! We can only hope in time... ;-)
Most browsers don't bother to work out what the resolution is and then
to work out how many pixels and inch should be. Instead they assume
that a fixed number of pixels equals one inch. Most modern browsers
say that 96px = 1 inch, so 12pt = 96/72 * 12 = 16 pixels, the default
in most browsers. Some older Mac browsers use 72px = 1 inch. Other
values are also used.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
But if there is no such unit representing line-height then, how can a
paragraph's margin possibly be defined to give a straight layout in a multi
column text like it's used in print media like magazines:
-------------------------------
| asdjfök | ajks öjklö |
| dsf dfs | gaerh sadfas |
| fffd fd | |
| dfas dfr | jkgfh hjjkfg |
| fasf df | fasdfdfasf |
-------------------------------
?
Axel
Axel Dahmen <NO*****@NoOneKnows.invalid> wrote: But if there is no such unit representing line-height then, how can a
paragraph's margin possibly be defined to give a straight layout in a multi
column text like it's used in print media like magazines:
-------------------------------
| asdjfök | ajks öjklö |
| dsf dfs | gaerh sadfas |
| fffd fd | |
| dfas dfr | jkgfh hjjkfg |
| fasf df | fasdfdfasf |
-------------------------------
?
I'm assuming that you want the space between the paragraphs on the right to
match the line-height of the paragraph on the left, so the lines of text on
the left stay aligned with the lines of text on the right.
If you set the line-height to a ratio (e.g., "line-height: 1.25") or to an
em-based value (e.g., "line-height: 1.25em"), then you can use an em-based
value for the margins/padding between the paragraphs (e.g., 1.25em).
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/
"Cheaters never win; they just finish first." - Johhny Hart
Jonathan N. Little wrote: Steve Pugh wrote:
"Axel Dahmen" <NO*****@NoOneKnows.invalid> wrote:
I always thought that "1em" equals one line height.
No, it equals the height of the font. The line-height is normally a
little bit larger, typically about 1.15 times larger.
Well it's a fine point, but no 'em' does not equal the 'line-height' of
a font, but the 'width' of the font's capital 'M'. This can vary among
fonts of the same size depending on the font's characteristics. 1em for
a 12pt 'Wide Latin' will be different than a compressed font like 1em of
12pt 'Impact'.
em=width of 'M' character
en=width of 'N' character
px=1 pixel dependent on device resolution
pt=approx 1/72 of an inch, computers use 1/72 I believe***
cm=1 centimeters...
***Unfortunately at present I have found different OS's and browsers can
wildly 'disagree' on the size of the same font displayed at the same
resolution when specified in points! We can only hope in time... ;-)
In general, em is a non-optimal measure for things on a computer screen.
As you correctly point out, different software can interpret and 'em'
very differently.
em was really only designed to be consistent within the same document
(assuming the same font). Useful for print designers.
--RC
On Wed, 16 Feb 2005, Rick Cook wrote:
[after a comprehensive quote, despite not addressing any of the points
raised in the quote.] In general, em is a non-optimal measure for things on a computer
screen.
Nonsense. For text there's nothing better. For images which need to
match text, it's debatable - but only because browser resizing
routines for pixel-based image formats are less than ideal. It would
be great with vector-based images.
As you correctly point out, different software can interpret and
'em' very differently.
Are you talking about the user's choice of text size? Then it's
working as designed.
http://www.w3.org/WAI/GL/css2em.htm
Or are you talking about a particular bug in a particular browser?
em was really only designed to be consistent within the same document
Eh?
(assuming the same font).
Oh yes, you do have a possible point (no pun intended) there.
That's what font-size-adjust was supposed to address, though its
definition was a bit muddled, and it didn't seem to get implemented
anyway, which is kind-of a shame.
Useful for print designers.
I'd say just the opposite. Print designers produce a product that
outputs to a fixed physical size. pt units would be good for that, in
a way that they can't be for computer displays. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: fis |
last post by:
Hi all,
I've problem because there are needed break lines in my texts on the
web site but i can't do it :(
My pipeline looks like: XMS -> I18N -> XSLT -> HTML
I have lot of texts in my...
|
by: Lasse |
last post by:
I have done this simple function, it seems to work as intended, to
solve a problem i have had for a while. I couldnt find any sample
around that was working for me.
I would like to test it with...
|
by: red |
last post by:
If I have <span>text</span> <br> and then some text
isn't there sopposed to be a line break between the span and the text ?
Why do browsers ignore the <br> ?
|
by: noor.rahman |
last post by:
I have an XML file that stores data from an HTML form. I use XSL to
display the data in HTML format. The data may have newline characters.
However, XSL is not displaying the newlines properly in...
|
by: meltedown |
last post by:
Earlier, there was a discussion of why not to use <br>s too much. I
mostly don't like using <br>s at all but there is one situation where
its seems better than the alternative.
<h4> this is the...
|
by: Winshent |
last post by:
I have a multi line text in an admin page on my cms.
I am trying to capture carriage returns as and replace them with
<p></p> bfore the string gets written to the database.
I have tried all...
|
by: Winshent |
last post by:
I have a multi line text in an admin page on my cms.
I am trying to capture carriage returns as and replace them with
<p></p> bfore the string gets written to the database.
I have tried all...
|
by: Summercoolness |
last post by:
so i am starting to use more of <br /and <div style="clear: both" /
which is the XHTML style...
now, won't those actually confuse the old browsers? for example,
will the old browser treat the...
|
by: Nathan Sokalski |
last post by:
Something that I recently noticed in IE6 (I don't know whether it is true
for other browsers or versions of IE) is that it renders <br/and <br></br>
differently. With the <br/version, which is what...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
