EOL without using <br />

**Haines Brown** · Jul 20 '05, 09:22 PM

Re: EOL without using <br />

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  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
https://www.univs-hannover.de/nhtcap.../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

**Brian** · Jul 20 '05, 09:22 PM

Re: EOL without using <br />

Haines Brown wrote:[color=blue]
>
> 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?[/color]

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

**Tim** · Jul 20 '05, 09:22 PM

Re: EOL without using <br />

On Sat, 17 Jan 2004 23:30:46 GMT,
Haines Brown <brownh@teufel. hartford-hwp.com> wrote:
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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?[/color]

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.

[color=blue]
> 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.[/color]

Again, I'd not be as sweeping as *all* browsers. It'd only be
applicable to browsers that support unicode (not all do).

[color=blue]
> 5. It was suggested I take a look at
> https://www.univs-hannover.de/nhtcap.../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.[/color]

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.

[color=blue]
> 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.[/color]

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.

**Jukka K. Korpela** · Jul 20 '05, 09:22 PM

Re: EOL without using <br />

Haines Brown <brownh@teufel. hartford-hwp.com> wrote:
[color=blue][color=green][color=darkred]
>> > I understand that <br /> is marginal in CSS,[/color][/color][/color]
- -[color=blue]
> However, they then qualify this by saying that BR is borderline
> between style and content:[/color]

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.
[color=blue]
> "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,[/color]

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.
[color=blue]
> 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">.. .?[/color]

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/

**Michael Rozdoba** · Jul 20 '05, 09:22 PM

Re: EOL without using <br />

Brian wrote:
[color=blue]
> Haines Brown wrote:
>[color=green]
>>
>> 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?[/color]
>
>
> I don't know what "W3C reference" you saw, so I do not know if that
> source is wrong, but Alan Flavell is right.[/color]

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[color=blue]
> This Page Is Valid HTML 4.01 Transitional![/color]

If I change the meta tag to
<meta http-equiv="Content-Type" content="text/html">

I get[color=blue]
> 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.[/color]

This implies at the very least it is certainly acceptable to specify the
charset in <head>.
[color=blue]
> 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.[/color]

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

**Haines Brown** · Jul 20 '05, 09:22 PM

Re: EOL without using <br />

Tim <Tim@mail.local host> writes:
[color=blue]
> 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.[/color]

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

**Alan J. Flavell** · Jul 20 '05, 09:22 PM

Re: EOL without using <br />

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:
[color=blue]
> Brian wrote:
>[color=green]
> > Haines Brown wrote:
> >[color=darkred]
> >> The W3C reference[/color][/color][/color]

WHAT "W3C reference"?
[color=blue][color=green][color=darkred]
> >> indicates that I _must_ include a meta line[/color][/color][/color]

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.
[color=blue][color=green][color=darkred]
> >> the browser how to encode char references,[/color][/color][/color]

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.
[color=blue][color=green][color=darkred]
> >> <meta http-equiv="content-type" content=""telt/html; charset=UTF-8"
> >> />
> >>
> >> But then Alan says this is irrelevant?[/color][/color][/color]

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

404 Not Found

http://ppewww.ph.gla.ac.uk/~flavell/charset/checklist.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)
[color=blue]
> I've just tried validating a page of mine (using HTML-Kit to pass the
> page contents to the W3C HTML validation service).[/color]

[...][color=blue]
> <meta http-equiv="Content-Type" content="text/html">
>
> I get[color=green]
> > I was not able to extract a character encoding labeling from any of the
> > valid sources for such information.[/color][/color]

So your server is failing to send the appropriate charset attribute on
its HTTP content-type header.
[color=blue][color=green]
> > 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.[/color][/color]

It's telling the truth, but it's tangential to the issue of
interpreting &#number; notations ("numerical character references").
[color=blue]
> This implies at the very least it is certainly acceptable to specify the
> charset in <head>.[/color]

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.
[color=blue][color=green]
> > The correct way to
> > announce the charset is in http headers (not the <head> of an html
> > document).[/color][/color]

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.
[color=blue]
> 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.[/color]

"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

**Michael Rozdoba** · Jul 20 '05, 09:22 PM

Charset & manners (Was: EOL without using <br />)

Alan J. Flavell wrote:
[color=blue]
> 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.[/color]

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.
[color=blue]
> But I'll give it a try, and hope you'll put in some effort on your
> background reading... comments continue below...[/color]

Perhaps other posters might care to put in some effort on developing
interpersonal skills :)
[color=blue]
> Note x-posting and suggested f'ups.[/color]

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.
[color=blue]
> On Sun, 18 Jan 2004, Michael Rozdoba wrote:
>
>[color=green]
>> Brian wrote:
>>
>>[color=darkred]
>>> Haines Brown wrote:[/color][/color][/color]

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]
[color=blue][color=green]
>> I've just tried validating a page of mine (using HTML-Kit to pass
>> the page contents to the W3C HTML validation service).[/color]
>
>
> [...]
>[color=green]
>> <meta http-equiv="Content-Type" content="text/html">
>>
>> I get
>>[color=darkred]
>>> I was not able to extract a character encoding labeling from any
>>> of the[/color]
>>[color=darkred]
>>> valid sources for such information.[/color][/color]
>
>
> So your server is failing to send the appropriate charset attribute
> on its HTTP content-type header.[/color]

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.
[color=blue][color=green][color=darkred]
>>> 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.[/color][/color]
>
>
> It's telling the truth,[/color]

I expected that.
[color=blue]
> but it's tangential to the issue of interpreting &#number; notations
> ("numerical character references").[/color]

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.
[color=blue][color=green]
>> This implies at the very least it is certainly acceptable to
>> specify the charset in <head>.[/color]
>
>
> No-one said it wasn't "acceptable ". What they might well say is that
> there are ways of doing it better.[/color]

This information I seek.
[color=blue]
> However, this still isn't germane to the interpretation of &#number;
> references.[/color]

Already commented on.
[color=blue][color=green][color=darkred]
>>> The correct way to announce the charset is in http headers (not
>>> the <head> of an html document).[/color][/color]
>
> 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.[/color]

I'll have another look myself, shortly.
[color=blue][color=green]
>> 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.[/color]
>
> "That's what they all say".[/color]

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 misunderstandin g.
[color=blue]
> 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),[/color]

Not too surprising, given the less than helpful & competent nature of
some ISPs.
[color=blue]
> 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).[/color]

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.
[color=blue]
> PHP, ASP etc. all have ways of doing this too. CGI - of course.[/color]

As to be expected of anything generating html server side, I would
imagine. Good.
[color=blue]
> 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).[/color]

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.
[color=blue]
> But please, _read in context_ and quote with citations,[/color]

I always do, however it is difficult to know from your post whether you
intend that comment to be aimed at myself or not.
[color=blue]
> if you're wanting to learn anything productive from all of this.[/color]

I wish to learn from all my experiences. Anything else is wasteful.
[color=blue]
> Don't just pluck "W3C says you must" and "Alan says irrelevant" out
> of the air and quote it out of context![/color]

Ah, probably not aimed at myself then.
[color=blue]
> ttfn[/color]

Cheers :)

--
Michael
m r o z a t u k g a t e w a y d o t n e t

**Brian** · Jul 20 '05, 09:23 PM

Re: EOL without using <br />

Michael Rozdoba wrote:[color=blue]
> Brian wrote:
>[color=green]
>> Haines Brown wrote:
>>[color=darkred]
>>> <meta http-equiv="content-type" content=""telt/html;
>>> charset=UTF-8" />
>>>
>>> But then Alan says this is irrelevant?[/color]
>>
>> Alan Flavell is right.[/color]
>
> 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[color=green]
>> This Page Is Valid HTML 4.01 Transitional![/color][/color]

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:[color=blue][color=green]
>> Even though the web page has <meta http-equiv="content-type"
>> content="text/html; charset=UTF-8" />?[/color][/color]
Alan Flavell:[color=blue]
> 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.[/color]
</quote>
[color=blue]
> This implies at the very least it is certainly acceptable to
> specify the charset in <head>.[/color]

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.
[color=blue][color=green]
>> The correct way to announce the charset is in http headers (not
>> the <head> of an html document).[/color][/color]

This is the key.
[color=blue][color=green]
>> I'm assuming you already know how to do this[/color]
>
> I don't. Could someone briefly explain this to me?[/color]

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

404 Not Found

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

[color=blue]
> 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.[/color]

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

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

**Brian** · Jul 20 '05, 09:23 PM

Re: Charset & manners (Was: EOL without using <br />)

Michael Rozdoba wrote:[color=blue]
>
> 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.[/color]

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 ."
[color=blue]
> Alan Flavell wrote:[color=green]
>> Note x-posting and suggested f'ups.[/color][/color]

Michael Rozdoba wrote:[color=blue]
> No.
>
> I don't read that group.[/color]

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

**Tim** · Jul 20 '05, 09:23 PM

Re: EOL without using <br />

Tim <Tim@mail.local host> writes:
[color=blue][color=green]
>> 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.[/color][/color]

Haines Brown <brownh@teufel. hartford-hwp.com> wrote:
[color=blue]
> 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>[/color]

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

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.

**Haines Brown** · Jul 20 '05, 09:23 PM

Re: EOL without using <br />

Tim <Tim@mail.local host> writes:
[color=blue]
> Tim <Tim@mail.local host> writes:
>
> Haines Brown <brownh@teufel. hartford-hwp.com> wrote:
>[color=green]
> > 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>[/color]
>
> Well that is a menu (looking) type of "list." It should work on all
> browser, and look nicer on modern browsers.[/color]

I'd have been happier had you left out the quotes. I believe the above
markup is in fact a list.
[color=blue][color=green]
> > b) take advantage of <pre>:
> >
> > line 1<pre> </pre>line 2[/color]
>
> 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).[/color]

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
brownh@hartford-hwp.com
kb1grm@arrl.net

https://www.hartford-hwp.com

**Michael Rozdoba** · Jul 20 '05, 09:23 PM

Re: Charset & manners (Was: EOL without using <br />)

Brian wrote:[color=blue]
> Michael Rozdoba wrote:
>[color=green]
>>
>> 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.[/color]
>
>
> It is also likely to be misleading to the op.[/color]

My mental picture?
[color=blue]
> So when you make claims that it is "valid" to use meta http-equiv to
> declare a charset,[/color]

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.
[color=blue]
> you're only clouding up the issue.[/color]

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.
[color=blue]
> It isn't invalid to declare a charset in that manner. But it is
> preferable to use real http headers instead of the "equivalent ."[/color]

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.
[color=blue][color=green]
>> Alan Flavell wrote:
>>[color=darkred]
>>> Note x-posting and suggested f'ups.[/color][/color]
>
>
> Michael Rozdoba wrote:
>[color=green]
>> No.
>>
>> I don't read that group.[/color]
>
> That's nice.[/color]

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.
[color=blue]
> But charset and http-equiv have little to do with stylesheets.[/color]

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$5V 2.96340@attbi_s 53>.

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$5V 2.96340@attbi_s 53>, 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

**Lauri Raittila** · Jul 20 '05, 09:23 PM

Re: Charset & manners (Was: EOL without using <br />)

In article Michael Rozdoba wrote:[color=blue]
> Brian wrote:[color=green]
> > Michael Rozdoba wrote:
> >[color=darkred]
> >>
> >> 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.[/color]
> >
> >
> > It is also likely to be misleading to the op.[/color]
>
> My mental picture?
>[color=green]
> > So when you make claims that it is "valid" to use meta http-equiv to
> > declare a charset,[/color]
>
> 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.
>[color=green]
> > you're only clouding up the issue.[/color]
>
> 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.
>[color=green]
> > It isn't invalid to declare a charset in that manner. But it is
> > preferable to use real http headers instead of the "equivalent ."[/color]
>
> 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.
>[color=green][color=darkred]
> >> Alan Flavell wrote:
> >>
> >>> Note x-posting and suggested f'ups.[/color]
> >
> >
> > Michael Rozdoba wrote:
> >[color=darkred]
> >> No.
> >>
> >> I don't read that group.[/color]
> >
> > That's nice.[/color]
>
> 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.[/color]

*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.

**Michael Rozdoba** · Jul 20 '05, 09:23 PM

Re: EOL without using <br />

Brian wrote:
[color=blue]
> Michael Rozdoba wrote:
>[color=green]
>> Brian wrote:
>>[color=darkred]
>>> 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.[/color]
>>
>>
>> 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
>>[color=darkred]
>>> This Page Is Valid HTML 4.01 Transitional![/color][/color]
>
>
> How is this relevant? Alan Flavell didn't claim it was invalid. He
> said it was irrelevant. But please read his comment in context.[/color]

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?
[color=blue]
>
> <quote> H Brown:
>[color=green][color=darkred]
>>> Even though the web page has <meta http-equiv="content-type"
>>> content="text/html; charset=UTF-8" />?[/color][/color]
>
> Alan Flavell:
>[color=green]
>> 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.[/color]
>
> </quote>
>[color=green]
>> This implies at the very least it is certainly acceptable to
>> specify the charset in <head>.[/color]
>
>
> It does not imply that meta http-equiv is the best place to do it.[/color]

No one claimed it did.
[color=blue]
> If you use that method, then the ua must begin parsing the document
> before it finds out what charset that document is in.[/color]

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.
[color=blue][color=green][color=darkred]
>>> The correct way to announce the charset is in http headers (not
>>> the <head> of an html document).[/color][/color]
>
>
> This is the key.[/color]

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.
[color=blue][color=green][color=darkred]
>>> I'm assuming you already know how to do this[/color]
>>
>>
>> I don't. Could someone briefly explain this to me?[/color]
>
>
> That's what Google is for.[/color]

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.
[color=blue]
> 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[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
>
> Answered in the article "Netscape burp" (link above).[/color]

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

EOL without using <br />

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment