Paragraph and DIV usage in XHTML

[tzuchia16]

Hello,

I'd like anyone's thoughts on which of the following would be the
correct manner of coding for XHTML.

<p></p>
<p>&nbsp;</p>
<p />
<p class="spacer"></p>
<p class="spacer">&nbsp;</p>
<p class="spacer" />

....and I've the same question for DIV...

<div></div>
<div>&nbsp;</div>
<div />
<div class="spacer"></div>
<div class="spacer">&nbsp;</div>
<div class="spacer" />

I've seen it done with the variations above. Just curious as to which
is the proper method. Oh, and my goal with divs would be just to space
between items (I've noticed that it's a bit smaller than the Paragraph
tag).

Thanks in advance.

Tee

 

[Steve Pugh]

I'd like anyone's thoughts on which of the following would be the
correct manner of coding for XHTML.

<p></p>
<p>&nbsp;</p>
<p />
<p class="spacer"></p>
<p class="spacer">&nbsp;</p>
<p class="spacer" />

...and I've the same question for DIV...

<div></div>
<div>&nbsp;</div>
<div />
<div class="spacer"></div>
<div class="spacer">&nbsp;</div>
<div class="spacer" />

None of the above.
<p /> and <div /> are wrong if you'res erving your XHTML as text/html
The rest aren't technically wrong but make no semantic sense and should
be avoided - what does an empty paragraph mean?

I've seen it done with the variations above. Just curious as to which
is the proper method. Oh, and my goal with divs would be just to space
between items (I've noticed that it's a bit smaller than the Paragraph
tag).

Set margins via CSS instead.

Steve

 

[Andy Dingley]

I'd like anyone's thoughts on which of the following would be the
correct manner of coding for XHTML.

<div class="spacer">&nbsp;</div>

All the others are varying degrees of wrong.


It's not a paragraph if it's only there as a "spacer", so it's just an
anonymous block element or <div> rather than <p>.

Only <p></p> / <div></div> style meets the Appendix C recommendation on
back-compatibility for SGML / HTML parsing of non-empty elements.
Anything else is very wrong.

If it's a "spacer" rather than having some content, then it should have
a class on it and not be merely anonymous.

If it's empty, then put a space in there at least or you can get
problems with it sometimes being discarded or re-serialized as "<div
/>"


PS - I'm also suspicious that you should be doing this at all. If the
"spacer" is to have an image in it or even some background colour /
borders, then it's reasonable. If it's truly just an invisible spacer,
then you should probably be using CSS instead. In particular your
comment "it's smaller than paragraph tag" makes me suspect that you
should be doing all of this with CSS and not adding any markup to your
HTML at all.


PPS - Don't use XHTML, use HTML 4.01 Strict instead.

 

[tzuchia16]

Thanks guys for replying. Your comments were very helpful.

And my question was related to a company website, and we're using
XHTML. I'll look into using Strict though.

Thanks again.

-Tee

 

[Harlan Messinger]

Thanks guys for replying. Your comments were very helpful.

And my question was related to a company website, and we're using
XHTML. I'll look into using Strict though.

Note: it's not a question of using Strict *versus* XHTML. Both HTML 4.01
and XHTML come in both Strict and Transitional versions. Andy's main
point was that you ought to use HTML 4.01 instead of XHTML. The Strict
part just follows the general principle that Transitional exists to
support existing sites, and that Strict should be used for new work.

 

[cwdjrxyz]

Note: it's not a question of using Strict *versus* XHTML. Both HTML 4.01
and XHTML come in both Strict and Transitional versions. Andy's main
point was that you ought to use HTML 4.01 instead of XHTML. The Strict
part just follows the general principle that Transitional exists to
support existing sites, and that Strict should be used for new work.

Only the old xhtml 1.0 comes in strict, transitional, and frameset
versions. The more recent xhtml 1.1 (not so new now and a higher
version is in the works) comes in only one version, which is about as
strict as a mother superior in a 1800s convent. There is no point in
writing in xhtml and then serving it as text/html as often is done. If
you serve as text/html, then html 4.01 strict is better. If you serve
any version of xhtml with the correct mime type of
application/xhtml+xml or application/xml, then it will not be viewable
on IE6, which can not display a true xhtml page served correctly. If
you can view a "xhtml" page on IE6, then you can be certain that it is
not served as true xhtml despite a correct xhtml doctype. To get around
this problem, you would need to serve an xhtml page with mime type
application/xhtml+xml associated with an extension .xhtml or mime type
application/xml associated with an extension .xml, for example. Most
servers are set to serve a page with an extension .html or .htm as
text/html. There is a good bit of info that is exchanged between the
server and browser before a page is downloaded in the header exchange.
If this information determines that the page is being served as
text/html, then that is how the page gets served, despite an xhtml
doctype. Of course one could redefine the extension .html to be
associated with one of the xhtml/xml mime types, but then you could not
serve ordinary html with the extension .html. If the correct mime types
for the extensions .xhtml and .xml are not set on the server, this
usually is easy to do from the control panel - unless you use a host
that will not allow this. The bottom line is that you need to serve a
true xhtml page for browsers that can handle it and an html page for
those such as IE that can not. This can be done, but it can involve
very careful design in the header exchange, code conversion from xhtml
to html, or perhaps using IE conditional comments to route IE to a
seperate html page, etc.

 

[Andy Dingley]

Only the old xhtml 1.0 comes in strict, transitional, and frameset
versions. The more recent xhtml 1.1 (not so new now and a higher
version is in the works) comes in only one version,

So why is "Newer" equivalent to "Better" ?
Justify your arguments. Show your working.

There is no point in
writing in xhtml and then serving it as text/html as often is done.

Except that if you accept that, then you implicitly accept there's no
point in writing XHTML at all. There is certainly no point (given the
current state of the web) in serving XHTML under an XML content-type.
Implicitly this then requires Appendix C and removes 1.1 from
viability.

If you _must_ (for whatever reason) push XHTML onto the web, then
you're currently forced to XHTML 1.0 rather than 1.1

 

[cwdjrxyz]

So why is "Newer" equivalent to "Better" ?
Justify your arguments. Show your working.

I did not say newer is better. I am just pointing out that xhtml 1.0 is
now fairly old, there is a newer version 1.1, and yet another version
is in the works. I think I will leave it to the W3C to explain why they
developed 1.1 and have another version in the works. That is their
baby, not mine.

Except that if you accept that, then you implicitly accept there's no
point in writing XHTML at all. There is certainly no point (given the
current state of the web) in serving XHTML under an XML content-type.
Implicitly this then requires Appendix C and removes 1.1 from
viability.
If you _must_ (for whatever reason) push XHTML onto the web, then
you're currently forced to XHTML 1.0 rather than 1.1

There is of course no point in writing an xhtml page for use on the web
and serving it properly with mime type application/xhtml+xml if you
want to write only a single page that can be viewed by IE6 and likely
IE7 as well as several other outdated browsers. On a network, with only
modern browsers that comply to W3C standards, of course there may be no
problem. The main problem with xhtml is caused by Microsoft who can
not or does not want to write a standards compliant browser, despite
the fact that they likely contribute more money to the W3C than most
others and serve on many of the W3C committees. Serving proper xhtml
1.1 is quite possible now if you wish, but it does require alternate
html code, which can be provided in various ways, for outmoded
browsers such as IE6. This may be more than many people want to do now.
I am not suggesting that anyone use one certain form of xhtml or html.
Use html 3.2 for all I care.But whatever you use, it helps if you use
valid code, especially if you do not have a huge zoo of browsers on
which to test the page. The fact remains that many web pages, often
from major companies, still do not come even close to validating as
anything and appear to have just grown over the years starting with
bits of html 3.2 and perhaps including some html 4.01 and perhaps even
some xhtml, as well as several versions of JavaScript code, all mixed
in the code stew.

 

[Harlan Messinger]

Only the old xhtml 1.0 comes in strict, transitional, and frameset
versions. The more recent xhtml 1.1 (not so new now and a higher
version is in the works) comes in only one version, which is about as
strict as a mother superior in a 1800s convent.

I didn't even know about XHTML 1.1. Interesting that the address

http://www.w3.org/TR/html/

leads to XHTML 1.0.

In any event, according to the W3C,

http://www.w3.org/TR/2001/REC-xhtml11-20010531/changes.html

the only differences between XHTML 1.1 and XHTML 1.0 Strict is in the
modularization architecture of the DTD and the following three changes:

1. On every element, the lang attribute has been removed in favor of
the xml:lang attribute (as defined in [XHTMLMOD]).
2. On the a and map elements, the name attribute has been removed in
favor of the id attribute (as defined in [XHTMLMOD]).
3. The "ruby" collection of elements has been added (as defined in
[RUBY]).

So I don't know what benefit would come from moving from XHTML 1.0 to
XHTML 1.1 anyway, *especially* if one is relying on Transitional features.

 

[Andy Dingley]

the only differences between XHTML 1.1 and XHTML 1.0 Strict is in the
modularization architecture of the DTD and the following three changes:

You missed the biggie. Appendix C isn't permissible for 1.1 That
means no 1.1 in a current-web compatible manner.

1. On every element, the lang attribute has been removed in favor of
the xml:lang attribute (as defined in [XHTMLMOD]).

This also loses you useful processing of lang for any HTML tool that
might have recognised it.

3. The "ruby" collection of elements has been added (as defined in
[RUBY]).

Ruby is nice, but I can live without.

So I don't know what benefit would come from moving from XHTML 1.0 to
XHTML 1.1 anyway,

Pretty much none - it's just an inevitable step on the push to a "pure
XML web"
As we're nowhere near that yet, nor even a "XML content as practical"
web, then 1.1 is nowhere near usable.

 

[Jukka K. Korpela]

Scripsit Andy Dingley:

You missed the biggie. Appendix C isn't permissible for 1.1 That
means no 1.1 in a current-web compatible manner.

I wonder if _anyone_ has actually scrutinized the differences, instead of
just swallowing what XHTML 1.1 presents as "the differences". I know that
the presentation contains essential omissions, but I don't know how many.
(Nobody has offered to pay me for such work, which _should_ have been made
by people who wrote the specs.)

3. The "ruby" collection of elements has been added (as defined
in [RUBY]).

Ruby is nice, but I can live without.

Actually, you don't have to live without. IE, which is the only browser out
there that has some (partial) Ruby support, happily interprets Ruby markup
even though you use good old HTML 4.01 kind of markup. Besides, as we know,
IE does not interpret your document at all if you declare it as
application/xhtml+xml, which is what XHTML 1.1 tells you to use.

So in order to use Ruby in any manner that results in _anything_ at present,
you _must not_ use XHTML 1.1.

 

[Harlan Messinger]

You missed the biggie. Appendix C isn't permissible for 1.1 That
means no 1.1 in a current-web compatible manner.

Could you explain that more fully? I've understood Appendix C to be a
set of recommendations for tailoring an XHTML document, in a manner that
complies with the body of the XHTML 1.0 spec exclusive of the
appendices, so that it will also "work" in an HTML context. I'm not
aware that the appendix itself defines any feature or rule that could be
changed or removed in a later version.

For example, <br />, with a space before the slash, is XHTML-compliant,
in all extant XHTML versions, and it "works" in HTML 4.01 browsers. It
will work whether the author has in mind either XHTML 1.0 or XHTML 1.1,
or has nothing in particular in mind and only types the space and slash
by accident.

 

[Andy Dingley]

Could you explain that more fully?

Appendix C is permitted for 1.0, not for 1.1

So if you want XHTML and you can't do XML (and the web can't), then you
either have to stick with 1.0, or you abuse 1.1. As there's no
tangible benefit to 1.1, then why break things even further ?

 

[Harlan Messinger]

Appendix C is permitted for 1.0, not for 1.1

Again, I don't know what you mean by Appendix C not being "permitted"
for 1.1, since Appendix C doesn't permit anything, it only gives
compatibility tips. "This appendix is informative. This appendix
summarizes design guidelines for authors who wish their XHTML documents
to render on existing HTML user agents." It makes no exceptions to XHTML
1.0 that XHTML 1.1 has now revoked; all the compatibility suggestions it
makes involve constructions that are legal in *both* versions of XHTML
(except for the one clause about the lang and xml:lang attributes).

As I pointed out in my example, <br /> is fine in both XHTML 1.0 and
XHTML 1.1, because it's fine in XML. Appendix C isn't what makes it
fine, and the absence of Appendix C doesn't make it *not* fine. All
Appendix C does is recommend that you stick the space in front of the
slash to satisfy HTML parsers, and, in another clause, that you not use
an discrete end tag instead for empty elements.

Likewise, Appendix C says, "Don't include more than one isindex element
in the document head. The isindex element is deprecated in favor of the
input element." So what does it mean for Appendix C not to be
"permitted"? You *must* use more than is index element in XHTML 1.1?

Likewise: "Avoid line breaks and multiple white space characters within
attribute values. These are handled inconsistently by user agents." This
is advice, applicable in the context of both versions of XHTML, even
though the later version doesn't mention this piece of advice. It would
be good advice even if Appendix C had excluded it, or if they hadn't
published Appendix C at all. It isn't a rule subject to being maintained
or revoked.

And so on.

 

[Andy Dingley]

Again, I don't know what you mean by Appendix C not being "permitted"
for 1.1,

Appendix C is part of 1.0 and it says it's permissible to serve this
XML format as text/html

1.1 has no such appendix. Nor is text/html permited for it by any other
note that I'm aware of.

 

[Harlan Messinger]

Appendix C is part of 1.0 and it says it's permissible to serve this
XML format as text/html

1. Where does it say this? I only see, "This appendix summarizes design
guidelines for authors who wish their XHTML documents to render on
existing HTML user agents. Note that this recommendation does not define
how HTML conforming user agents should process HTML documents. Nor does
it define the meaning of the Internet Media Type text/html. For these
definitions, see [HTML4] and [RFC2854] respectively."

2. By its own terms, "This appendix is informative". It isn't normative;
it doesn't grant or deny permission for anything. It declares no musts
nor shoulds nor mays nor may nots nor must nots.

 

[Andy Dingley]

2. By its own terms, "This appendix is informative". It isn't normative;
it doesn't grant or deny permission for anything. It declares no musts
nor shoulds nor mays nor may nots nor must nots.

Then if you impose that strict an interpretation, even 1.0 Appendix C
is invalid (as far as "invalid" matters).

My point is that whatever (or how little) leeway is available for 1.0
under Appendix C, this isn't available for 1.1 I don't think we're
disagreeing on that much.

 

[Harlan Messinger]

Then if you impose that strict an interpretation, even 1.0 Appendix C
is invalid (as far as "invalid" matters).

This interpretation is "strict" in the same sense that only strict
interpretation would lead me to assume that it's raining outside when
someone says to me "It's raining outside". You are characterizing
Appendix C as something that it isn't.

My point is that whatever (or how little) leeway is available for 1.0
under Appendix C, this isn't available for 1.1.

You can water your garden by bringing water one glass at a time from the
kitchen sink, or you can use a hose. Suppose both approaches are
permitted under the regulations of the local Water Authority. Then
suppose that the Water Authority send out a "tips for homeowners" sheet
recommending that you use a hose because it's more efficient. The tip
sheet isn't permitting you or giving you leeway to use the hose because
you already have that permission and leeway. If the Water Authority
doesn't send out such a tip sheet, you have no less permission to use
either approach, AND you would still be wiser to use a hose even though
nobody told you so.

 

[Michael Winter]

Andy Dingley wrote:
[snip]

... Appendix C isn't permissible for 1.1 ...

Could you explain that more fully?

Appendix C (XHTML 1.0) doesn't apply to XHTML 1.1, in part, because the
difference between it and HTML 4.01 includes changes to the DTD that
would require a user agent to actually recognise XHTML 1.1 and not
simply treat it as HTML.

- New elements have been added (ruby, rbc, rtc, rb, rt, rp)
- The name attribute for anchors is no longer defined (user
agents are forced to recognise id attribute values as
destination anchors).
- The usemap attribute no longer refers to a name attribute
value, but is instead an IDREF.
- The lang attribute is not defined (user agents are forced to
recognise xml:lang).

I will admit that these alterations are insignificant for the bulk of
HTML documents, but it would still be wrong to say that Appendix C
applied to any XHTML 1.x document. Moreover, these are only the
differences mentioned in the Recommendation, and as Jukka wrote, there
could be more significant ones that aren't listed.

In addition, and in the language of RFC 2119, XHTML 1.1 SHOULD be served
such that it will be processed as an application of XML, with
application/xhtml+xml being the preferred media type. Appendix C
facilitates parsing as HTML, so it cannot be relevant. I don't see how
there could be a reason significant enough to override that
recommendation, especially as XHTML 1.0 is so (apparently) similar
should one feel compelled to serve XHTML and nothing's wrong with HTML
4.01 in the first place.

[snip]

Mike