http://members.shaw.ca/davepatton/gps.html
In another newsgroup(related to GPS), in regards to
the above page, someone said:
----------------------------------------------------------------------
That page has quite a cryptic title: "CIS: GPS". I saved the URL in my
browser but changed the title to "Patton's GPS pages".
The headings are rather haphazard. For example, the first one ("On
This Page") is a third level heading (an <h3>), which looks strange
because it doesn't fall under an <h2>.
A little distance down the page, "Overview" is a first level heading.
Below that are titles which to me look like they deserve to be
headings, e.g., "GPS resources". However, they're just ordinary text.
I think "Links" definitely should be a heading, since there's a link
at the top of the page to jump to this section.
----------------------------------------------------------------------
The "CIS" refers to the initials of my company, and I agree I should
change it - maybe to something like "Patton"?
The reason for the <h3>On This Page:</h3> being near the top of the
page was that originally the navigation menu was at the bottom of the
HTML, but when viewed without CSS support, it meant the navigation
menu was at the bottom of the page, so I moved it to the top of the
HTML, without making changes to the heading structure :-(
I want to change the first level "Overview" headings that appear on
some of my pages, because, taken by themselves, they don't provide
any context(e.g. to search engine indexing). On the above page,
maybe something like "GPS Information Overview" would be better?
"GPS Resources" is marked up as:
<div class="heading1"><a name="resources">GPS Resources</a></div>
rather than, for example, as a second level heading. I can't recall
exactly why I did that, but it was at the time I was learning CSS,
and probably isn't "the correct way to do things".
Anyone care to offer any suggestions, either about the proper
way to structure the page/headings, or anything else on my site?
Thanks
--
Dave Patton
Canadian Coordinator, Degree Confluence Project http://www.confluence.org/
My website: http://members.shaw.ca/davepatton/ 26  2322 
Dave Patton wrote: http://members.shaw.ca/davepatton/gps.html
<snip>Description of page structure</snip>
Anyone care to offer any suggestions, either about the proper
way to structure the page/headings, or anything else on my site?
Thanks
This is easy. Write down, on a piece of paper, the structure you
want for you headings. Write it in a heirachy, so that you can see what
level each heading is at.
Start with the document title, this is heading 1. Then, list all the
section headings below that, indented one level. Then repeat for sub
headings.
For example:
CIS (<h1>)
Overview (<h2>)
Sub Heading 1 (<h3>)
Sub Heading 2 (<h3>)
Global Positioning System (<h2>)
At this Site (<h2>)
This may not be accurate, I didn't read the whole content, so I don't
understand the correct structure. Use it as a guide only.
You can either put the site navigation at the top or bottom. Either
way, be sure to include a skip link to either skip to content or skip to
navigation, depending whether it's at the top or bottom. You can hide
this skip link with CSS, but it's visible when the document is not styled.
After you've worked out you're structure, mark it up using the
correct heading elements. Wrap each heading and its associated content
within a <div>. The CSS Zen Garden does this, and I do it on my site.
So you should end up with some code like this.
<body id="cis">
<div id="container">
<h1><acronym title="C? I? S?">CIS</acronym></h1>
<!-- Fill in whatever CIS stands for in the title attribute -->
<p>content...
<div>
<h2>Overview</h2>
<p>content...</p>
<div>
<h3>Sub Heading 1</h3>
<p>content...</p>
</div>
<div>
<h3>Sub Heading 2</h3>
<p>content...</p>
</div>
</div>
<div>
<h2>Global Positioning System</h2>
<p>content...</p>
</div>
<div>
<h2>At this Site</h2>
<ul>
<li>menu items...</li>
</ul>
</div>
</div>
</body>
When you're done, validate you're page, with the outline option
selected. The outline should match the way you've structured your
headings. This link will validate you're current site, and show the
heading structure outline at the end. http://validator.w3.org/check?uri=ht...ne=1&verbose=1
--
Lachlan Hunt http://www.lachy.id.au/ la**********@lachy.id.au.update.virus.scanners
Remove .update.virus.scanners to email me,
NO SPAM and NO VIRUSES!!!
Lachlan Hunt wrote: Dave Patton wrote: http://members.shaw.ca/davepatton/gps.html
<snip>Description of page structure</snip>
Anyone care to offer any suggestions, either about the proper
way to structure the page/headings, or anything else on my site?
Thanks
[snip] After you've worked out you're structure, mark it up using the
correct heading elements. Wrap each heading and its associated
content within a <div>. The CSS Zen Garden does this, and I do it on
my site.
[snip]
Interesting. I've never considered wrapping *all* headers+content this way.
However, I often do this for deeper nesting, and I then use the following
rule. It indents the header+content. It works progressively when nested, of
course. It can make it visually clearer what the structure is, without just
relying on different styles for the headers:
div.section {
margin-left: 3em;
}
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
"Lachlan Hunt" <la**********@lachy.id.au.update.virus.scanners> wrote in
message news:on**************@news-server.bigpond.net.au... Dave Patton wrote: http://members.shaw.ca/davepatton/gps.html
<snip>Description of page structure</snip>
Anyone care to offer any suggestions, either about the proper
way to structure the page/headings, or anything else on my site?
Thanks
This is easy. Write down, on a piece of paper, the structure you
want for you headings. Write it in a heirachy, so that you can see what
level each heading is at.
[snip]
After you've worked out you're structure, mark it up using the
correct heading elements. Wrap each heading and its associated content
within a <div>. The CSS Zen Garden does this, and I do it on my site.
So you should end up with some code like this.
<body id="cis">
<div id="container">
<h1><acronym title="C? I? S?">CIS</acronym></h1>
<!-- Fill in whatever CIS stands for in the title attribute -->
<p>content...
<div>
<h2>Overview</h2>
<p>content...</p>
<div>
<h3>Sub Heading 1</h3>
<p>content...</p>
</div>
<div>
<h3>Sub Heading 2</h3>
<p>content...</p>
</div>
</div>
<div>
<h2>Global Positioning System</h2>
<p>content...</p>
</div>
<div>
<h2>At this Site</h2>
<ul>
<li>menu items...</li>
</ul>
</div>
</div>
</body>
This makes eminently good sense. It applies a real hierarchical structure to
the page, rather than one that is only implied by the alternation of heading
elements and paragraphs. It lends itself to easy and flexible styling, and
can facilitate the implementation of certain features one might occasionally
want to code in client-side script.
Harlan Messinger wrote: This makes eminently good sense. It applies a real hierarchical structure to
the page, rather than one that is only implied by the alternation of heading
elements and paragraphs. It lends itself to easy and flexible styling, and
can facilitate the implementation of certain features one might occasionally
want to code in client-side script.
Yes, it is what <div> is for — to indicate structural divisions,
however XHTML 2.0's <section> element is slightly more semantic for the
purpose I demonstrated, leaving <div> for more generic grouping or
dividing of document elements and sections. I like to use <div
class="section">, in places where I would normally use <section> if I
were writing XHTML 2.0, which helps to distinguish them from more
general uses of <div>. I just omitted that to keep the example simple.
Basically, the idea is to make the transition to XHTML 2.0 in the future
in the future easy, as soon as it becomes a standard and is supported in
Mozilla, Opera and Safari; most likely not IE [1].
Also, the structure helps to see what level heading should be used,
especially when authoring long documents (assuming the indentation has
been kept consistent).
[1] It's already a foregone conclusion that IE won't even be supporting
XHTML 1.0 when Windows Longhorn is released; at least according to Hixie
[1a], so I just don't care about IE any more (not that I ever cared much
anyway). My site won't be supporting it now, except for virtually
unstyled text/html, for backwards compatibility with other older UAs.
[1a] http://ln.hixie.ch/?start=1086158925&order=-1&count=1
--
Lachlan Hunt http://www.lachy.id.au/ la**********@lachy.id.au.update.virus.scanners
Remove .update.virus.scanners to email me,
NO SPAM and NO VIRUSES!!!
"Lachlan Hunt" <la**********@lachy.id.au.update.virus.scanners> wrote in
message news:F_****************@news-server.bigpond.net.au... Harlan Messinger wrote: This makes eminently good sense. It applies a real hierarchical
structure to the page, rather than one that is only implied by the alternation of
heading elements and paragraphs. It lends itself to easy and flexible styling,
and can facilitate the implementation of certain features one might
occasionally want to code in client-side script.
Yes, it is what <div> is for — to indicate structural divisions,
however XHTML 2.0's <section> element is slightly more semantic for the
purpose I demonstrated, leaving <div> for more generic grouping or
It's not clear to me how "section" is more semantically related to the
*division* of a document into logical *sections* (or the sectioning into
logical divisions) than "div" is.
Harlan Messinger wrote: "Lachlan Hunt" <la**********@lachy.id.au.update.virus.scanners> wrote
[snip] Yes, it is what <div> is for - to indicate structural divisions,
however XHTML 2.0's <section> element is slightly more semantic for
the purpose I demonstrated, leaving <div> for more generic grouping
or
It's not clear to me how "section" is more semantically related to the
*division* of a document into logical *sections* (or the sectioning
into logical divisions) than "div" is.
What I found attractive about "section" was that it didn't require an explicit
statement of the header-level. It simply had a header.
If a section was nested inside a 2nd-level section, its header was equivalent
(in some sense) to a <h3>. Move that section to a position in a 1st-level
section and that header is immediately equivalent to a <h2>. That is a crude
way of thinking about it. But it illustrates that "section" is
context-dependent. And that is semantically important.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message
news:bk0yc.45$sj7.31@newsfe6-win... Harlan Messinger wrote: "Lachlan Hunt" <la**********@lachy.id.au.update.virus.scanners> wrote [snip] Yes, it is what <div> is for - to indicate structural divisions,
however XHTML 2.0's <section> element is slightly more semantic for
the purpose I demonstrated, leaving <div> for more generic grouping
or
It's not clear to me how "section" is more semantically related to the
*division* of a document into logical *sections* (or the sectioning
into logical divisions) than "div" is.
What I found attractive about "section" was that it didn't require an
explicit statement of the header-level. It simply had a header.
Ah. I should have gone and looked into the details. Even cooler than I
thought.
If a section was nested inside a 2nd-level section, its header was
equivalent (in some sense) to a <h3>. Move that section to a position in a 1st-level
section and that header is immediately equivalent to a <h2>. That is a
crude way of thinking about it. But it illustrates that "section" is
context-dependent. And that is semantically important.
Dave Patton <no**@none.com> wrote: http://members.shaw.ca/davepatton/gps.html
In another newsgroup(related to GPS), in regards to
the above page, someone said:
----------------------------------------------------------------------
That page has quite a cryptic title: "CIS: GPS". I saved the URL in my
browser but changed the title to "Patton's GPS pages".
That's a quite understandable move; the user probably knows what "GPS"
is, and he wants to distinguish your page from all the other GPS pages he
has bookmarked.
But in a more general perspective, "Patton's GPS pages" isn't informative
enough. What's GPS? I'm pretty sure I could find 42 meanings for that
abbreviation, and I'm sure there are people who do not know any of them.
And Patton _who_? The general?
As the good old HTML 2.0 specification said, "The title should identify
the contents of the document in a global context. A short title, such as
"Introduction" may be meaningless out of context. A title such as
"Introduction to HTML Elements" is more appropriate." However, this is
not sufficient; there are, or could be, zillions of pages with the title
"Introduction to HTML Elements".
I would suggest something like the following:
<title>Global Positioning System (GPS) material, collected by Dave
Patton</title>
The headings are rather haphazard. For example, the first one ("On
This Page") is a third level heading (an <h3>), which looks strange
because it doesn't fall under an <h2>.
Apparently, the table of content should have <h2>. And the <h1> should
describe the page as a whole; "Overview" says remarkably little, and does
not even vaguely describe the _page_. The <title> element's content might
be a good starting point.
By the way, if you use CSS positioning to set the ToC on the right, it
would probably be better to put it _last_ in HTML markup. That way it
would not disturb people using text browsers, speech browsers, and other
linearizing browsers too much. (They don't want to see or hear the menu
each and every time they move from one page to another on your site.)
The "CIS" refers to the initials of my company, and I agree I should
change it - maybe to something like "Patton"?
Spelling out what it stands for (maybe followed by "(CIS)") would be OK.
This would associate the site with a company (maybe a small one) rather
than a private person.
The reason for the <h3>On This Page:</h3> being near the top of the
page was that originally the navigation menu was at the bottom of the
HTML, but when viewed without CSS support, it meant the navigation
menu was at the bottom of the page, so I moved it to the top of the
HTML, without making changes to the heading structure :-(
If it were a 3rd level heading, it should have <h3> irrespectively of its
placement. But it's really 2nd level. And I think the move was wrong,
except perhaps on the _main_ page. When entering a main page, the user
_might_ wish to hear the table of content first; when entering a subpage,
oh no, people don't want to hear again and again what other pages there
are.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
On Sat, 12 Jun 2004 15:41:09 +0000 (UTC),
"Jukka K. Korpela" <jk******@cs.tut.fi> posted: By the way, if you use CSS positioning to set the ToC on the right, it
would probably be better to put it _last_ in HTML markup. That way it
would not disturb people using text browsers, speech browsers, and other
linearizing browsers too much. (They don't want to see or hear the menu
each and every time they move from one page to another on your site.)
This is something that I've been playing with recently. With it at the
top, you can float it to the right, and it positions fairly well in all
browsers, and doesn't end up with text drawing over the top of text (things
flow around each other). But if it's at the bottom and you try and
reposition it at the top, that doesn't work in various browsers (they
ignore the positioning), you have to use absolute positions and sizes
(which you can't do for text, because text is an unpredictable size), and
you have to deliberately make a blank space for it in some other way, so
that it doesn't get dumped over the top of the text on the page.
You're stuck choosing between two bad options, and I've found the first one
to be less of a problem for most browsers.
--
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 delete some files yourself.
Tim <ti*@mail.localhost.invalid> wrote: With [the table of content] at
the top, you can float it to the right, and it positions fairly well
in all browsers,
Using positioning, you can put it anywhere in the markup and still have
it visually on the right, or on left, or elsewhere.
But if it's at the bottom and
you try and reposition it at the top, that doesn't work in various
browsers (they ignore the positioning),
So what? Usual CSS caveats apply anyway. If the navigation area is at the
bottom, no real harm is done, as opposite to "forcing" the user to listen
to a long list of links each and every time he moves from one page to
another (or to taking extra trouble and creating new problems by "skip
nav" links).
you have to use absolute
positions and sizes
No I don't. See e.g. http://www.cs.tut.fi/~jkorpela/styles/layout.html
(The positions are "absolute" only in the sense of being "absolute
positioning", which is positioning relative to a coordinate system.
You do _not_ need pixel units.)
You're stuck choosing between two bad options, and I've found the
first one to be less of a problem for most browsers.
Why would you try and minimize harm caused to browsers, as opposite to
minimizing harm caused to users?
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
On Sun, 13 Jun 2004 11:55:02 +0930, Tim <ti*@mail.localhost.invalid> wrote: This is something that I've been playing with recently. With it at the
top, you can float it to the right, and it positions fairly well in all
browsers, and doesn't end up with text drawing over the top of text
(things
flow around each other). But if it's at the bottom and you try and
reposition it at the top, that doesn't work in various browsers (they
ignore the positioning), you have to use absolute positions and sizes
(which you can't do for text, because text is an unpredictable size), and
you have to deliberately make a blank space for it in some other way, so
that it doesn't get dumped over the top of the text on the page.
You're stuck choosing between two bad options, and I've found the first
one
to be less of a problem for most browsers.
Not claiming this as a perfect site, but check out how I accomplished it
here... http://www.opro.org/ Many other examples exist as well - you'll
find it's not that hard once you figure it out.
Tim <ti*@mail.localhost.invalid> wrote: You're stuck choosing between two bad options, and I've found the first
one to be less of a problem for most browsers.
Neal <ne*****@yahoo.com> posted:
Not claiming this as a perfect site, but check out how I accomplished it
here... http://www.opro.org/ Many other examples exist as well - you'll
find it's not that hard once you figure it out.
That's something I have looked at, but still suffers the table layout
/magazine column look (multiple columns are a pest on a vertically
scrolling medium, and the reduce the space available for reading the actual
content).
The coding for something like that isn't too hard, but I'm looking for a
better implementation.
--
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 delete some files yourself.
Tim <ti*@mail.localhost.invalid> wrote: With [the table of content] at the top, you can float it to the right,
and it positions fairly well in all browsers,
"Jukka K. Korpela" <jk******@cs.tut.fi> posted:
Using positioning, you can put it anywhere in the markup and still have
it visually on the right, or on left, or elsewhere.
Though if you don't put it somewhere sensible, it does look bad.
But if it's at the bottom and you try and reposition it at the top,
that doesn't work in various browsers (they ignore the positioning),
So what? Usual CSS caveats apply anyway. If the navigation area is at the
bottom, no real harm is done, as opposite to "forcing" the user to listen
to a long list of links each and every time he moves from one page to
another (or to taking extra trouble and creating new problems by "skip
nav" links).
I think that a long list of links, wherever it's placed is bad news. I was
sticking to something smaller (e.g. home, help, search).
you have to use absolute positions and sizes
No I don't. See e.g. http://www.cs.tut.fi/~jkorpela/styles/layout.html
(The positions are "absolute" only in the sense of being "absolute
positioning", which is positioning relative to a coordinate system.
You do _not_ need pixel units.)
Which details most of the things I've tried.
If I simply float a menu to the right, the rest of the page can flow around
it, and I don't waste reading space below the menu.
If you carve the page into content and menu divs, you end up with a two
column display. As soon as the menu finishes, there's wasted blank space
below it for the rest of the page. Also, you have to specify widths, for
at least the menu - this isn't easy to do well (10ems for a 10 character
wide menu usually makes it far wider than needed, specifying less risks
there not being enough space on some people's displays).
You're stuck choosing between two bad options, and I've found the
first one to be less of a problem for most browsers.
Why would you try and minimize harm caused to browsers, as opposite to
minimizing harm caused to users?
Thus far, I've seen the alternatives to be more harmful to users (painful
to use).
--
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 delete some files yourself.
Tim wrote: you have to use absolute positions and sizes
"Jukka K. Korpela" <jk******@cs.tut.fi> posted:
No I don't. See e.g. http://www.cs.tut.fi/~jkorpela/styles/layout.html
(The positions are "absolute" only in the sense of being "absolute
positioning", which is positioning relative to a coordinate system.
You do _not_ need pixel units.)
Though you've still used an absolute width for that side bar (ems rather
than px). How do you determine how many ems to use? Count the characters
in your text? What about the font sizing issues?
A few of my brief experiments: http://htmltestbed.speedymail.org/
Unfortunately I lost most of my positioning experiements (I wasn't doing
them on my computer, and didn't copy them to disk). :-( But trying them
out on different browsers did show me that it seemed to be the worst way to
do it (convoluted to do, and only worked on some browsers).
--
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 delete some files yourself.
Tim wrote: Tim wrote: you have to use absolute positions and sizes
"Jukka K. Korpela" <jk******@cs.tut.fi> posted:
See e.g. http://www.cs.tut.fi/~jkorpela/styles/layout.html
You do _not_ need pixel units.)
Though you've still used an absolute width for that side bar (ems
rather than px). How do you determine how many ems to use? Count
the characters in your text? What about the font sizing issues?
Em units are based on font-size. The bigger the font-size, the larger
the width, if that width is set in em units. You have to set a width
when floating, too, if the natural width would otherwise be 100%.
trying them out on different browsers did show me that it seemed to
be the worst way to do it (convoluted to do, and only worked on
some browsers).
It's not easy, but it can be done. See url in sig for example.
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/
Tim wrote: you have to use absolute positions and sizes
"Jukka K. Korpela" <jk******@cs.tut.fi> posted:
See e.g. http://www.cs.tut.fi/~jkorpela/styles/layout.html
You do _not_ need pixel units.)
Tim wrote:
Though you've still used an absolute width for that side bar (ems
rather than px). How do you determine how many ems to use? Count
the characters in your text? What about the font sizing issues?
Brian wrote:
Em units are based on font-size. The bigger the font-size, the larger
the width, if that width is set in em units.
But not in a manner that's always so useful.
e.g. If I have some text that's ten characters wide, but if I were to set
a width of 10em, it'd be *far* wider than my text. But if I try to
compensate by using a smaller width, I might make a mess should a browser
use a font that draws some characters wider than I anticipate.
You have to set a width when floating, too, if the natural width would
otherwise be 100%.
I didn't need to when playing with lists, which was the beauty of that
approach: <http://htmltestbed.speedymail.org/htmlmenus/floated_menus.html>
trying them out on different browsers did show me that it seemed to be
the worst way to do it (convoluted to do, and only worked on some
browsers).
It's not easy, but it can be done. See url in sig for example.
Still suffers one thing I dislike, and want to avoid: A rather
significant portion of the canvas is permanently lost to a navigation bar.
--
My from address is fake, but the reply-to is real, though temporary. But I
really don't want private replies to usenet postings. Reply to the group.
Tim wrote: Brian wrote:
Em units are based on font-size. The bigger the font-size, the
larger the width, if that width is set in em units.
But not in a manner that's always so useful.
e.g. If I have some text that's ten characters wide, but if I were
to set a width of 10em, it'd be *far* wider than my text. But if I
try to compensate by using a smaller width, I might make a mess
should a browser use a font that draws some characters wider than I
anticipate.
I'm not sure I see your point. It's true that you cannot make e.g. a
nav only precisely wide enough for text links, and not 1 pixel wider.
So what? The www is not a place for pixel-perfect layout. You already
knew that, so perhaps you could explain what you mean by that.
To restate: make the positioned box wide enough for the content, leave
a small amount of breathing room, check using different font sizes. If
the user has selected a wide font, the em unit should take that into
account.
1em != 1 character You have to set a width when floating, too, if the natural width
would otherwise be 100%.
I didn't need to when playing with lists, which was the beauty of
that approach:
<http://htmltestbed.speedymail.org/htmlmenus/floated_menus.html>
Depends. Try floating a block level text container without setting a
width; now have a look in IE 5.x/Mac. ;-) And don't complain about
the browser -- it was only following the spec at the time. See url in sig for example.
Still suffers one thing I dislike, and want to avoid: A rather
significant portion of the canvas is permanently lost to a
navigation bar.
Fair enough, but you've just introduced an entirely different
complaint, one which I didn't address because it wasn't in the
discussion earlier.
--
Best,
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/
"Brian" <us*****@julietremblay.com.invalid> wrote in message
news:10*************@corp.supernews.com... Tim wrote:
Brian wrote:
Em units are based on font-size. The bigger the font-size, the
larger the width, if that width is set in em units.
But not in a manner that's always so useful.
e.g. If I have some text that's ten characters wide, but if I were
to set a width of 10em, it'd be *far* wider than my text. But if I
try to compensate by using a smaller width, I might make a mess
should a browser use a font that draws some characters wider than I
anticipate.
I'm not sure I see your point. It's true that you cannot make e.g. a
nav only precisely wide enough for text links, and not 1 pixel wider.
So what? The www is not a place for pixel-perfect layout. You already
knew that, so perhaps you could explain what you mean by that.
Perhaps his point is that topography has an 'em' unit which is the width of
a font's letter M. I remember being confused myself when I started using
CSS because its definition of 'em' units was so perversely different (I
think that the CSS unit should have been named something else). The
typographical em unit could be useful in ensuring that fixed-width blocks
will hold specific text as compactly as possible. This is not an issue of
pixel-perfect layout, but rather an issue of making optimal use of the space
available on the page.
"C A Upsdell" <cupsdell0311XXX@-@-@XXXrogers.com> wrote: Perhaps his point is that topography has an 'em' unit which is the
width of a font's letter M.
That would be a very odd point.
Technically, to set some width to ten characters, the best shot is to use
something like width: 4em or width: 5em in CSS. Roughly speaking, the
average width of characters is somewhat less than 0.5em.
ObHTML: Some HTML constructs allow the author to set (or suggest) a width
in "average characters", e.g. in <input type="text" ... size="...">. But
this has not been quite satisfactorily implemented in browsers (except
for monospace fonts), and there is no CSS equivalent (i.e., no CSS unit
corresponding to "average character width").
I remember being confused myself when I
started using CSS because its definition of 'em' units was so
perversely different
Actually, the CSS definition is far more compatible with typographical
principles than the idea of em as the width of this or that letter.
But this has been discussed... wait... 42, 43, 44, ... oh well,
_several_ times in comp.infosystems. www.stylesheets, and if problems
remain after checking its fine FAQ resources, please ask there.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
On Wed, 16 Jun 2004 19:25:46 GMT, "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> wrote:
[...] Perhaps his point is that topography...
"topography" ?
...has an 'em' unit which is the width of a font's letter M.
That "Anglo-Saxon bullshit definition" of an 'em' pops up again, just
about a week since the last time it was mentioned right here.
I remember being confused myself when I started using CSS
because its definition of 'em' units was so perversely
different
There is only one single font design available where the 'em' unit just
happens to coincide with the width of its letter 'M' and that is for a
font named "Capitalis Quadrata". CQ is in effect a reconstruction of the
font that was used in the ancient Roman Empire for carving of
inscriptions on columns, statues and the likes. (one of CQ's most famous
occurrences can be found on the "Trajanus Column" in Rome, Italy)
http://hans.presto.tripod.com/isbn/trajan.html
Due to changes in writing style and typesetting procedures over hundreds
of years after the fall of the Roman Empire, the connection between the
'em' unit and the width of letter 'M' has been lost.
Still the 'em' unit comes to its best use in typography when it is
defined as the total height of a lead block where each and every
character in a font can be casted on the same baseline.
There is historical evidence to this, available at the Plantin Moretus
Museum in Antwerp - Belgium, where the major part of Claude Garamond's
original font design work is kept. Most especially it can be seen that
CG did know that a relative unit that describes the total height of a
font would make typographical work much simpler. His design drawings for
the 'em-dash' and the white space filler 'em-square' clearly indicates
this.
(I think that the CSS unit should have been named something else)
I think that people of Anglo-Saxon origin, and "Americans" especially,
needs to study, and learn, from real history instead of inventing their
own.
The CSS 'em' unit, as originally defined in CSS1, is correct and stands
on historical facts. Haakon and Bert did their job correct on this part,
as well as for just about all parts of CSS1 as a total. http://www.css.nu/articles/typograph1-en.html
--
Rex
"Jan Roland Eriksson" <re*@css.nu> wrote in message
news:et********************************@4ax.com... On Wed, 16 Jun 2004 19:25:46 GMT, "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> wrote:
...has an 'em' unit which is the width of a font's letter M.
That "Anglo-Saxon bullshit definition" of an 'em' pops up again, just
about a week since the last time it was mentioned right here.
Maybe because there is some validity to it, e.g. see http://wvdg.westvalley.edu/wvdg-tips.../lexicon6.html among other
sources. As for "Anglo-Saxon Bullshit": my grandfather and
great-grandfather were in the print business, and they did not think it was
BS ... but then they WERE Anglo-Saxon, and perhaps such people have no
credibility in your eyes.
Brian wrote: Em units are based on font-size. The bigger the font-size, the
larger the width, if that width is set in em units.
Tim wrote:
But not in a manner that's always so useful.
e.g. If I have some text that's ten characters wide, but if I were
to set a width of 10em, it'd be *far* wider than my text. But if I
try to compensate by using a smaller width, I might make a mess
should a browser use a font that draws some characters wider than I
anticipate.
Brian <us*****@julietremblay.com.invalid> posted:
I'm not sure I see your point. It's true that you cannot make e.g. a
nav only precisely wide enough for text links, and not 1 pixel wider.
So what? The www is not a place for pixel-perfect layout. You already
knew that, so perhaps you could explain what you mean by that.
I'm not trying to achieve pixel precision, just avoid wasting a lot of
space. As my prior paragraph stated, the difference can be quite
excessive.
To restate: make the positioned box wide enough for the content, leave
a small amount of breathing room, check using different font sizes. If
the user has selected a wide font, the em unit should take that into
account.
There's two issues with that:
1. I could check a plethora of different fonts, and not come up with a
clearly useful answer.
2. The width of the words would entirely depend on what characters are
used, and that's something that can radically change with different fonts.
See url in sig for example.
Still suffers one thing I dislike, and want to avoid: A rather
significant portion of the canvas is permanently lost to a
navigation bar.
Fair enough, but you've just introduced an entirely different
complaint, one which I didn't address because it wasn't in the
discussion earlier.
Actually, it was; pretty much right from the start. Not that it matters.
--
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 delete some files yourself.
Tim wrote: Brian wrote:
Em units are based on font-size. The bigger the font-size,
the larger the width, if that width is set in em units.
2. The width of the words would entirely depend on what characters
are used, and that's something that can radically change with
different fonts.
I'm unable to duplicate this problem here. The only thing
I can think to try is to use a "word" that consists only of
"mmmmmmmmmmmmmmm" and compare it to "lllllllllllllll," which would
only illustrate how to break it in a situation that isn't terribly
likely to occur in a real authoring situation.
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/
On Thu, 17 Jun 2004 01:10:21 GMT, "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> wrote: "Jan Roland Eriksson" <re*@css.nu> wrote in message
news:et********************************@4ax.com.. .
On Wed, 16 Jun 2004 19:25:46 GMT, "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> wrote: >...has an 'em' unit which is the width of
>a font's letter M.
That "Anglo-Saxon bullshit definition" of an 'em'
pops up again...
Maybe because there is some validity to it, e.g. see
http://wvdg.westvalley.edu/wvdg-tips.../lexicon6.html among other
sources.
Oh yes; there's a lot of that "mumbo-jumbo" around, most often to be
found on www resources produced in the "big" country on the other side
of the big water.
But since you point us all to an example, let me show you that what it
has to say does not hold up to a logical analysis.
The following snip is quoted verbatim from the www resource given above.
"Em; Traditionally, the width occupied by a capital M that,
usually being a square, gave rise to a linear measurement
equal to the point size of the type being set; thus,
a 9-point em is 9 points wide. A 12-point em is generally
called a pica, or pica em, and measures 4.22mm (0.166inch).
Half and em is called an en."
"Em quad; An em space, which is the size of a square of the
type being set."
Let's now put forward the following set of questions...
1. One 'em' is equal to the width of letter 'M'.
(Yes/No)?
(don't try to answer this one just yet)
2. The point size of a type is the distance from the top
of the tallest character (with a diacritical mark)
down to the bottom edge of a character with a descender.
(Yes/No)?
(my answer here is 'Yes' and international practice is
to set the character combination 'Ép' in print on the
same baseline and then measure the resulting total
height of that combo to arrive at the point size of
"the type being set")
3. Now take this measured point size of the "type being set"
and use it to construct a square with its sides equal to
the measured point size.
Is this the square of "the type being set".
(Yes/No)?
(well, 'Yes' of course it is)
Return to question 1. to find its answer when you try to
place your letter 'M' (from the same type naturally) in
the square in a way that the 'M' fills the full width of
the square.
And your answer to question 1. is? 'Yes' or 'No' ?
Secondary question; Is your referenced source contradicting it self in
its description of what one 'em' represents?
Yes it is in fact and it is in good company. E.g. "The Oxford
Illustrated", which is said to have a level of quality as a dictionary,
manage to create an even bigger mess when it tries to describe what one
'em' represents in print.
As for "Anglo-Saxon Bullshit": my grandfather and great-grandfather
were in the print business, and they did not think it was BS ...
I had no reason to point at any one in particular but more to the fact
that this really persistent BS about the 'em' seems to have its roots in
an Anglo-Saxon printing tradition and that it is kept alive and well fed
in a traditional BS fashion.
As for BS it self, there is this document... http://www.jelks.nu/misc/articles/bs.html
....which has been available on the www as a definition of BS for as long
as I can remember.
--
Rex
Tim wrote (about setting a width for the floated object): I didn't need to when playing with lists, which was the beauty of
that approach:
<http://htmltestbed.speedymail.org/htmlmenus/floated_menus.html>
Brian <us*****@julietremblay.com.invalid> posted:
Depends. Try floating a block level text container without setting a
width; now have a look in IE 5.x/Mac. ;-) And don't complain about
the browser -- it was only following the spec at the time.
Just for curiosity's sake, can you send me a screenshot? I don't have a
Mac to play with.
--
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 delete some files yourself.
Tim wrote: Brian posted:
Try floating a block level text container without setting a
width; now have a look in IE 5.x/Mac.
Just for curiosity's sake, can you send me a screenshot? I don't
have a Mac to play with.
Neither do I. I used to test regularly on a Mac, and I couldn't
understand why floats on short elements didn't work. Then I learned
what was wrong. My sister uses a Mac at work. If noone else can do
it, I'll post a test file on the web and have her take a screen shot
for you. But this will likely take a bit of time.
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/ This discussion thread is closed Replies have been disabled for this discussion. Similar topics
7 posts
views
Thread by duncan.lovett |
last post: by
|
reply
views
Thread by hxin |
last post: by
|
2 posts
views
Thread by John B. |
last post: by
|
1 post
views
Thread by Tony Carnell |
last post: by
|
1 post
views
Thread by Larry R Harrison Jr |
last post: by
|
5 posts
views
Thread by Charles Law |
last post: by
|
3 posts
views
Thread by dennist685 |
last post: by
|
5 posts
views
Thread by MaxiWheat |
last post: by
|
1 post
views
Thread by satya.mahesh |
last post: by
|
reply
views
Thread by xavier.boneu |
last post: by
| | | | | | | | | | | | | | | | | | | |
