How to display a box in "em" units?

[axlq]

I'm trying to figure out how to display a box that has a width in
"em" units. So far no luck. Below is some HTML that displays two
rows of 30 'm' characters in lowercase and uppercase, followed by
a 30em-wide table and a 30em-wide div block. I'm using HTML 4.01
Transitional doctype.

================================
<p>lines of 30 M:<br>
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<br>
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmm<br>
<table width="30em" border=1 cellspacing=0 cellpadding=0>
<tr><td>30em wide table</td></tr>
</table>
<div style="border: 1px solid black; width=30em; min-width=30em; float: left;">
30em wide rectangle
</div>
================================

The resulting table appears to be 30 pixels instead of 30em. It's
very narrow.

The div block is only as wide as the containing text. It's
certainly not 30 M characters wide.

What am I doing wrong? The example above works the same in IE and
Opera.

Also, which M width is used by the "em" units? Uppercase or
lowercase? These widths are different for larger font sizes.

-A

[Chris Morris]

ax**@spamcop.net (axlq) writes:

I'm using HTML 4.01 Transitional doctype.
Why not strict?
<table width="30em" border=1 cellspacing=0 cellpadding=0>
<table style="width: 30em" border=1 ...
Also, which M width is used by the "em" units? Uppercase or
lowercase? These widths are different for larger font sizes.

Neither - it's the width of the "em quad".

--
Chris

[axlq]

In article <87************@dinopsis.dur.ac.uk>,
Chris Morris <c.********@durham.ac.uk> wrote:

ax**@spamcop.net (axlq) writes:

I'm using HTML 4.01 Transitional doctype.

Why not strict?

Does it matter? Does the behavior of "em" units change between
transitional and strict?

-A

[Jim Moe]

axlq wrote:

I'm using HTML 4.01 Transitional doctype.

Why not strict?

Does it matter? Does the behavior of "em" units change between
transitional and strict?

Yes.
No.

Transitional, as you might surmise from the term, was meant to allow a
gradual transition from pre-v4 HTML to v4. Implied in the name is
transition, temporary, for a little while, short time, placeholder, a
breather space. It was never intended for common, ongoing usage.
A more cogent reason for Strict is that browser rendering is more
uniform and predictable, especially IE.

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Eric B. Bednarz]

Jim Moe <jm***************@sohnen-moe.com> writes:

A more cogent reason for Strict is that browser rendering is more
uniform and predictable, especially IE.

Pardon, 'especially IE'?

I suppose you actually mean doctype sniffing by 'strict'.

* IE < 6 doesn't do doctpe sniffing. Double your efforts.
* IE 6 in 'standards-compliant mode' does have lots of bugs that IE 6 (and
lower) otherwise does not sport. Quadripple you efforts.
* Client side or any inbetween proxy software can unexpectedly -- and
legally -- wave good-bye to 'standards-compliant mode', and you'll
never know; say hello to voodoo-programming.
* The MSDN excuse for documentation clearly states that
'standards-compliant mode' is *not* predictable.
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011

[Tim]

ax**@spamcop.net (axlq):

Also, which M width is used by the "em" units? Uppercase or lowercase?
These widths are different for larger font sizes.

Chris Morris: Neither - it's the width of the "em quad".

The *size* used for it. It also has height, and it's not necessarily
square.

For those not wanting to look up the em quad, broadly speaking it's the
space used for printing the capital M, including the spacing that goes
around it. Much the same as when you printed using blocks (individual
letters on a block), in ye olde printing machines, it refers to the entire
size of the block, not just the size of the letter on it.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

[axlq]

In article <pa***************************@mail.localhost.inva lid>,
Tim <se**********@optusnet.com.au> wrote:

[an 'em' is] the space used for printing the capital M, including
the spacing that goes around it.

Thanks, that's good to know.

-A

[axlq]

In article <pd********************@giganews.com>,
Jim Moe <jm***************@sohnen-moe.com> wrote:

axlq wrote:

I'm using HTML 4.01 Transitional doctype.

Why not strict?

Does it matter? Does the behavior of "em" units change between
transitional and strict?

... [in Strict,] browser rendering is more
uniform and predictable, especially IE.

Okay, so I've changed the doctype to strict. It validates. It
didn't make a difference in behavior. Here's a link:

http://sunbeam.rahul.net/~unicorn/boxtest.html

Now, would someone explain to me how to display a text-container
block 30 em wide? This seems like such a simple and trivial thing
but for some reason I'm failing to grasp a key concept here.

-A

[Andy Dingley]

On Sun, 2 Apr 2006 15:40:26 +0000 (UTC), ax**@spamcop.net (axlq) wrote:

Now, would someone explain to me how to display a text-container
block 30 em wide?

Replace
width=30em;
with
width:30em;

[Jack]

axlq wrote:

Now, would someone explain to me how to display a text-container
block 30 em wide? This seems like such a simple and trivial thing
but for some reason I'm failing to grasp a key concept here.
Reading the answers people give to your questions would be a good start.
Chris Morris gave you this advice:
<table style="width: 30em" border=1 ...

The use of ems is supported in CSS, but not in HTML. Your sample
specifies the width of the table as an HTML attribute, not as a CSS
property.

Furthermore, in your <div> you specified the CSS width property using
HTML-like notation (width=30em), which CSS didn't understand. it should
have been width:30em.

--
Jack.

[Jukka K. Korpela]

Tim wrote:

ax**@spamcop.net (axlq):

Also, which M width is used by the "em" units? Uppercase or lowercase?
These widths are different for larger font sizes.

Chris Morris:

Neither - it's the width of the "em quad".

The *size* used for it.

Sigh. The em unit has been discussed _many_ times in this group and
especially where it belongs, c.i.w.a.stylesheets, but there seems to be
no end to the repetition of tales and sagas.

The em unit means the size of the font, which is by definition the
height of the font. The height of the font is a design property of the
font, _usually_ corresponding to the distance from the lowest descensor
to the highest ascensor, but this is really up to the font designer to
decide. That's it. The letter "M", or any other particular letter or
other character, has nothing to do with this. The connection between the
"em" unit and the letter "M" is purely historical (including etymology)
and best forgotten unless you are really abandoning all present-day and
future practical issues for now and want to know about history.
It also has height, and it's not necessarily square.
The em quad is really irrelevant here and just confuses people,
especially if you misrepresent its nature:
For those not wanting to look up the em quad, broadly speaking it's the
space used for printing the capital M, including the spacing that goes
around it.

Not even broadly. Did you actually test this? Set up a sequence of ten
M's and define a block with width 10em. You'll easily see that the em
unit is typically considerably larger than the width of "M", and the
proportion varies greatly by font. If some odd font has an "M" with a
width of 1em, it's just a coincidence, and a rare coincidence at that.

[axlq]

In article <e0*******************@news.demon.co.uk>,
Jack <ja**@nospam.jackpot.uk.net> wrote:

The use of ems is supported in CSS, but not in HTML. Your sample
specifies the width of the table as an HTML attribute, not as a CSS
property.
I thought HTML tags like table would accept the style modifier,
which would include CSS properties. It should be no different from
writing

<table class="wide30"...>

.... after defining the class

wide30 { width: 30em; }

Correct?
Furthermore, in your <div> you specified the CSS width property using
HTML-like notation (width=30em), which CSS didn't understand. it should
have been width:30em.

You're right. Thanks. Hmmm, interesting... fixing that mistake
now makes a box that is too wide, wider than 30em. The sample page
again:

http://sunbeam.rahul.net/~unicorn/boxtest.html

Compare the box width against the line of 30 M characters above.

-A

[axlq]

In article <e0**********@phys-news4.kolumbus.fi>,
Jukka K. Korpela <jk******@cs.tut.fi> wrote:

Set up a sequence of ten M's and define a block with width
10em. You'll easily see that the em unit is typically considerably
larger than the width of "M", and the proportion varies greatly by
font.

That's correct. What doesn't make sense to me is a length attribute
like "em" is most often used to designate HORIZONTAL lengths, when
it appears that "em" seems related to the VERTICAL height of a font.

I thought the point of "em" was to create things that adjust
properly to changes in the default font size. Unfortunately, the
width of a block in "em" units won't adjust proportionally to the
average width of the font glyphs. Is there such a unit one can use
besides "em"? "ex" perhaps?

-A

[Gus Richter]

axlq wrote:

now makes a box that is too wide, wider than 30em. The sample page
again:

http://sunbeam.rahul.net/~unicorn/boxtest.html

Compare the box width against the line of 30 M characters above.

(your original 30 M characters) != (30 EM boxes)

1. The EM box is dependant on/relative to/proportional to, the current
font size.
2. The M is designed within the EM box (a square box - em square - h=w).
3. The M height and width, within the EM box, varies with the typeface
(font) design.
4. The EM box size remains constant for the same font size, whereas the
actual M size will vary within this EM box from font to font.
5. The M within the EM box has white space above and below it not so
much for ascender and descender, but particularly for upper and lower
diacritical marks.

Keeping the above in mind, perform the following:
1. Set only one M in the line and give it a border.
- The bordered area is the EM box, em square, h=w, value in em for
height/width.
- Note the white spaces from the M to the EM box borders.
- All the characters in the font are designed within this EM box.
- White space within the EM box varies from char to char.
- With the same font size, define different fonts and note the EM
box remains constant whereas the M dimension changes.
2. Change the size and repeat the same.
- Note the differences and the constant.
3. Now set one M with a border followed by a few more M's on the same
line without borders.
- Note that the second M is partially within the first M's EM box
(or the first EM box extends over the second M).
- It is this EM box width, and not the M character width, repeated
by the number of em value calls which accounts for the em line length.
- *This explains* that the 30em line length is not the width of your
original 30 M characters as you expected, but 30 times the EM box.
4. Now place everything in 3. inside a wrapper div, give it a different
border color and specify a width in em for it (width:30em; for your
original).
- wrapper border width = the EM box width of the first M times the
em value for width.

--
Gus

[Jim Moe]

axlq wrote:

Set up a sequence of ten M's and define a block with width
10em. You'll easily see that the em unit is typically considerably
larger than the width of "M", and the proportion varies greatly by
font.
That's correct. What doesn't make sense to me is a length attribute
like "em" is most often used to designate HORIZONTAL lengths, when
it appears that "em" seems related to the VERTICAL height of a font.

An inch used to be the knuckle length of the current monarch. Is that
any less weird?
From the CSS2 spec (4.3.2 Lengths):
"The 'em' unit is equal to the computed value of the 'font-size' property
of the element on which it is used. The exception is when 'em' occurs in
the value of the 'font-size' property itself, in which case it refers to
the font size of the parent element. It may be used for vertical or
horizontal measurement. (This unit is also sometimes called the quad-width
in typographic texts.)

"The 'ex' unit is defined by the font's 'x-height'. The x-height is so
called because it is often equal to the height of the lowercase 'x'.
However, an 'ex' is defined even for fonts that don't contain an 'x'."
I thought the point of "em" was to create things that adjust
properly to changes in the default font size. Unfortunately, the
width of a block in "em" units won't adjust proportionally to the
average width of the font glyphs. Is there such a unit one can use
besides "em"? "ex" perhaps?

I do not sure what you mean by "the average width of the font glyphs."
An em is a measure based on the font-size property. As such it changes
according to the current font size value.
If I understand your question, there is no unit that adjusts to the
average width of any single line of text.

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Jukka K. Korpela]

Gus Richter wrote:

1. The EM box is dependant on/relative to/proportional to, the current
font size.
The em box is not an HTML concept, and not really a CSS concept either.
1. Set only one M in the line and give it a border.
- The bordered area is the EM box, em square, h=w, value in em for
height/width.

Oh, please. Why are you repeating the usual disinformation in a
particularly bogous manner? Did _you_ actually try what happens if you
set <span style="border:solid red 1px">M</span>? (Hint: the result is
nowhere near a square. You see this more easily if you use a large font
size. You see this even on IE, although it incorrectly omits the top
border.) Yeah, I guessed so.

[Andy Dingley]

axlq wrote:

I thought

Bad idea. Try _reading_ the spec instead of making it up.
It's fine for you to take the line "This is how it ought to work". But
how are you going to tell all the world's browsers that ?

[Jukka K. Korpela]

Jim Moe <jm***************@sohnen-moe.com> wrote:

"The 'ex' unit is defined by the font's 'x-height'. The x-height is so
called because it is often equal to the height of the lowercase 'x'.
However, an 'ex' is defined even for fonts that don't contain an 'x'."
That's the theory. In practice, browsers implement ex brutally as half of em,
i.e. 1ex as 0.5em. This defeats most of the usefulness of the ex unit, which
should be the x-height of a font. (It has no defined relationship to the
_width_ of any particular letter or letters in the general.)
I do not sure what you mean by "the average width of the font glyphs."
It's indeed a vague expression. Should be count each character once, and
which characters? All characters in a font, including, perhaps, myriads of
Chinese ideographs? Or should we weigh the widths by frequencies of
characters? Which frequencies?
If I understand your question, there is no unit that adjusts to the
average width of any single line of text.

Moreover, there _cannot_ be any such unit without a definition for "average
width". The idea is impractical, too. In HTML, there is an "average width"
concept; the size="..." attribute of <input type="text" ...> should express
the suggested visible width in terms of average-width characters. This has
been implemented lousily, partly because it really cannot be implemented
properly without additional definitions.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Andy Dingley]

Jim Moe wrote:

An inch used to be the knuckle length of the current monarch. Is that
any less weird?

Not for any measuring system I'm aware of (possibly Egyptian or
Russian). In the English system we picked one monarch (James I) then
used them as an ongoing standard. We didn't redefine for each reign.

[Tim]

Tim:

For those not wanting to look up the em quad, broadly speaking it's the
space used for printing the capital M, including the spacing that goes
around it.

Jukka K. Korpela: Not even broadly. Did you actually test this?
I read up on M, N and x spacing from where they originated, in print
publishing long ago. I wrote about what I discovered. Though we all know
that print doesn't translate into web, I described the M quad, as was
brought up in the thread.

Testing anything in a web browser is generally a pointless exercise, they
get so many things wrong that you don't know which problem you're picking
over.

And did you actually read what I said? "it's the space used for printing
the capital M, including the spacing that goes around it." I didn't
mention width, but you then harped on about it as if I did:
Set up a sequence of ten M's and define a block with width 10em. You'll
easily see that the em unit is typically considerably larger than the
width of "M", and the proportion varies greatly by font. If some odd
font has an "M" with a width of 1em, it's just a coincidence, and a rare
coincidence at that.

I've done that before, and got the same results, and for the reason that I
mentioned: It's not the size of the visible part of the letter M, it's
(traditionally) the size of the printing block for the M. Which is the
quad, whether or not people like that, and not its width but its size(as I
said).

For instance, some font's M *may* be rendered thus:

+-------------+
| |
| MM MM |
| MMM MMM |
| MMMM MMMM |
| MM MMMM MM |
| MM MM MM |
| MM MM |
| MM MM |
| |
| |
+-------------+

With the obvious height and width of the character itself, plus spacing
around it (where I've drawn a crude illustrative border) so it doesn't jam
immediately against characters along any side of it. That is the M quad.

It may well be taller than it is wide, and it's size, not width (as I
said) that describes what the M quad dimension is. So several M spaces
can be wider than several letter Ms in succession. I expect that, I don't
know why you suggest that I wouldn't.

Do other tests, like draw a 3em by 3em box (e.g. a fixed width div), and
sometimes you'll get a square, sometimes you'll get a rectangle. Now, if
browsers took the EM to be the height of the EM quad, you'd expect that
test to always draw a square, just with differing overall dimensions
depending on the font its basing it on.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

[VK]

Tim wrote:

Do other tests, like draw a 3em by 3em box (e.g. a fixed width div), and
sometimes you'll get a square, sometimes you'll get a rectangle. Now, if
browsers took the EM to be the height of the EM quad, you'd expect that
test to always draw a square, just with differing overall dimensions
depending on the font its basing it on.

Also one may google for "kerning pairs" to make the picture totally
clear.

For regular (non-fixed) fonts the only meaningful horizontal unit is
*particular* string consisting of *particular* characters in
*particular* combinations.

One can still use em's for horizontal dimensions (nothing wrong in
that). One just has to live with very wide approximations it implies.

[Jukka K. Korpela]

Tim <ti*@mail.localhost.invalid> wrote:

Tim:

For those not wanting to look up the em quad, broadly speaking it's the
space used for printing the capital M, including the spacing that goes
around it.

Jukka K. Korpela:

Not even broadly. Did you actually test this?

I read up on M, N and x spacing from where they originated, in print
publishing long ago. I wrote about what I discovered. Though we all know
that print doesn't translate into web, I described the M quad, as was
brought up in the thread.

Testing anything in a web browser is generally a pointless exercise,

I guess that counts as a "No" answer. You could have taken the question as
rhetoric only, instead of continuing your misinformed off-topic lecture.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Spartanicus]

Tim <ti*@mail.localhost.invalid> wrote:

Do other tests, like draw a 3em by 3em box (e.g. a fixed width div), and
sometimes you'll get a square, sometimes you'll get a rectangle.
Never seen that, care to elaborate under which condition or with which
browser you are getting this with? Are you sure you weren't looking at a
white space issue? http://homepage.ntlworld.ie/spartanicus/temp.htm
Now, if
browsers took the EM to be the height of the EM quad, you'd expect that
test to always draw a square, just with differing overall dimensions
depending on the font its basing it on.

CSS defines the em unit relative to the "em square", it doesn't expand
on this other than to say it is a concept used in typography, but I've
always assumed that it was relative to the width of said "em square",
regardless of whether it was used to specify a CSS width or height.

--
Spartanicus

[axlq]

In article <11**********************@e56g2000cwe.googlegroups .com>,
Andy Dingley <di*****@codesmiths.com> wrote:

axlq wrote:

I thought
Bad idea. Try _reading_ the spec instead of making it up.

I did. Perhaps you should withhold snide remarks until you do
the same. The HTML 4 spec clearly states that 'style' is a legal
attribute within a table tag. And a width modifier within a style
attribute requires a number to express width, and that number can be
expressed in em units.

http://www.w3.org/TR/html4/struct/tables.html
It's fine for you to take the line "This is how it ought to work". But
how are you going to tell all the world's browsers that ?

I don't say "this is how it ought to work" without first having a
spec to tell me that it ought to work. You presume too much.

-A

[axlq]

In article <Xn*****************************@193.229.4.246>,
Jukka K. Korpela <jk******@cs.tut.fi> wrote:

I do not sure what you mean by "the average width of the font glyphs."

It's indeed a vague expression. Should be count each character once, and
which characters? All characters in a font, including, perhaps, myriads of
Chinese ideographs? Or should we weigh the widths by frequencies of
characters? Which frequencies?

Sorry, what I meant was this: It would be really useful if there was
available a length unit, dependent on the specified language type,
that represented a weighted average character glyph width based on
the frequency of characters typical of that language.

The research on character frequencies within various language has
already been done. See for example character rankings at
http://www.bckelk.uklinux.net/words/etaoin.html or frequencies in the
English language at
http://www.central.edu/homepages/Lin...etterfreq.html
and for Belarusian at http://www.pravapis.org/art_letter_frequency.asp

The point is, I think a length unit based on that would be far more
useful for scaling horizontal sizes than something like em or ex. I
am frankly surprised that the HTML or CSS specs don't include such
a thing. It wouldn't be hard to implement, seeing that most of the
underlying work has already been done.

(Chinese characters, by the way, are pretty much fixed-width, or
at least mostly so, so the width unit would be trivially simple to
calculate.)

If I understand your question, there is no unit that adjusts to the
average width of any single line of text.

Moreover, there _cannot_ be any such unit without a definition for "average
width". The idea is impractical, too. In HTML, there is an "average width"
concept; the size="..." attribute of <input type="text" ...> should express
the suggested visible width in terms of average-width characters. This has
been implemented lousily, partly because it really cannot be implemented
properly without additional definitions.

What it takes are two things:
1. a document language type
2. letter frequency statistics for that language

The resulting unit won't be perfect, but I bet it would serve as a
better approximation than anything in use now.

-A

[Harlan Messinger]

axlq wrote:

I'm trying to figure out how to display a box that has a width in
"em" units. So far no luck. Below is some HTML that displays two
rows of 30 'm' characters in lowercase and uppercase, followed by
a 30em-wide table and a 30em-wide div block. I'm using HTML 4.01
Transitional doctype.

================================
<p>lines of 30 M:<br>
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<br>
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmm<br>
<table width="30em" border=1 cellspacing=0 cellpadding=0>
<tr><td>30em wide table</td></tr>

You can't use explicit units in HTML attributes. HTML only deals with
pixels, and you don't mention them explicitly: width="30" means 30
pixels. For em, you need to use CSS, as you do in the style attribute
for the DIV tag below. But there, you use equals signs, which are
invalid. You knew to use colons for border and float; why did you use
equals signs for width and min-width?
</table>
<div style="border: 1px solid black; width=30em; min-width=30em; float: left;">
30em wide rectangle
</div>

[Steve Pugh]

axlq wrote:

Andy Dingley <di*****@codesmiths.com> wrote:

axlq wrote:

I thought
Bad idea. Try _reading_ the spec instead of making it up.

I did. Perhaps you should withhold snide remarks until you do
the same. The HTML 4 spec clearly states that 'style' is a legal
attribute within a table tag.

It is. But your original table didn't use the style attribute.
And a width modifier within a style
What's a "modifier"? HTML has a width attribute, CSS has a width
property.
attribute requires a number to express width, and that number can be
expressed in em units.
The CSS width property can take a value expressed in ems, the HTML
width attribute can not.

Your original code:
<table width="30em" border=1 cellspacing=0 cellpadding=0>
uses no style attribute, just a width attribute and the rules for the
width attribute are defined at the URL that you give next...
http://www.w3.org/TR/html4/struct/tables.html

If you had double checked the contents of that page you would have
seen.

<!ELEMENT TABLE - -
(CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)>
<!ATTLIST TABLE -- table element --
%attrs; -- %coreattrs, %i18n, %events --
summary %Text; #IMPLIED -- purpose/structure for speech
output--
width %Length; #IMPLIED -- table width --

Where %Length is defined as
<!ENTITY % Length "CDATA" -- nn for pixels or nn% for percentage length
-->

Hence you can see that the HTML spec allows the width attribute to take
values expressed in either raw numbers (to be interprted as pixels) or
percentages. Nothing else.

Your code should have read
<table style="width: 30em" border=1 cellspacing=0 cellpadding=0>

If you had done this and corrected the syntax error in your div then
the div and the table would have been the same width. This would be
30ems, which, as you've probably gathered by now, under CSS rules is 30
times the font size, not 30 times the width of the letter M.

Steve

[Andy Dingley]

axlq wrote:

In article <11**********************@e56g2000cwe.googlegroups .com>,
Andy Dingley <di*****@codesmiths.com> wrote: Perhaps you should withhold snide remarks until

I did, until you showed yourself to be an arrognat tosser. One minute
you're mouthing off about worldwide CSS support levels on mobile
devices, the next you're trying to specify CSS properties with an
equals sign.

[Jim Moe]

Andy Dingley wrote:

An inch used to be the knuckle length of the current monarch. Is that
any less weird?

Not for any measuring system I'm aware of (possibly Egyptian or
Russian). In the English system we picked one monarch (James I) then
used them as an ongoing standard. We didn't redefine for each reign.

My understanding was that before James I the inch changed with each new
king. Finally the rational community had enough and insisted on an
unchanging standard.

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[axlq]

In article <11*********************@i39g2000cwa.googlegroups. com>,
Steve Pugh <st**********@gmail.com> wrote:

It is. But your original table didn't use the style attribute.
Ah. You're correct. Nevermind. I was trying to get a table that
changed its width dependent on font size without resorting to CSS
at first, and failed, and then got all confused about what I did.
Somehow I got it in my head that I used a style attribute in the
table.
The CSS width property can take a value expressed in ems, the HTML
width attribute can not.

Got it now. Thanks.

-A

[axlq]

In article <49************@individual.net>,
Harlan Messinger <hm*******************@comcast.net> wrote:

You can't use explicit units in HTML attributes. HTML only deals with
pixels, and you don't mention them explicitly: width="30" means 30
pixels. For em, you need to use CSS, as you do in the style attribute
for the DIV tag below. But there, you use equals signs, which are
invalid. You knew to use colons for border and float; why did you use
equals signs for width and min-width?

Why? A moment of perfect stupidity on my part. Yes, I know better.
Sorry to inflict it on the group. As penance I will ponder the HTML
mess of the HTML source at gmail.com.

-A

[axlq]

In article <11**********************@z34g2000cwc.googlegroups .com>,
Andy Dingley <di*****@codesmiths.com> wrote:

Perhaps you should withhold snide remarks until
I did, until you showed yourself to be an arrognat tosser. One minute

'arrognat'?
you're mouthing off about worldwide CSS support levels on mobile
devices,
You have me confused with someone else. All I mouthed off about was
the ridiculousness (to me) of browsing the web on a mobile phone. I
made no comments about CSS support.
the next you're trying to specify CSS properties with an
equals sign.

Anyway, apologies for my dumb mistakes. Such moments are occuring with
alarming frequency these days....

-A

[Andy Dingley]

axlq wrote:

I did, until you showed yourself to be an arrognat tosser. One minute

'arrognat'?

http://community.livejournal.com/spellfecker/33519.html

[Tim]

On Mon, 03 Apr 2006 13:13:14 +0000, Jukka K. Korpela sent:

I guess that counts as a "No" answer.
Obviously you haven't read the whole message, as I specifically answered
that part further below.
You could have taken the question as rhetoric only, instead of
continuing your misinformed off-topic lecture.

Just because you don't like being told what an EM quad is, and disagree
with others definition (I didn't define it), doesn't make you correct.
You seem to set yourself up as knowing everything, careful that you don't
run out of oxygen up their on your high horse.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

[Tim]

Tim <ti*@mail.localhost.invalid> wrote:

Do other tests, like draw a 3em by 3em box (e.g. a fixed width div),
and sometimes you'll get a square, sometimes you'll get a rectangle.

Spartanicus: Never seen that, care to elaborate under which condition or with which
browser you are getting this with? Are you sure you weren't looking at a
white space issue? http://homepage.ntlworld.ie/spartanicus/temp.htm
That was the same sort of test I did (sizing a <div></div> with no space
between them), trying out various different browsers probably about a year
or two ago (Opera, MSIE, Mozilla, k-meleon, galeon, and a couple of others
that I can't recall). It seemed odd at the time, but I was more concerned
with some other issue to test.
CSS defines the em unit relative to the "em square", it doesn't expand on
this other than to say it is a concept used in typography, but I've always
assumed that it was relative to the width of said "em square", regardless
of whether it was used to specify a CSS width or height.

If it truly were an em "square" it wouldn't matter if you were measuring
its width or height. ;-)

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

[Jukka K. Korpela]

Tim <ti*@mail.localhost.invalid> wrote:

You seem to set yourself up as knowing everything, careful that you don't
run out of oxygen up their on your high horse.

Please keep using your forged From field as the common indicator of bogosity
and disgusting personal attacks behind a fake identity. There seems to be
little risk in missing _anything_ related to HTML _or_ worth reading if we
plonk you.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[axlq]

In article <11**********************@e56g2000cwe.googlegroups .com>,
Andy Dingley <di*****@codesmiths.com> wrote:

axlq wrote:

>I did, until you showed yourself to be an arrognat tosser. One minute

'arrognat'?

http://community.livejournal.com/spellfecker/33519.html

Made me chuckle... thanks.
-A

[Dr John Stockton]

JRS: In article <11**********************@i39g2000cwa.googlegroups .com>
, dated Mon, 3 Apr 2006 04:45:56 remote, seen in news:comp.infosystems.w
ww.authoring.html, Andy Dingley <di*****@codesmiths.com> posted :

Jim Moe wrote:

An inch used to be the knuckle length of the current monarch. Is that
any less weird?

Not for any measuring system I'm aware of (possibly Egyptian or
Russian). In the English system we picked one monarch (James I) then
used them as an ongoing standard. We didn't redefine for each reign.

I don't believe either of those, for England, except perhaps for much
earlier dates.

I have a reliable book - "Mass Length and Time" by Prof Norman Feather
(1959), which says that Henry VII's standard yard was still extant; and
that, by AD 950, a standard yard (of 36 inches) was kept at Winchester.

--
© John Stockton, Surrey, UK. *@merlyn.demon.co.uk / ??*********@physics.org ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)

[Yukky Korpulent]

And when I say "we" plonk you, I'm utilizing, of course the "Pluralis
Majestatis"--specfically, the bloated plurality of my big ego and even
bigger head. And, yes, I _am_ a smug, bombastic boob.

Yucky,
Yukka Korpulent