By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,648 Members | 1,203 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,648 IT Pros & Developers. It's quick & easy.

EOL without using <br />

P: n/a

I understand that <br /> is marginal in CSS, and so am looking for a
substitute for the EOL character. I've failed in both approaches and
seek advice.

The first thing I tried was to use the unicode EOL characer, which is
000A. I figured with was 10 in decimal notation, and so tried:

line 1 line 2

No go. What was wrong with my thinking here?

The second approach was to use a list. Since menu is deprecated, I
tried:

ul.menoo { list-style-image: none; }

<ul class="menoo">
<li>line 1</li>
<li>line 2</li>
</ul>

I still get the default dot (galeon browser).

--
Haines Brown
br****@hartford-hwp.com
kb****@arrl.net
www.hartford-hwp.com

Jul 20 '05 #1
Share this Question
Share on Google+
37 Replies


P: n/a
Haines Brown wrote:
I understand that <br /> is marginal in CSS, and so am looking for a
substitute for the EOL character. I've failed in both approaches and
seek advice.

The first thing I tried was to use the unicode EOL characer, which is
000A. I figured with was 10 in decimal notation, and so tried:

line 1 line 2

No go. What was wrong with my thinking here?
000A is whitespace, and is normalised according to normal HTML rules.

The second approach was to use a list.
For what? Why you want to start a new line is pretty important in how you
go about doing it.

Since menu is deprecated, I
tried:

ul.menoo { list-style-image: none; }

<ul class="menoo">
<li>line 1</li>
<li>line 2</li>
</ul>

I still get the default dot (galeon browser).


<URL:http://www.w3.org/TR/REC-CSS2/generate.html#lists>

The list-style-image property applies to list-items, not the lists
themselves. Furthermore, you want to set the list-style-type property to
'none' (the default is usually 'disc', which is the dot you are seeing).

--
Jim Dabell

Jul 20 '05 #2

P: n/a
Haines Brown wrote:

ul.menoo { list-style-image: none; }


ul.menoo { list-style-type: none; }

With the caveat in the other response: use the correct markup first,
then apply the css.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #3

P: n/a

"Haines Brown" <br****@teufel.hartford-hwp.com> wrote in message
news:87************@teufel.hartford-hwp.com...

I understand that <br /> is marginal in CSS,


Just curious--what do you mean by that?

Jul 20 '05 #4

P: n/a
"Harlan Messinger" <h.*********@comcast.net> writes:
"Haines Brown" <br****@teufel.hartford-hwp.com> wrote in message
news:87************@teufel.hartford-hwp.com...

I understand that <br /> is marginal in CSS,


Just curious--what do you mean by that?


Lie and Bos, Cascading Style Sheets, pg. 322-323. The context is a
discussion of HTML elements that are used to convey style and lack
content. BR is one such element.

However, they then qualify this by saying that BR is borderline
between style and content:

"Also borderline is BR. Recall that it is an empty element that
represents a hard line break; a line break will be placed where it is
used no matter how the rest of the paragraph around it is aligned or
justified. . . . It really should have been a character instead of an
element, but the intended character is not part of the Latin-1
character set. . . . With the advent of support for the Unicode
character set. . .BR could have been replaced by. . .the line
separator character. But people were used to BR, so it stuck."

I wrote without thinking regarding the construction of a list without
markers, and the correction does what I want. I often must try my best to
reproduce the appearance of a hard copy document, and menus show up
for a variety of purposes, such as the lines of someone's address.

A side question on this. Since the menu list is deprecated, is it
OK now to use it as a name, such as in <li class="menu">...?

--
Haines Brown
br****@hartford-hwp.com
kb****@arrl.net
www.hartford-hwp.com

Jul 20 '05 #5

P: n/a
Jim Dabell <ji********@jimdabell.com> writes:
Haines Brown wrote:
I understand that <br /> is marginal in CSS, and so am looking for a
substitute for the EOL character. I've failed in both approaches and
seek advice.

The first thing I tried was to use the unicode EOL characer, which is
000A. I figured with was 10 in decimal notation, and so tried:

line 1 line 2

No go. What was wrong with my thinking here?


000A is whitespace, and is normalised according to normal HTML rules.


Indeed, that's appears to be what happened when I used it. I find it
difficult sometimes to track down unicode characters. Here's what I
did in this case; where was my mistake?

UTF_&_BOM-FAQ_utf_bom.html

@@@ The Unicode Standard 3.2
@@@+ Draft U32M020305.lst
...

000A <control>
= LINE FEED (LF)
= new line (NL), end of line (EOL)
...

0085 <control>
= NEXT LINE (NEL)

0085 (decimal notation 133) gave me an elipsis. I'm obviously doing
something wrong here.

--
Haines Brown
br****@hartford-hwp.com
kb****@arrl.net
www.hartford-hwp.com

Jul 20 '05 #6

P: n/a
Haines Brown <br****@teufel.hartford-hwp.com> wrote:
0085 <control>
= NEXT LINE (NEL)
0085 (decimal notation 133) gave me an elipsis. I'm obviously doing
something wrong here.


No. It's the browsers that all treat ISO-8859-1 as Windows-1252.
Jul 20 '05 #7

P: n/a
Andreas Prilop <nh******@rrzn-user.uni-hannover.de> writes:
Haines Brown <br****@teufel.hartford-hwp.com> wrote:
0085 <control>
= NEXT LINE (NEL)
0085 (decimal notation 133) gave me an elipsis. I'm obviously doing
something wrong here.


No. It's the browsers that all treat ISO-8859-1 as Windows-1252.


Andreas. I'm not sure I follow you. Are you saying that 000A is the
correct character for EOL, but existing browsers don't know how to
handle the character and revert to the non-standard Windows character
assignments? Even though the web page has <meta
http-equiv="content-type" content="text/html; charset=UTF-8" />?

--
Haines Brown
br****@hartford-hwp.com
kb****@arrl.net
www.hartford-hwp.com

Jul 20 '05 #8

P: n/a
On Fri, 16 Jan 2004, Haines Brown wrote:
0085 <control>
= NEXT LINE (NEL)

0085 (decimal notation 133) gave me an elipsis. I'm obviously doing
something wrong here.


Well, sort-of. Unicode characters 0080 to 009F are control
characters, and excluded from use in HTML (and, as far as I know, from
XHTML).

Your browser is compounding the confusion by interpreting them as if
you meant them to be windows-1252, but this behaviour is undefined in
HTML (subtle gag: "undefined", not "illegal"), and forbidden by XML
(i.e rejected by an XML-conforming validator).

In fact, the W3C validator nowadays rejects such usage in HTML as well
as in XHTML, which is pragmatically probably a good thing, although
pedantically it's wrong. See previous discussions of the topic if you
really want to know more.

N.B don't confuse the Document Character Set (which is always
iso10646/unicode in HTML4 as in XHTML) with the external character
coding. The external character coding can indeed be windows-1252 (if
the client accepts it, via their accept-charset header if any), but
those characters then map into quite different parts of the Unicode
character space.
Jul 20 '05 #9

P: n/a
On Fri, 16 Jan 2004, Haines Brown wrote:
No. It's the browsers that all treat ISO-8859-1 as Windows-1252.
Andreas. I'm not sure I follow you.


Basically, this is simple: but for someone confused about the issues,
it seems unbelievably complex: if you want to understand it, you're
going to have to do some background reading. No offence intended, but
shooting off random questions only reveals that you won't be able to
understand the answers.
Are you saying that 000A is the correct character for EOL,
Not only is he saying it, but it's true. However, you don't seem to
understand what HTML/XHTML specifications say should be done with it.
but existing browsers don't know how to handle the character
On the contrary, they understand very well what to do with it, but it
seems that you don't. Consult your nearest copy of an (X)HTML
specification.
and revert to the non-standard Windows character assignments?
No: that was in relation to your misuse of a character in the U+008x
range.
Even though the web page has <meta
http-equiv="content-type" content="text/html; charset=UTF-8" />?


That's irrelevant in theory; in practice it's a dodge to help NN4 into
the only mode in which it correctly deals with HTML4 i18n.

Please, either give up now, or (preferably) get yourself up to speed
on the HTML4 character model (documented quite well in the HTML4.01
spec) which underlies all versions of HTML from RFC2070 through HTML4
to XHTML/anything. Questions of detail are pointless until you have a
mental model adequate to understand the answers.

I repeat, this is not intended to be offensive, but no more than a
statement of the way things are, AFAICS.
Jul 20 '05 #10

P: n/a
Haines Brown <br****@teufel.hartford-hwp.com> wrote:
No. It's the browsers that all treat ISO-8859-1 as Windows-1252.
Andreas. I'm not sure I follow you. Are you saying that 000A is the
correct character for EOL,


I think we were speaking about chars x0080 to x009F.
but existing browsers don't know how to
handle the character and revert to the non-standard Windows character
assignments? Even though the web page has <meta
http-equiv="content-type" content="text/html; charset=UTF-8" />?


At least they do this for "charset=ISO-8859-1" and for &#number;
expressions. I'm no longer sure for "charset=UTF-8". Look here:
<http://www.unics.uni-hannover.de/nhtcapri/temp/controls.html>
Neither Mozilla 1.5 nor Internet Explorer 6.0 show any "Windows
graphic characters". Which browser showed you an ellipsis?
Jul 20 '05 #11

P: n/a
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
Unicode characters 0080 to 009F are control
characters, and excluded from use in HTML (and, as far as I know, from
XHTML).
Yes.
Your browser is compounding the confusion by interpreting them as if
you meant them to be windows-1252,


Which browser does this sort of things?
<http://www.unics.uni-hannover.de/nhtcapri/temp/controls.html>
Jul 20 '05 #12

P: n/a
On Fri, Jan 16, Andreas Prilop inscribed on the eternal scroll:
Your browser is compounding the confusion by interpreting them as if
you meant them to be windows-1252,
Which browser does this sort of things?


I didn't know, not till I tried (see below). I was only trying to
make sense of the hon. Usenaut's observations.
<http://www.unics.uni-hannover.de/nhtcapri/temp/controls.html>


Wrong test. &#x85; displays as ellipsis on at least one WWW browser,
as well as on the notorious operating system component. Your URL
points to a document that doesn't seem to contain any &#number;
numerical character references, so it doesn't actually test that
issue.

--
Procrastination gives you something to look forward
to putting off tomorrow. -spotted on ahbou
Jul 20 '05 #13

P: n/a
"Alan J. Flavell" <fl*****@mail.cern.ch> wrote:
References: <87************@teufel.hartford-hwp.com>
<http://www.unics.uni-hannover.de/nhtcapri/temp/controls.html>


Wrong test. &#x85; displays as ellipsis on at least one WWW browser,


In <news:87************@teufel.hartford-hwp.com> I read

| 0085 (decimal notation 133) gave me an elipsis. I'm obviously doing
| something wrong here.

I see nothing of &#x85; or … .
Jul 20 '05 #14

P: n/a
On Sat, Jan 17, Andreas Prilop inscribed on the eternal scroll:
In <news:87************@teufel.hartford-hwp.com> I read

| 0085 (decimal notation 133) gave me an elipsis. I'm obviously doing
| something wrong here.
Indeed, and in a context that was referring back to:

|> > The first thing I tried was to use the unicode EOL characer, which
|> > is 000A. I figured with was 10 in decimal notation, and so tried:
|> >
|> > line 1 line 2

i.e the context was the use of &#number; to represent a character
whose decimal value was known.
I see nothing of &#x85; or … .


I see no mention of a character encoding, either, but I *do* see the
remark "decimal notation 133". I deduced that the most likely
explanation was that the hon. Usenaut had not tried to represent this
U+0085 control character as an actual coded character, but used an
ampersand notation. (OK, I mentioned &#x85; and I should probably
have said … instead).

And it actually fits the reported observations, too, nicht wahr?

cheers
Jul 20 '05 #15

P: n/a
I spent hours today clawing through the W3C reference for HTML
4.01, but doing so has not answered my initial question, and the
discussion that ensued only raised more issues for me.

1. I'm told _all_ browsers treat ISO-8859-1 as Windows-1252, and then
someone expresses surprise that _any_ browser does so. I'm left
uncertain.

2. The W3C reference indicates that I _must_ include a meta line to
tell the browser how to encode char references, and I have:

<meta
http-equiv="content-type"
content=""telt/html; charset=UTF-8"
/>

But then Alan says this is irrelevant? Who is right?

3. In the refrence I read about defining the unicode range, such as:

@font-face {unicode-range: U+0085;}

But when I use &#x0085; in a document, it shows up as an elipsis
(galeon) rather than generate a EOL.

4. However, the W3C reference says that the range specification is not
well-supported, and in any case, UCS is the standard default for
all browsers. I took this to mean I do not have to specify the
unicode-range at all. In any case, doing so made no difference.

5. It was suggested I take a look at
http://www.univs-hannover.de/nhtcapr.../controls.html, but wasn't told
what that page is. I get a list of numbers, 128-159 followed by
question marks. Does that mean my browser is not making sense of
Windows' use of those char refs? I didn't find anything in the W3C
documentation that addressed this issue.

5. So I remain where I started. The reference clearly stated that hex
0085 is the EOL control character. I can only assume this value
is the UCS reference number, and my understanding so far is that
browsers today should understand these references. But my effort to
reference that control character clearly didn't work and instead
only yields an elipsis.

--
Haines Brown

Jul 20 '05 #16

P: n/a
Haines Brown wrote:

The W3C reference indicates that I _must_ include a meta line to
tell the browser how to encode char references, and I have:

<meta http-equiv="content-type" content=""telt/html; charset=UTF-8"
/>

But then Alan says this is irrelevant? Who is right?


I don't know what "W3C reference" you saw, so I do not know if that
source is wrong, but Alan Flavell is right. The correct way to
announce the charset is in http headers (not the <head> of an html
document). I'm assuming you already know how to do this, so I won't
repeat myself on that point.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #17

P: n/a
Tim
On Sat, 17 Jan 2004 23:30:46 GMT,
Haines Brown <br****@teufel.hartford-hwp.com> wrote:
I spent hours today clawing through the W3C reference for HTML
4.01, but doing so has not answered my initial question, and the
discussion that ensued only raised more issues for me.

1. I'm told _all_ browsers treat ISO-8859-1 as Windows-1252, and then
someone expresses surprise that _any_ browser does so. I'm left
uncertain.
I doubt that *all* browsers do that. Maybe many of the Windows browsers
do, but I'm sure that most non-Windows browsers do not.
2. The W3C reference indicates that I _must_ include a meta line to
tell the browser how to encode char references, and I have:

<meta
http-equiv="content-type"
content=""telt/html; charset=UTF-8"
/>

But then Alan says this is irrelevant? Who is right?
There's no "must" about it. It's mostly ignored, actually. Though some
browsers (an old Netscape, if I remember correctly) will do some funny
things if you specify the information in a meta element and HTTP
headers.

4. However, the W3C reference says that the range specification is not
well-supported, and in any case, UCS is the standard default for
all browsers. I took this to mean I do not have to specify the
unicode-range at all. In any case, doing so made no difference.
Again, I'd not be as sweeping as *all* browsers. It'd only be
applicable to browsers that support unicode (not all do).

5. It was suggested I take a look at
http://www.univs-hannover.de/nhtcapr.../controls.html, but wasn't told
what that page is. I get a list of numbers, 128-159 followed by
question marks. Does that mean my browser is not making sense of
Windows' use of those char refs? I didn't find anything in the W3C
documentation that addressed this issue.
That link doesn't work here (www.univs-hannover.de has no DNS answer
data, *and* that address it's missing the http:// protocol prefix). I
can't tell what you're looking at (obviously), but I'd guess that your
browser isn't handling what's there, for whatever reason.

5. So I remain where I started. The reference clearly stated that hex
0085 is the EOL control character. I can only assume this value
is the UCS reference number, and my understanding so far is that
browsers today should understand these references. But my effort to
reference that control character clearly didn't work and instead
only yields an elipsis.


End-of-lines are ignored in the traditional sense in HTML (they're taken
as just white space, not an end-of-line). Just about the only places an
EOL character is used as an EOL, is inside pre and textarea input
elements.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

This message was sent without a virus, please delete some files yourself.
Jul 20 '05 #18

P: n/a
Haines Brown <br****@teufel.hartford-hwp.com> wrote:
> I understand that <br /> is marginal in CSS,
- - However, they then qualify this by saying that BR is borderline
between style and content:
There's a point in that statement, but it's not really the same thing
as saying that <br /> is marginal in CSS. The <br> tag, or <br /> if
you are playing the XHTML game, is simply HTML. It does not exist,
as marginal or otherwise, in CSS at all.
"Also borderline is BR. Recall that it is an empty element that
represents a hard line break; - - It really should have been a
character instead of an element,
Well, that's debatable. The XHTML 2.0 draft takes the position that
lines deserve an element of their own, the <line>...</line> element,
and you can actually simulate it in present-day HTML using
<div>...</div>. ObCSS: This gives you an element to attach CSS
properties to; you cannot attach them to a string of characters.
A side question on this. Since the menu list is deprecated, is it
OK now to use it as a name, such as in <li class="menu">...?


Well, why not? You can use mostly anything as a class name, within the
syntactic limitations. If you wish to make them mnemonic, which is a
good idea, then "menu" sounds great for a menu - rather independently
of its being the name of an HTML element (which has been used by rather
few people, not surprisingly, since browsers mostly implement it the
same way as the ul element).

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jul 20 '05 #19

P: n/a
Brian wrote:
Haines Brown wrote:

The W3C reference indicates that I _must_ include a meta line to tell
the browser how to encode char references, and I have:

<meta http-equiv="content-type" content=""telt/html; charset=UTF-8"
/>

But then Alan says this is irrelevant? Who is right?

I don't know what "W3C reference" you saw, so I do not know if that
source is wrong, but Alan Flavell is right.


I've just tried validating a page of mine (using HTML-Kit to pass the
page contents to the W3C HTML validation service).

With <head> including the meta tag
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

I get This Page Is Valid HTML 4.01 Transitional!
If I change the meta tag to
<meta http-equiv="Content-Type" content="text/html">

I get I was not able to extract a character encoding labeling from any of the
valid sources for such information. Without encoding information it is
impossible to validate the document. The sources I tried are:

The HTTP Content-Type field.
The XML Declaration.
The HTML "META" element.
And I even tried to autodetect it using the algorithm defined in
Appendix F of the XML 1.0 Recommendation.

Since none of these sources yielded any usable information, I will not
be able to validate this document. Sorry. Please make sure you specify
the character encoding in use.
This implies at the very least it is certainly acceptable to specify the
charset in <head>.
The correct way to
announce the charset is in http headers (not the <head> of an html
document). I'm assuming you already know how to do this, so I won't
repeat myself on that point.


I don't. Could someone briefly explain this to me? As far as I'm
currently aware (not far, I know), I only have control over the content
of each page's content, not (generally) over any additional data the
server provides when the page is requested. Thanks.

--
Michael
m r o z a t u k g a t e w a y d o t n e t
Jul 20 '05 #20

P: n/a
Tim <Ti*@mail.localhost> writes:
End-of-lines are ignored in the traditional sense in HTML (they're taken
as just white space, not an end-of-line). Just about the only places an
EOL character is used as an EOL, is inside pre and textarea input
elements.


This I discovered this morning, and so I ended up with two ways to do
a menu-type list:

a) set the li attribute

ul { margin-left: -2.5em; } /* optional for flush left */
li.menu-list { list-style-type: none; }

<ul>
<li class="menu-list">line 1</li>
<li class="menu-list">line 2</li>
</ul>

b) take advantage of <pre>:

line 1<pre> </pre>line 2

--
Haines Brown

Jul 20 '05 #21

P: n/a

This is hopeless. You're all bogged down in the detail without having
a clear mental model of what you're doing. Trying to clarify point by
point is probably going to be a waste of time, if you won't take the
trouble to develop that mental picture. But I'll give it a try, and
hope you'll put in some effort on your background reading...
comments continue below...

Note x-posting and suggested f'ups.

On Sun, 18 Jan 2004, Michael Rozdoba wrote:
Brian wrote:
Haines Brown wrote:
The W3C reference
WHAT "W3C reference"?
indicates that I _must_ include a meta line
I find that hard to believe. XHTML/1.0 Appendix C describes _some_
situations where such a <meta...> would have to be used, but there is
always an alternative.
the browser how to encode char references,
ABSOLUTELY NOT. Character _references_ (&#number;) are always by
reference to iso/10646/Unicode. The "charset" attribute is used
for interpreting coded characters, NOT character references.
<meta http-equiv="content-type" content=""telt/html; charset=UTF-8"
/>

But then Alan says this is irrelevant?

Irrelevant -in this context- because the charset attribute *should*
have no effect whatever on the interpretation of &#number; character
references. NN4 doesn't understand that principle, though: see the
discussion on my page
http://ppewww.ph.gla.ac.uk/~flavell/...cklist.html#s6
and supporting materials, for why it can be useful to pretend to NN4
that you are coding in utf-8 (even though you're really coding in
us-ascii)
I've just tried validating a page of mine (using HTML-Kit to pass the
page contents to the W3C HTML validation service).
[...] <meta http-equiv="Content-Type" content="text/html">

I get
I was not able to extract a character encoding labeling from any of the
> valid sources for such information.

So your server is failing to send the appropriate charset attribute on
its HTTP content-type header.
Without encoding information it is
impossible to validate the document. The sources I tried are:

The HTTP Content-Type field.
The XML Declaration.
The HTML "META" element.
It's telling the truth, but it's tangential to the issue of
interpreting &#number; notations ("numerical character references").
This implies at the very least it is certainly acceptable to specify the
charset in <head>.
No-one said it wasn't "acceptable". What they might well say is that
there are ways of doing it better. However, this still isn't germane
to the interpretation of &#number; references.
The correct way to
announce the charset is in http headers (not the <head> of an html
document).


It's a server configuration issue. I'm sure there's a note about it
at the W3C but I can't seem to put my finger on it right now.
As far as I'm currently aware (not far, I know), I only have control
over the content of each page's content, not (generally) over any
additional data the server provides when the page is requested.


"That's what they all say". And for some disadvantaged proportion it
seems to be true (their web service provider is too cheap to give them
the Tools That They Need for Doing the Job), but more often it turns
out to be just a lack of knowledge about what they can do with
..htaccess (or the corresponding features of the server that they use).

PHP, ASP etc. all have ways of doing this too. CGI - of course.

Oh, and CERT CA-2000-02 says that all servers should set the
appropriate charset attribute on their HTTP headers - it's got
security implications (though they're rather complex, and well beyond
what we could usefully discuss in detail here, I suppose).

But please, _read in context_ and quote with citations, if you're
wanting to learn anything productive from all of this. Don't just
pluck "W3C says you must" and "Alan says irrelevant" out of the air
and quote it out of context!

ttfn
Jul 20 '05 #22

P: n/a
Alan J. Flavell wrote:
This is hopeless. You're all bogged down in the detail without
having a clear mental model of what you're doing. Trying to clarify
point by point is probably going to be a waste of time, if you won't
take the trouble to develop that mental picture.
If you're going to use pronouns to refer to posters I strongly suggest
you reply to the post originating the comments you're responding to, to
make it clear to whom you are referring.

Mixing responses to several posters within one reply, by replying to any
post which contains the relevant sections at arbitrary levels of quoting
leads to confusion over who you're replying to, especially when a reader
is using a threaded display. References exist for a reason.

This is particularly important if you have a rather brusque or impolite
manner, since you will otherwise generate even more animosity than you
might otherwise do.

As far as this discusion is concerned, I don't consider that personally
I have failed to take time to develop a mental picture, even though mine
is still far from perfect.
But I'll give it a try, and hope you'll put in some effort on your
background reading... comments continue below...
Perhaps other posters might care to put in some effort on developing
interpersonal skills :)
Note x-posting and suggested f'ups.
No.

I don't read that group. I replied to a non cross posted article within
another group & replied within that group. If the content of both those
posts was off charter, I suggest this be pointed out to all involved in
the discussion, particularly the originating poster of the off topic
material.

Do not directly attempt to change the location of an existing thread; it
is extremely ill mannered.
On Sun, 18 Jan 2004, Michael Rozdoba wrote:

Brian wrote:

Haines Brown wrote:
I'll now snip out all of your comments replying to other posters, since
they confuse the issue of who's talking to whom about what.
[snip]
I've just tried validating a page of mine (using HTML-Kit to pass
the page contents to the W3C HTML validation service).

[...]
<meta http-equiv="Content-Type" content="text/html">

I get
I was not able to extract a character encoding labeling from any
of the

valid sources for such information.

So your server is failing to send the appropriate charset attribute
on its HTTP content-type header.


In that case, the problem, if there is one, might be in how HTML-Kit
passes the data to the Validator. In order that I can suggest they
correct this problem, perhaps you'll be able to help with the following
uncertainties.
Without encoding information it is impossible to validate the
document. The sources I tried are:

The HTTP Content-Type field. The XML Declaration. The HTML "META"
element.

It's telling the truth,


I expected that.
but it's tangential to the issue of interpreting &#number; notations
("numerical character references").
Yes, I am aware of that, however that is not the issue I am posting
about. This is perhaps the one mistake I have made re netiquette - while
I was correct in replying to the previous poster & thus remaining part
of the original thread, I ought to have altered the subject line
appropriately - now done.
This implies at the very least it is certainly acceptable to
specify the charset in <head>.

No-one said it wasn't "acceptable". What they might well say is that
there are ways of doing it better.


This information I seek.
However, this still isn't germane to the interpretation of &#number;
references.
Already commented on.
The correct way to announce the charset is in http headers (not
the <head> of an html document).
It's a server configuration issue. I'm sure there's a note about it
at the W3C but I can't seem to put my finger on it right now.


I'll have another look myself, shortly.
As far as I'm currently aware (not far, I know), I only have
control over the content of each page's content, not (generally)
over any additional data the server provides when the page is
requested.


"That's what they all say".


Then for once I'm in the company of the majority. How comforting. And
all the more reason for the informed few to spread the knowledge
necessary to correct this misunderstanding.
And for some disadvantaged proportion it seems to be true (their web
service provider is too cheap to give them the Tools That They Need
for Doing the Job),
Not too surprising, given the less than helpful & competent nature of
some ISPs.
but more often it turns out to be just a lack of knowledge about what
they can do with .htaccess (or the corresponding features of the
server that they use).
That quite possibly includes myself. Any chance of a link to further
information applicable to many such cases? I'll look for more info on
..htaccess.
PHP, ASP etc. all have ways of doing this too. CGI - of course.
As to be expected of anything generating html server side, I would
imagine. Good.
Oh, and CERT CA-2000-02 says that all servers should set the
appropriate charset attribute on their HTTP headers - it's got
security implications (though they're rather complex, and well beyond
what we could usefully discuss in detail here, I suppose).
Interesting.

How ought a server determine an appropriate charset? Is it a case of
assuming a reasonable default & offering webmasters the ability (via say
.htaccess) to modify this on a per page basis?

In such a case, one should suggest to the HTMLKit authors that this is
provided as a configurable option prior to uploading pages for
validation - checking out the validator shows it does offer an extended
file uploading form that allows specification of the charset, which
could be used.
But please, _read in context_ and quote with citations,
I always do, however it is difficult to know from your post whether you
intend that comment to be aimed at myself or not.
if you're wanting to learn anything productive from all of this.
I wish to learn from all my experiences. Anything else is wasteful.
Don't just pluck "W3C says you must" and "Alan says irrelevant" out
of the air and quote it out of context!
Ah, probably not aimed at myself then.
ttfn


Cheers :)

--
Michael
m r o z a t u k g a t e w a y d o t n e t
Jul 20 '05 #23

P: n/a
Michael Rozdoba wrote:
Brian wrote:
Haines Brown wrote:
<meta http-equiv="content-type" content=""telt/html;
charset=UTF-8" />

But then Alan says this is irrelevant?
Alan Flavell is right.


I've just tried validating a page of mine (using HTML-Kit to pass
the page contents to the W3C HTML validation service).

With <head> including the meta tag <meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

I get
This Page Is Valid HTML 4.01 Transitional!
How is this relevant? Alan Flavell didn't claim it was invalid. He
said it was irrelevant. But please read his comment in context.

<quote>
H Brown: Even though the web page has <meta http-equiv="content-type"
content="text/html; charset=UTF-8" />? Alan Flavell: That's irrelevant in theory; in practice it's a dodge to help NN4
into the only mode in which it correctly deals with HTML4 i18n. </quote>
This implies at the very least it is certainly acceptable to
specify the charset in <head>.
It does not imply that meta http-equiv is the best place to do it. If
you use that method, then the ua must begin parsing the document
before it finds out what charset that document is in.
The correct way to announce the charset is in http headers (not
the <head> of an html document).
This is the key.
I'm assuming you already know how to do this


I don't. Could someone briefly explain this to me?


That's what Google is for. I posted this link within the last day or
so. Here it is again.

http://ppewww.ph.gla.ac.uk/~flavell/...t/ns-burp.html
As far as I'm currently aware (not far, I know), I only have
control over the content of each page's content, not (generally)
over any additional data the server provides when the page is
requested.


Answered in the article "Netscape burp" (link above).

--
Brian http://www.tsmchughs.com
follow the directions in my address to email me

Jul 20 '05 #24

P: n/a
Michael Rozdoba wrote:

As far as this discusion is concerned, I don't consider that
personally I have failed to take time to develop a mental picture,
even though mine is still far from perfect.
It is also likely to be misleading to the op. So when you make claims
that it is "valid" to use meta http-equiv to declare a charset, you're
only clouding up the issue. It isn't invalid to declare a charset in
that manner. But it is preferable to use real http headers instead of
the "equivalent."
Alan Flavell wrote:
Note x-posting and suggested f'ups.

Michael Rozdoba wrote: No.

I don't read that group.


That's nice. But charset and http-equiv have little to do with
stylesheets.

--
Brian http://www.tsmchughs.com
follow the directions in my address to email me

Jul 20 '05 #25

P: n/a
Tim
Tim <Ti*@mail.localhost> writes:
End-of-lines are ignored in the traditional sense in HTML (they're taken
as just white space, not an end-of-line). Just about the only places an
EOL character is used as an EOL, is inside pre and textarea input
elements.


Haines Brown <br****@teufel.hartford-hwp.com> wrote:
This I discovered this morning, and so I ended up with two ways to do
a menu-type list:

a) set the li attribute

ul { margin-left: -2.5em; } /* optional for flush left */
li.menu-list { list-style-type: none; }

<ul>
<li class="menu-list">line 1</li>
<li class="menu-list">line 2</li>
</ul>
Well that is a menu (looking) type of "list." It should work on all
browser, and look nicer on modern browsers.
b) take advantage of <pre>:

line 1<pre> </pre>line 2


Which would just be some arbitrary text, and done in a very peculiar
way. I can't see how that's easier than: first line<br>second line
Or: <div>first line</div> <div>second line</div> Though both of these
still are arbitrary text (i.e. meaningless content).

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

This message was sent without a virus, please delete some files yourself.
Jul 20 '05 #26

P: n/a
Tim <Ti*@mail.localhost> writes:
Tim <Ti*@mail.localhost> writes:

Haines Brown <br****@teufel.hartford-hwp.com> wrote:
This I discovered this morning, and so I ended up with two ways to do
a menu-type list:

a) set the li attribute

ul { margin-left: -2.5em; } /* optional for flush left */
li.menu-list { list-style-type: none; }

<ul>
<li class="menu-list">line 1</li>
<li class="menu-list">line 2</li>
</ul>


Well that is a menu (looking) type of "list." It should work on all
browser, and look nicer on modern browsers.


I'd have been happier had you left out the quotes. I believe the above
markup is in fact a list.
b) take advantage of <pre>:

line 1<pre> </pre>line 2


Which would just be some arbitrary text, and done in a very peculiar
way. I can't see how that's easier than: first line<br>second line
Or: <div>first line</div> <div>second line</div> Though both of
these still are arbitrary text (i.e. meaningless content).


The context is not ease of markup, but confronting the condition that
markup define the function of elements, not their style. Indeed, <br
/> is easier, but it is considered marginal because it is used to
define style (placement of the following text on a new line). I was
informed that the technically proper way to do that (other than the
list approach above) would be to use an EOL character, and my option
(b) is just an illustration of how that can be done. I don't recommend
it.

Using <div> would also certainly work, but then what is the function
of the text so divided? None, and so this option violates the
principle that markup not be used to set style. Indeed, you yourself
note that it and <br> are text-independent. However, thy are not the
same for I gather an EOL character (although its use is peculiar, as
you say) is technically correct. The "character" does not define
a style, but is a self-contained "character," much as < and & are
characters that don't define style, but serve as controls.

--
Haines Brown
br****@hartford-hwp.com
kb****@arrl.net
www.hartford-hwp.com

Jul 20 '05 #27

P: n/a
Brian wrote:
Michael Rozdoba wrote:

As far as this discusion is concerned, I don't consider that
personally I have failed to take time to develop a mental picture,
even though mine is still far from perfect.

It is also likely to be misleading to the op.


My mental picture?
So when you make claims that it is "valid" to use meta http-equiv to
declare a charset,
I didn't make the claim. I participated in a discussion attempting to
discover the truth, during which I suggested, correctly, the the w3c
validator's output implied the above.
you're only clouding up the issue.
The truth sometimes does that, though not in this case, I suspect. And
when it does, personally I'd prefer not to pretend that reality is
simpler in order to reinforce a false model.
It isn't invalid to declare a charset in that manner. But it is
preferable to use real http headers instead of the "equivalent."
Which eventually came out in the discussion. I'm sure the OP was equally
able to gain from that, should they still be following the thread.
Alan Flavell wrote:
Note x-posting and suggested f'ups.

Michael Rozdoba wrote:
No.

I don't read that group.


That's nice.


Thank you. Your quoting of my post above, however, isn't. You've quoted
me out of context by failing to include, mention or respond to my
justification for the above.
But charset and http-equiv have little to do with stylesheets.


Agreed & if I were to start such a discussion I would use ciwah rather
than ciwas, however I was replying to a post on the above subject matter
which had been posted solely in ciwas, ref
<KHmOb.77038$5V2.96340@attbi_s53>.

I might even have agreed to the suggestion of moving to another group,
however I considered setting followups to direct the thread out of the
group to be unreasonably rude, particularly when put into the context of
the general tone of Alan J Flavell's response.

If you feel strongly that this is incorrect behaviour on my part, I
would suggest you also point this out to the poster of
<KHmOb.77038$5V2.96340@attbi_s53>, informing them that they were posting
to the wrong group, however that seems a little silly, seeing as that
poster was yourself.

This dispute over netiquette has surely run its course, no? If not, I
politely suggest taking it to email, as I have no wish to waste other
people's bandwidth.

Regards,

--
Michael
m r o z a t u k g a t e w a y d o t n e t
Jul 20 '05 #28

P: n/a
In article Michael Rozdoba wrote:
Brian wrote:
Michael Rozdoba wrote:

As far as this discusion is concerned, I don't consider that
personally I have failed to take time to develop a mental picture,
even though mine is still far from perfect.

It is also likely to be misleading to the op.


My mental picture?
So when you make claims that it is "valid" to use meta http-equiv to
declare a charset,


I didn't make the claim. I participated in a discussion attempting to
discover the truth, during which I suggested, correctly, the the w3c
validator's output implied the above.
you're only clouding up the issue.


The truth sometimes does that, though not in this case, I suspect. And
when it does, personally I'd prefer not to pretend that reality is
simpler in order to reinforce a false model.
It isn't invalid to declare a charset in that manner. But it is
preferable to use real http headers instead of the "equivalent."


Which eventually came out in the discussion. I'm sure the OP was equally
able to gain from that, should they still be following the thread.
Alan Flavell wrote:

Note x-posting and suggested f'ups.

Michael Rozdoba wrote:
No.

I don't read that group.


That's nice.


Thank you. Your quoting of my post above, however, isn't. You've quoted
me out of context by failing to include, mention or respond to my
justification for the above.


*plonk*

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #29

P: n/a
Brian wrote:
Michael Rozdoba wrote:
Brian wrote:
Haines Brown wrote:

<meta http-equiv="content-type" content=""telt/html;
charset=UTF-8" />

But then Alan says this is irrelevant?
Alan Flavell is right.

I've just tried validating a page of mine (using HTML-Kit to pass
the page contents to the W3C HTML validation service).

With <head> including the meta tag <meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

I get
This Page Is Valid HTML 4.01 Transitional!

How is this relevant? Alan Flavell didn't claim it was invalid. He
said it was irrelevant. But please read his comment in context.


I did.

The OP was trying to reach an understanding by incorporating information
he had gained from various sources. Alan stated one such piece of
information was irrelevant with no further explanation. You responded
with agreement, but no further explanation.

I was attempting to find out why it was irrelevant & what the right
method is. An efficient method to do this is to make a case for ones
current unbderstanding, in order to thrash out any errors in that model,
or come to it, the corresponding model of those others posting.

Is this against this group's charter?

<quote> H Brown:
Even though the web page has <meta http-equiv="content-type"
content="text/html; charset=UTF-8" />?
Alan Flavell:
That's irrelevant in theory; in practice it's a dodge to help NN4
into the only mode in which it correctly deals with HTML4 i18n.
</quote>
This implies at the very least it is certainly acceptable to
specify the charset in <head>.

It does not imply that meta http-equiv is the best place to do it.


No one claimed it did.
If you use that method, then the ua must begin parsing the document
before it finds out what charset that document is in.
Obviously. It must make an unsafe assumption about the charset upto that
point. I don't consider myself to be an expert on such matters, so I
take the w3c's allowance of this mechanism to imply its inadvisability
isn't on a par with that of GBH.
The correct way to announce the charset is in http headers (not
the <head> of an html document).

This is the key.


Yes, it seemed quite plausible when I read it in Alan's helpful
response. A little searching confirmed tha matter & my own small site
now complies with the optimal method, as my university run a correctly
configured Apache.
I'm assuming you already know how to do this

I don't. Could someone briefly explain this to me?

That's what Google is for.


My mistake, sorry, I clearly haven't spilled enough blood & sweat within
this group to have earned the help of those more worthy than myself. I
humbly beg your forgiveness.
I posted this link within the last day or
so. Here it is again.

http://ppewww.ph.gla.ac.uk/~flavell/...t/ns-burp.html


Thanks. That might help the OP or other readers. I found something
similar yesterday at http://www.htmlhelp.com/tools/validator/charset.html

....LOL - the above links to your quoted url; I didn't realise yesterday
I'd found my own way to Mr Flavell's site.
As far as I'm currently aware (not far, I know), I only have
control over the content of each page's content, not (generally)
over any additional data the server provides when the page is
requested.

Answered in the article "Netscape burp" (link above).


Indeed. We got there eventually.

Incidentally, in another thread I was helpfully given the following url,
which might help others who need to check how their server is describing
their content when serving it up: http://www.delorie.com/web/headers.html

Regards,

--
Michael
m r o z a t u k g a t e w a y d o t n e t
Jul 20 '05 #30

P: n/a
Michael Rozdoba wrote:

if I were to start such a discussion I would use ciwah rather than
ciwas, however I was replying to a post on the above subject matter
which had been posted solely in ciwas

If you feel strongly that this is incorrect behaviour on my part, I
would suggest you also point this out to the poster of
<KHmOb.77038$5V2.96340@attbi_s53>, informing them that they were
posting to the wrong group, however that seems a little silly,
seeing as that poster was yourself

This dispute over netiquette has surely run its course,


As has my interest in your contribution to this ng.
Bye.

--
Brian (follow directions in my address to email me)
http://www.tsmchughs.com/

Jul 20 '05 #31

P: n/a
Tim
Haines Brown <br****@teufel.hartford-hwp.com> wrote:
This I discovered this morning, and so I ended up with two ways to do
a menu-type list:

a) set the li attribute

ul { margin-left: -2.5em; } /* optional for flush left */
li.menu-list { list-style-type: none; }

<ul>
<li class="menu-list">line 1</li>
<li class="menu-list">line 2</li>
</ul>

Tim <Ti*@mail.localhost> writes:
Well that is a menu (looking) type of "list." It should work on all
browser, and look nicer on modern browsers.

Haines Brown <br****@teufel.hartford-hwp.com> wrote:
I'd have been happier had you left out the quotes. I believe the above
markup is in fact a list.
I don't know what you're complaining about. It is a "list," and it's
one that "looks" like a "menu." But I've already said that.

b) take advantage of <pre>:

line 1<pre> </pre>line 2

Which would just be some arbitrary text, and done in a very peculiar
way. I can't see how that's easier than: first line<br>second line
Or: <div>first line</div> <div>second line</div> Though both of
these still are arbitrary text (i.e. meaningless content).

The context is not ease of markup, but confronting the condition that
markup define the function of elements, not their style. Indeed, <br
/> is easier, but it is considered marginal because it is used to
define style (placement of the following text on a new line). I was
informed that the technically proper way to do that (other than the
list approach above) would be to use an EOL character, and my option
(b) is just an illustration of how that can be done. I don't recommend
it.
Please supply us with what you're informed about, to back that up.

A br element is a line break, the line ends there and a new one begins.
There's little semantic difference between a character as the end of a
line and a tag as the end of a line, other than a br element having a
*defined* purpose in HTML.
Using <div> would also certainly work, but then what is the function
of the text so divided? None, and so this option violates the
principle that markup not be used to set style. Indeed, you yourself
note that it and <br> are text-independent. However, thy are not the
same for I gather an EOL character (although its use is peculiar, as
you say) is technically correct. The "character" does not define
a style, but is a self-contained "character," much as < and & are
characters that don't define style, but serve as controls.


But you *are* proposing to use an EOL to "set a style," in just the same
manner: You're using the content to layout a page (you're not just
marking where an end of the line might be, you're trying to create a
line break on the page, there), that's not what HTML is all about. HTML
is used to delineate content, styles are used to layout the content, the
content is the content.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

This message was sent without a virus, please delete some files yourself.
Jul 20 '05 #32

P: n/a
On Sat, 17 Jan 2004, Alan J. Flavell wrote:
I deduced that the most likely
explanation was that the hon. Usenaut had not tried to represent this
U+0085 control character as an actual coded character, but used an
ampersand notation.

And it actually fits the reported observations, too, nicht wahr?


Probably. Why didn't the OP provide a sample URL? <sigh>

--
Nicht's geht mehr ohne Apostroph.

Jul 20 '05 #33

P: n/a
On Sun, 18 Jan 2004, Tim wrote:
Haines Brown <br****@teufel.hartford-hwp.com> wrote:
http://www.univs-hannover.de/nhtcapr.../controls.html


That link doesn't work here (www.univs-hannover.de has no DNS answer
data, *and* that address it's missing the http:// protocol prefix).


Some people cannot even "copy 'n' paste" and retype URLs.
<http://www.unics.uni-hannover.de/nhtcapri/temp/>
<http://www.unics.uni-hannover.de/nhtcapri/temp/controls.html>

Jul 20 '05 #34

P: n/a
Tim
Haines Brown <br****@teufel.hartford-hwp.com> wrote:
http://www.univs-hannover.de/nhtcapr.../controls.html


Tim wrote:
That link doesn't work here (www.univs-hannover.de has no DNS answer
data, *and* that address it's missing the http:// protocol prefix).


Andreas Prilop <nh******@rrzn-user.uni-hannover.de> wrote:
Some people cannot even "copy 'n' paste" and retype URLs.
<http://www.unics.uni-hannover.de/nhtcapri/temp/>
<http://www.unics.uni-hannover.de/nhtcapri/temp/controls.html>


Well, if you're referring to me retyping it, I'm not really interested
at playing guessing games with what URI someone really meant to post,
when they posted a broken one.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

This message was sent without a virus, please delete some files yourself.
Jul 20 '05 #35

P: n/a
Tim <Ti*@mail.localhost> wrote:
Haines Brown <br****@teufel.hartford-hwp.com> wrote:
http://www.univs-hannover.de/nhtcapr.../controls.html


Well, if you're referring to me retyping it,


Apparently not.
Jul 20 '05 #36

P: n/a
Andreas Prilop <nh******@rrzn-user.uni-hannover.de> writes:
Tim <Ti*@mail.localhost> wrote:
Haines Brown <br****@teufel.hartford-hwp.com> wrote:
> http://www.univs-hannover.de/nhtcapr.../controls.html


Well, if you're referring to me retyping it,


Apparently not.


No, he's referring to this Klutz ;-(

When I view the page, I see (in galeon):

128 ?
129 ?
130 ?
131 ?
132 ?
133 ?
134 ?
....

Not sure what I _should_ be seeing.

--
Haines Brown
br****@hartford-hwp.com
kb****@arrl.net
www.hartford-hwp.com

Jul 20 '05 #37

P: n/a
Haines Brown <br****@teufel.hartford-hwp.com> wrote:
[ http://www.unics.uni-hannover.de/nht.../controls.html ]
When I view the page, I see (in galeon):

133 ?
...

Not sure what I _should_ be seeing.


Well, it's OK. But you reported in an earlier message that you see
an ellipsis (...) for character 133. Presumably that was … .
Jul 20 '05 #38

This discussion thread is closed

Replies have been disabled for this discussion.