"BR" tag equivalent in XHTML Strict?

[Mohammd M. Hussain]

Hi,

I am writing an XHTML 1.0 Strict Compatible web page. However, the
validator complained about the <br> tag. I wonder whether there is
another alternative for this.

Thanks,

[David Dorward]

Mohammd M. Hussain wrote:

I am writing an XHTML 1.0 Strict Compatible web page. However, the
validator complained about the <br> tag. I wonder whether there is
another alternative for this.

http://www.w3.org/TR/xhtml1/#h-4.6

However - in most cases, when people use <br> then either mean <li> or
margin-bottom: 1em; (or larger).

Why are you using XHTML anyway? http://www.hixie.ch/advocacy/xhtml

--
David Dorward <http://dorward.me.uk/>

[Jukka K. Korpela]

mm******@syr.edu (Mohammd M. Hussain) wrote:

I am writing an XHTML 1.0 Strict Compatible web page. However, the
validator complained about the <br> tag.
Then it had a reason to that. You asked it to check the syntax of your
document against a formal definition that you refer to. And it did
exactly that. If you are puzzled, that's because you don't know the
formal definition that you referred to.

There's formally nothing wrong with the <br> tag in XHTML 1.0 Strict
per se. It's the context where you use it that matters. And you gave no
hint of that, such as a URL.
I wonder whether there is
another alternative for this.

The markup you use should depend on the logical structure of your
document, which you haven't described at all.

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

[Dennis M. Straussfogel]

In article <87**************************@posting.google.com >,
mm******@syr.edu (Mohammd M. Hussain) wrote:

I am writing an XHTML 1.0 Strict Compatible web page. However, the
validator complained about the <br> tag. I wonder whether there is
another alternative for this.

I think XHTML requires a closing space-slash, as in: <br />

Dennis M. Straussfogel, Ph.D.
Aerospace Engineering Consultant

[Neal]

On Thu, 22 Jan 2004 23:30:07 +0000, David Dorward <do*****@yahoo.com>
wrote:

Mohammd M. Hussain wrote:

I am writing an XHTML 1.0 Strict Compatible web page. However, the
validator complained about the <br> tag. I wonder whether there is
another alternative for this.

http://www.w3.org/TR/xhtml1/#h-4.6

However - in most cases, when people use <br> then either mean <li> or
margin-bottom: 1em; (or larger).

Why are you using XHTML anyway? http://www.hixie.ch/advocacy/xhtml

Opera doesn't know what to do with that .htm page. Author might as well
have called it a text file, as it is decidedly NOT an HTML file. Text is
cut off once the <script> is mentioned in the text, for obvious reasons.

You'll pardon me if I'm reluctant to take advice from someone who can't
even make the page display.

[Neal]

On Fri, 23 Jan 2004 00:00:18 +0000 (UTC), Jukka K. Korpela
<jk******@cs.tut.fi> wrote:

mm******@syr.edu (Mohammd M. Hussain) wrote:

I am writing an XHTML 1.0 Strict Compatible web page. However, the
validator complained about the <br> tag.

Then it had a reason to that. You asked it to check the syntax of your
document against a formal definition that you refer to. And it did
exactly that. If you are puzzled, that's because you don't know the
formal definition that you referred to.

There's formally nothing wrong with the <br> tag in XHTML 1.0 Strict
per se. It's the context where you use it that matters. And you gave no
hint of that, such as a URL.

I wonder whether there is
another alternative for this.

The markup you use should depend on the logical structure of your
document, which you haven't described at all.

If you require a line break, you use the XML empty tag which has a slash
before the closing angled bracket. So it's <br/> and <img/> and <link/>.
Of course, it's recommended to use a blank space before that slash in case
an older browser is tripped up, so <br /> and <img /> and <link /> is
what's recommended.

Advise OP read http://www.w3.org/TR/xhtml1/

[Brian]

Neal wrote:

David Dorward <do*****@yahoo.com> wrote:

http://www.hixie.ch/advocacy/xhtml
Opera doesn't know what to do with that .htm page. Author might as
well have called it a text file, as it is decidedly NOT an HTML
file.

Author *did* call it a text file, via the headers, which advertise its
content type as text/plain.
Text is cut off once the <script> is mentioned in the text, for
obvious reasons.
It's not obvious to me. Care to explain?
You'll pardon me if I'm reluctant to take advice from someone who
can't even make the page display.

I suspect something might be wrong on the reading end.

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

[Neal]

On Fri, 23 Jan 2004 01:46:17 GMT, Brian
<us*****@julietremblay.com.invalid-remove-this-part> wrote:

Author *did* call it a text file, via the headers, which advertise its
content type as text/plain. .... I suspect something might be wrong on the reading end.

My apologies. Opera cannot parse it, yet Mozilla and even IE can. Must be
a bug in Opera.

[Mohammd M. Hussain]

Thanks for the reply,

Actually what I'm writing is a server side Perl script that generates
XHTML 1.0 Strict compatible documents. I am well aware of the rules of
XHTML 1.0 Strict and my document 99% conforms with them ( thanks to
CSS ) except for those <br /> tags.

This is a sample code:
----------------------
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>SKIN.pm Test OK</title>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" />

<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body>
<table class="navTable">
<tr>
<td class="tableHeader">SKIN.pm Test OK</td>
</tr>
<tr>
<td class="alt1">[ <a href="http://localhost/mxGuest/main.cgi">View
Comments</a> | <a href="http://localhost/mxGuest/post.cgi">Add a
New Comment</a> ]</td>
</tr>
</table>
<hr />
<br />

<table class="msgTable">
<tr>
<td class="tableHeader">SKIN.pm Test OK</td>
</tr>
<tr>
<td class="alt1">Test OK!</td>
</tr>
</table>

<br />
<hr />
<div class="copyright">Copyright (c) 2004</div>
</body>
</html>

[DU]

Mohammd M. Hussain wrote:

Thanks for the reply,

Actually what I'm writing is a server side Perl script that generates
XHTML 1.0 Strict compatible documents. I am well aware of the rules of
XHTML 1.0 Strict and my document 99% conforms with them ( thanks to
CSS ) except for those <br /> tags.

This is a sample code:
----------------------
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>SKIN.pm Test OK</title>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" />

<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body>
<table class="navTable">
<tr>
<td class="tableHeader">SKIN.pm Test OK</td>
</tr>
<tr>
<td class="alt1">[ <a href="http://localhost/mxGuest/main.cgi">View
Comments</a> | <a href="http://localhost/mxGuest/post.cgi">Add a
New Comment</a> ]</td>
</tr>
</table>
<hr />
<br />

<table class="msgTable">
<tr>
<td class="tableHeader">SKIN.pm Test OK</td>
</tr>
<tr>
<td class="alt1">Test OK!</td>
</tr>
</table>

<br />
<hr />
<div class="copyright">Copyright (c) 2004</div>
</body>
</html>

2 comments.
1- You're using tables for non-tabular data. This is not recommendable
for various reasons that I won't detail here.
2- You don't need to include a <br />; you just have to declare a
margin-bottom for your table if you want the horizontal rule to be cleared.

DU

[Jukka K. Korpela]

Neal <ne*****@spamrcn.com> wrote:

Opera cannot parse it, yet Mozilla and even IE can. Must be
a bug in Opera.

Actually, Opera does not get the _media type_ of
http://www.hixie.ch/advocacy/xhtml
right. It's clearly declared as text/plain, yet Opera treats it as
text/html - even claiming that the server send that type. But maybe I'm
missing something - maybe the server actually sends a different
Content-Type header to Opera.

It's a bug that Opera _parses_ it. It has been told to treat the data
as plain text. It should simply make it available to the user as plain
text, typically displaying it literally as written, preserving the line
structure and all.

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

[Jukka K. Korpela]

DU <dr*******@hotWIPETHISmail.com> wrote:

2- You don't need to include a <br />; you just have to declare a
margin-bottom for your table if you want the horizontal rule to be
cleared.

That's a good practical advice. Using CSS is more flexible. Besides,
there's really no guarantee that <br /> causes the empty space that the
author wants. What does it mean to break a line immediately after a
table? Can you break something that really doesn't exist? Browsers may
behave as if there were an empty line between the table element and the
br element, but why would we count on such (mis)behavior?

But the _validator_ message is caused by the fact that <br /> is an
inline element, which means that it is not allowed as a direct sub-
element, or "child", of the body element. In Strict DTD, all inline
elements inside body must be somehow wrapped into block-level elements.
Formally, this would be satisfied by making it
<div><br /></div>
but this actually emphasizes how illogical it is to try to create empty
space by using <br />.

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

[Steve Pugh]

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

Neal <ne*****@spamrcn.com> wrote:

Opera cannot parse it, yet Mozilla and even IE can. Must be
a bug in Opera.

Actually, Opera does not get the _media type_ of
http://www.hixie.ch/advocacy/xhtml
right. It's clearly declared as text/plain, yet Opera treats it as
text/html - even claiming that the server send that type. But maybe I'm
missing something - maybe the server actually sends a different
Content-Type header to Opera.

It's a bug that Opera _parses_ it. It has been told to treat the data
as plain text. It should simply make it available to the user as plain
text, typically displaying it literally as written, preserving the line
structure and all.

Odd, no problems at all here with Opera 7.23.

Which versions are giving problems and what are the user preferences
with regards to trusting server mime-types set to?

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

[Jukka K. Korpela]

Under Subject: Re: "BR" tag equivalent in XHTML Strict?
Steve Pugh <st***@pugh.net> wrote:

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

Neal <ne*****@spamrcn.com> wrote:

Opera cannot parse it, yet Mozilla and even IE can. Must be a
bug in Opera.
Actually, Opera does not get the _media type_ of
http://www.hixie.ch/advocacy/xhtml right. It's clearly declared as
text/plain, yet Opera treats it as text/html - even claiming that
the server send that type. But maybe I'm missing something - maybe
the server actually sends a different Content-Type header to Opera.

It's a bug that Opera _parses_ it. It has been told to treat the
data as plain text. It should simply make it available to the user
as plain text, typically displaying it literally as written,
preserving the line structure and all.

Odd, no problems at all here with Opera 7.23.

I'm using 7.23 too.
Which versions are giving problems and what are the user
preferences with regards to trusting server mime-types set to?

Oh my. I don't think I have changed those settings, and they indeed
seem to say that Opera makes its own guesses if it thinks that the Mime
type is not "trustworthy". I don't know what the English version says,
but I suppose the Finnish version is a technically correct translation.
And the sidebar really claims that the MIME type from server is
text/html. If I change the setting (in file type association window),
then it correctly reports the type as text/plain and displays the data
"as is".

Thus the default is protocol-incorrect behavior, unless I'm missing
something. Moreover, the browser incorrectly claims that its guess is
what the server actually sent. And the dialogue for changing the
behavior is very misleading. There's no reason whatsoever to regard the
Mime type as not trustworthy just because a browser "thinks" it can
deduce the type better from the URL or the actual data. Treating a
resource as text/html just because it has no "suffix" is absurd too.

I'm afraid Opera is making great progress in imitating some of the
worst intentional errors of IE.

Moving the discussion to the relevant browsers group now.

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

[Alan J. Flavell]

On Fri, 23 Jan 2004, Jukka K. Korpela wrote:

[re. Opera's response to text/plain]

Thus the default is protocol-incorrect behavior,
Unfortunately, it is. Opera seems to have decided in favour of
emulating IE's HTTP protocol violation by default, and only conforming
to this mandatory requirement of RFC2616 for those users who had
enough technical knowledge to reconfigure the preferences for
protocol-correct behaviour.
Moreover, the browser incorrectly claims that its guess is
what the server actually sent.
That's doubly-unfortunate.

I would - just about - be prepared to accept a browser dialog which
informed the user that the server-provided content type appeared to be
broken, and invited them to take their own decision on whether it
should be fixed.

But modifying the content-type by stealth in the client is forbidden
by RFC2616, and since this is potentially a security exposure, the
disregard of such a mandatory requirement is inadmissible IMHO.
And the dialogue for changing the behavior is very misleading.
There's no reason whatsoever to regard the Mime type as not
trustworthy
In theory, there isn't; but in practice it's known that many (most?)
servers will serve-out unknown content as text/plain, which is
doubtless why IE decided to establish the entirely incorrect and
impermissible assumption that conversely, text/plain means "client may
guess". But there is another RFC which defines the meaning of
text/plain - see e.g:

http://www.cis.ohio-state.edu/cgi-bi...html#sec-4.1.3

which I would say puts the matter beyond dispute.

Historical digression:

It would have been better for all concerned if the principle had been
established that servers sent out all unknown content types as
application/octet-stream, and then it would have been permissible for
clients to establish the convention that octet-stream uniquely means
"client may guess" - but for security reasons I would still have
wanted the client software to dialog with the user before taking any
action on the result of that guess.
I'm afraid Opera is making great progress in imitating some of the
worst intentional errors of IE.

Moving the discussion to the relevant browsers group now.

I see that you set f'ups to ms-windows: but is this behaviour unique
to Opera's MS-Windows implementations? I haven't tried others myself,
but I'd expect them to behave similarly, no? Maybe this should be
broadened to ...browsers.misc, depending on the answer to that
question. (Note temporary addition of x-post, f'ups).

[Martin Honnen]

Neal wrote:

On Thu, 22 Jan 2004 23:30:07 +0000, David Dorward <do*****@yahoo.com>
wrote:

Why are you using XHTML anyway? http://www.hixie.ch/advocacy/xhtml

Opera doesn't know what to do with that .htm page. Author might as well
have called it a text file, as it is decidedly NOT an HTML file. Text is
cut off once the <script> is mentioned in the text, for obvious reasons.

You'll pardon me if I'm reluctant to take advice from someone who can't
even make the page display.

The page is served as text/plain when I look at the HTTP header so I
don't know why Opera 7 thinks it is text/html.
--

Martin Honnen
http://JavaScript.FAQTs.com/

[Neal]

On Fri, 23 Jan 2004 09:26:12 +0000, Steve Pugh <st***@pugh.net> wrote:

Odd, no problems at all here with Opera 7.23.
Problems in this 7.23...


Which versions are giving problems and what are the user preferences
with regards to trusting server mime-types set to?

Default setting - determine by extension if MIME type is "unreliable".
Changing that setting fixes the problem.

[Neal]

On Fri, 23 Jan 2004 09:26:12 +0000, Steve Pugh <st***@pugh.net> wrote:

It's a bug that Opera _parses_ it. It has been told to treat the data
as plain text. It should simply make it available to the user as plain
text, typically displaying it literally as written, preserving the line
structure and all.

One more question: if author wants it interpreted as text, why use an .htm
extension on the file? Is there a benefit?

[Steve Pugh]

Neal <ne*****@spamrcn.com> wrote:

On Fri, 23 Jan 2004 09:26:12 +0000, Steve Pugh <st***@pugh.net> wrote:

It's a bug that Opera _parses_ it. It has been told to treat the data
as plain text. It should simply make it available to the user as plain
text, typically displaying it literally as written, preserving the line
structure and all.

I didn't write the above, Jukka did. Please be more careful with
attributions.
One more question: if author wants it interpreted as text, why use an .htm
extension on the file? Is there a benefit?

In the case in question the author didn't, the file had no extension.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

[Neal]

On Fri, 23 Jan 2004 15:39:01 +0000, Steve Pugh <st***@pugh.net> wrote:

Neal <ne*****@spamrcn.com> wrote:

On Fri, 23 Jan 2004 09:26:12 +0000, Steve Pugh <st***@pugh.net> wrote:
One more question: if author wants it interpreted as text, why use an
.htm
extension on the file? Is there a benefit?

In the case in question the author didn't, the file had no extension.

I see. However, if he had added a .txt extension, there would have been no
confusion in a browser set to prefer extension over MIME. It would seem
that adding an extension, while not required, would yield better results
on the whole.

[Neal]

And apologies for screwing up the attribution yet again :\

[Brian]

Neal wrote:

On Fri, 23 Jan 2004 Steve Pugh <st***@pugh.net> wrote:

Neal <ne*****@spamrcn.com> wrote:

if author wants it interpreted as text, why use an
.htm extension on the file? Is there a benefit?
In the case in question the author didn't, the file had no
extension.

if he had added a .txt extension, there would have been no
confusion in a browser

There should be no confusion. The content type was correctly declared
as text/plain. That's definitive as far as I can see.
set to prefer extension over MIME.
In violation of the standards, as others have pointed out.
It would seem that adding an extension, while not required, would
yield better results on the whole.

It would preclude content type negotiation, so it seems to me that it
would produce worse results in some cases. How would it produce better
results?

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

[DU]

Jukka K. Korpela wrote:

DU <dr*******@hotWIPETHISmail.com> wrote:

2- You don't need to include a <br />; you just have to declare a
margin-bottom for your table if you want the horizontal rule to be
cleared.

That's a good practical advice.

I must follow that advice myself in a few pages of mine :)

Using CSS is more flexible. Besides, there's really no guarantee that <br /> causes the empty space that the
author wants.
I wonder how <br /> is rendered in other media.

What does it mean to break a line immediately after a table? Can you break something that really doesn't exist? Browsers may
behave as if there were an empty line between the table element and the
br element, but why would we count on such (mis)behavior?

But the _validator_ message is caused by the fact that <br /> is an
inline element, which means that it is not allowed as a direct sub-
element, or "child", of the body element. In Strict DTD, all inline
elements inside body must be somehow wrapped into block-level elements.
Yep!
Formally, this would be satisfied by making it
<div><br /></div>
but this actually emphasizes how illogical it is to try to create empty
space by using <br />.

I think the habit of adding a <br> in webpages to vertically space out
elements comes from old HTML editors themselves. Even the latest Mozilla
1.6 Composer does that.

DU

[Mohammd M. Hussain]

Thanks for your reply,

That worked great. But I will use the proposed solution by using the
margin-bottom property, it seems more elegant.

Another minor question: does the fact that XHTML 1.0 strict pages
usually make heavy use of CSS, does it limit browser-compatibility? I
know IE 6 works great for most of CSS attributes, but what about
others?

[Jukka K. Korpela]

mm******@syr.edu (Mohammd M. Hussain) wrote:

does the fact that XHTML 1.0 strict pages
usually make heavy use of CSS, does it limit browser-compatibility? I
know IE 6 works great for most of CSS attributes, but what about
others?

This is more of a CSS question, so it would be better suited for
c.i.w.a.stylesheets. The general answer is that it depends on the
properties you use, and the way you use them. Setting margin-bottom:1em
works pretty well across browsers. (It's virtually negligible that NN 4
implements it wrong, especially since this only means some more spacing
that you ask for, sometimes.) But when you start settings widths, for
example, there are often problems on IE 5.x - but the seriousness of
the problems varies a lot.

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