Copyright ©2002-2008 W3C ® ( MIT , INRIA , Keio ), All Rights Reserved. W3C liability , trademark , document use and software licensing rules apply.
Many people want to use XHTML to author their web pages, but are confused about the best ways to deliver those pages in such a way that they will be processed correctly by various user agents. This Note contains guidance about when it is appropriate to use XHTML vs HTML, suggestions as to how to format XHTML to ensure it is maximally portable, and how to deliver XHTML to various user agents - even those that do not yet support XHTML natively.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a Note made available by the World Wide Web Consortium (W3C) for your information. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.
This document has been produced by the W3C XHTML 2 Working Group as part of the HTML Activity . The goals of the XHTML 2 Working Group are discussed in the XHTML 2 Working Group charter . The document represents working group consensus on the usage of Internet media types for various XHTML Family documents. However, this document is not intended to be a normative specification. Instead, it documents a set of recommendations to maximize the interoperability of XHTML documents with regard to Internet media types. This document does not address general issues on media types and namespaces.
Comments on this document may be sent to www-html-editor@w3.org ( archive ). Public discussion on this document may take place on the mailing list www-html@w3.org ( archive ).
XHTML 1.0 [ XHTML1 ] reformulated HTML 4 [ HTML4 ] as an XML application, and Modularization of XHTML [ XHTMLM12N ] provided a means to define XHTML-based markup languages using XHTML modules, collectively called the "XHTML Family". However, due to historical reasons, a recommended way to serve such XHTML Family documents, in particular with regard to Internet media types, was somewhat unclear.
After the publication of [ XHTML1 ], an RFC for XML media types was revised and published as RFC 3023 [ RFC3023 ], and it introduced the '+xml' suffix convention for XML-based media types. The 'application/xhtml+xml' media type [ RFC3236 ] was registered following that convention. Now there are at least four possibilities on media type labeling for XHTML Family documents - 'text/html', 'application/xhtml+xml', and generic XML media types 'application/xml' and 'text/xml'.
This document summarizes the current best practice for using those various Internet media types for XHTML Family documents.
In general , 'application/xhtml+xml' should be used for XHTML Family documents, and the use of 'text/html' should be limited to HTML -compatible XHTML Family documents intended for delivery to user agents that do not explcitly state in their HTTP Accept header that they accept 'application/xhtml+xml'. The media types 'application/xml' and 'text/xml' may also be used, but whenever appropriate, 'application/xhtml+xml' or 'text/html' should be used rather than those generic XML media types.
Note that, because of the lack of explicit support for XHTML (and XML in general) in some user agents, only very careful construction of documents can ensure their portability (see Appendix A ). If you do not require the advanced features of XHTML Family markup languages (e.g., XML DOM, XML Validation, extensibility via XHTML Modularization, semantic markup via XHTML+RDFa, Assistive Technology access via the XHTML Role and XHTML Access modules, etc.), you may want to consider using HTML 4.01 [ HTML ] in order to reduce the risk that content will not be portable to HTML user agents. Even in that case authors can help ensure their portability AND ease their eventual migration to the XHTML Family by ensuring their documents are valid [ VALIDATOR ] and by following the relevant guidelines in Appendix A .
Note: While this document sometimes uses terms like "must" and "should", this document is not normative and those terms do not have the same meaning as when they are used in a normative W3C specification.
http://www.w3.org/1999/xhtml
.
xml:lang
),
but
an
XHTML
Family
document
type
may
also
include
elements
and
attributes
from
other
namespaces,
such
as
MathML
[
MathML2
].
This section summarizes which Internet media type should be used for which XHTML Family document for which purpose.
A combination of these rules, in conjunction with a careful examination of the HTTP Accept header, can be useful in determining which media type to use when a document adheres to the guidelines in Appendix A . Specifically:
application/xhtml+xml
(with
either
no
"q"
parameter
or
a
positive
"q"
value)
deliver
the
document
using
that
media
type.
text/html
(with
either
no
"q"
parameter
or
a
positive
"q"
value)
deliver
the
document
using
that
media
type.
text/html
.
When
an
XHTML
document
does
NOT
adhere
to
the
guidelines,
it
should
not
be
delivered
as
media
type
text/html
.
If
such
documents
need
to
be
delivered
to
requestors
who
do
not
explicitly
support
the
XHTML
family,
those
documents
should
be
transformed
into
valid
HTML
and
then
delivered
as
such.
Note:
It
is
possible
that
in
the
future
XHTML
Modularization
will
define
rules
for
indicating
which
specific
XHTML
Family
members
are
supported
by
a
requestor
(e.g.,
via
the
profile
parameter
of
the
media
type
in
the
Accept
header).
Such
rules,
when
used
in
conjunction
with
the
"q"
parameter
of
the
media
type
could
help
a
server
determine
which
of
several
versions
of
a
document
to
deliver
-
thereby
allowing
server-side
customization
of
content
for
specific
classes
of
user
agent.
The 'text/html' media type [ RFC2854 ] is primarily for HTML, not for XHTML. In general, this media type is NOT suitable for XHTML except when the XHTML is carefully constructed (see Appendix A. In particular, 'text/html' is NOT suitable for XHTML Family document types that add elements and attributes from foreign namespaces, such as XHTML+MathML [ XHTML+MathML ].
XHTML documents served as 'text/html' will not be processed as XML [ XML10 ], e.g., well-formedness errors may not be detected by user agents. Also be aware that HTML rules will be applied for DOM and style sheets (see guidelines 11 and 13 ).
Authors should also be careful about character encoding issues. A typical misunderstanding is that since an XHTML document is an XML document, the character encoding of an XHTML document should be treated as UTF-8 or UTF-16 in the absence of an explicit character encoding information. This is NOT the case when an XHTML document is served as 'text/html'. "6. Charset default rules" of [ RFC2854 ] notes as follows:
The use of an explicit charset parameter is strongly recommended. While [ MIME ] specifies "The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII." [ HTTP ] Section 3.7.1, defines that "media subtypes of the 'text' type are defined to have a default charset value of 'ISO-8859-1'". Section 19.3 of [ HTTP ] gives additional guidelines. Using an explicit charset parameter will help avoid confusion.
Using an explicit charset parameter also takes into account that the overwhelming majority of deployed browsers are set to use something other than 'ISO-8859-1' as the default; the actual default is either a corporate character encoding or character encodings widely deployed in a certain national or regional community. For further considerations, please also see Section 5.2 of [ HTML40 ].
"5.2.2
Specifying
the
character
encoding"
of
the
HTML
4
specification
[
HTML4
]
also
notes
that
user
agents
must
not
assume
any
default
value
for
the
"charset"
parameter
.
Therefore,
authors
should
not
assume
any
default
value
for
an
XHTML
document
served
as
'text/html',
and
as
mentioned
in
[
RFC2854
],
the
use
of
an
explicit
charset
parameter
is
STRONGLY
RECOMMENDED
.
When
it
is
difficult
to
specify
an
explicit
charset
parameter
through
a
higher-level
protocol
(e.g.,
HTTP),
authors
should
include
a
meta
http-equiv
statement
(e.g.
<meta
http-equiv="Content-Type"
content="text/html;
charset=EUC-JP" />
).
See
guideline
1
and
guideline
9
for
details.
The 'application/xhtml+xml' media type [ RFC3236 ] is the primary media type for XHTML Family document types, and in particular it is suitable for all XHTML Host Language document types. XHTML Family document types suitable for this media type include (for example) [ XHTML1 ], [ XHTMLBasic ], [ XHTML11 ], and [ XHTMLPrint ], and [ XHTML+MathML ]. An XHTML Host Language document type that adds elements and attributes from foreign namespaces may identify its profile with the 'profile' optional parameter or other means such as the "Content-features" MIME header described in RFC 2912 [ RFC2912 ]. Each namespace should be explicitly identified through namespace declaration [ XMLNS ].
In general, this media type is NOT suitable for XHTML Integration Set document types (markup languages that use XHTML Modularization, but do not adhere to the structural requirements of the XHTML Family). This document does not define which media type should be used for XHTML Integration Set document types.
'application/xhtml+xml' should be used for serving XHTML documents to XHTML user agents (agents that explicitly indicate they support this media type). Authors who wish to support both XHTML and HTML user agents may utilize content negotiation by serving carefully constructed XHTML documents both as 'text/html' and as 'application/xhtml+xml'. Alternately, authors may serve HTML versions of such documents as 'text/html' and XHTML versions as 'application/xhtml+xml'. Also note that it is not necessary for XHTML documents served as 'application/xhtml+xml' to follow the HTML4 Compatibility Guidelines .
When serving an XHTML document with this media type, authors may include the XML stylesheet processing instruction [ XMLstyle ] to associate style sheets. This is not generally necessary when documents are to be processed by XHTML-aware user agents, but generic XML document processors may handle such processing instructions.
As for character encoding issues, as mentioned in "6. Charset default rules" of [ RFC3236 ], 'application/xhtml+xml' has the same considerations as 'application/xml'. See section 3.3 for details.
The 'application/xml' media type [ RFC3023 ] is a generic media type for XML documents, and the definition of 'application/xml' does not preclude serving XHTML documents as that media type. Any XHTML Family document may be served as 'application/xml'.
However, authors should be aware that such a document may not always be processed as XHTML (e.g. hyperlinks may not be recognized), depending on user agents. Generic XML User Agents might recognize it as just an XML document which includes elements and attributes from the XHTML namespace (and others), and may not have a priori knowledge what to do with such a document beyond they can do for generic XML documents.
Authors
should
use
the
XML
stylesheet
PI
when
serving
content
using
this
media
type,
since
a
Generic
XML
User
Agent
is
unlikely
interpret
the
XHTML
link
elements
or
style
elements
correctly.
Whenever appropriate, 'application/xhtml+xml' should be used rather than 'application/xml' so that the user agent can know, via the media type, the inherent semantics of the markup language.
As
for
character
encoding
issues,
"3.2
Application/xml
Registration"
of
[
RFC3023
]
says
that
the
use
of
the
charset
parameter
is
STRONGLY
RECOMMENDED
,
and
also
specifies
a
rule
that
[i]f
an
application/xml
entity
is
received
where
the
charset
parameter
is
omitted,
no
information
is
being
provided
about
the
charset
by
the
MIME
Content-Type
header
.
This
means
that
conforming
XML
User
Agents
must
follow
the
requirements
described
in
section
4.3.3
of
[
XML10
].
Therefore, while it is STRONGLY RECOMMENDED to specify an explicit charset parameter through a higher-level protocol, authors should include the XML declaration (e.g. <?xml version="1.0" encoding="EUC-JP"?> ) when delivering XHTML content using this media type. Note that a meta http-equiv statement will not be recognized by Generic XML User Agents, and while authors may include such a statement a statement in an XHTML document served as 'application/xml' it will not effect processing of the document since the User Agent will not be aware of the special semantics of that construct.
The 'text/xml' media type [ RFC3023 ] is an another generic media type for XML documents, and the definition of 'text/xml' does not preclude serving XHTML documents as that media type, either. Any XHTML Family document may be served as 'text/xml'. The considerations for 'application/xml' also apply to 'text/xml'. Whenever appropriate, 'application/xhtml+xml' should be used rather than 'text/xml'.
Authors
should
also
be
aware
of
the
difference
between
'application/xml'
(and
for
that
matter
'application/xhtml+xml'
as
well)
and
'text/xml'
with
regard
to
the
treatment
of
character
encoding.
According
to
"3.1
Text/xml
Registration"
of
[
RFC3023
],
if
a
text/xml
entity
is
received
with
the
charset
parameter
omitted,
MIME
processors
and
XML
processors
must
use
the
default
charset
value
of
"us-ascii"[
ASCII
]
.
This
default
value
is
authoritative
over
the
encoding
information
specified
in
the
XML
declaration,
or
the
XML
default
encodings
of
UTF-8
and
UTF-16
when
no
encoding
declaration
is
supplied,
so
omitting
the
charset
parameter
of
a
'text/xml'
entity
might
cause
an
unexpected
result.
As
mentioned
in
[
RFC3023
],
the
use
of
the
charset
parameter
is
STRONGLY
RECOMMENDED
.
The following table summarizes recommendation to content authors for labeling XHTML documents. HTML 4 is also listed for comparison.
Media type | HTML 4 | XHTML Family (HTML 4 compatible) | XHTML Family (other) | XHTML Family + Extensions |
---|---|---|---|---|
text/html | should | may | should not * | should not |
application/xhtml+xml | must not | may | should | should |
application/xml | must not | may | may | may |
text/xml | must not | may | may | may |
* However, see transformation .
This appendix summarizes design guidelines for authors who wish their XHTML documents to render on both XHTML-aware and modern HTML user agents. The purpose of providing these guidelines is to supply a simple collection that, if followed, will give reasonable, predictable results in modern user agents. Document authors should treat these as best practices that were considered correct at the time this document was published. Like all of this document, this Appendix is informative . It contains no absolute requirements, and should NEVER be used as the basis for creating conformance nor validation rules of any sort. Period.
For an example document that reflect the use of the guidelines from this section, see Appendix B .
DO NOT include XML processing instructions NOR the XML declaration.
Rationale : Some HTML user agents render XML processing instructions. Also, some user agents interpret the XML declaration to mean that the document is unrecognized XML rather than HTML. Such user agents may not render the document as expected. For compatibility with these types of HTML browsers, you should avoid using processing instructions and XML declarations.
Consequence : Remember, however, that when the XML declaration is not included in a document, AND the character encoding is not specified by a higher level protocol such as HTTP, the document can only use the default character encodings UTF-8 or UTF-16. See, however, guideline 9 below.
If
an
element
has
an
EMPTY
content
model
DO
use
the
minimized
tag
syntax
permitted
by
XML
(e.g.,
<br />
).
DO
NOT
use
the
alternative
syntax
(e.g.,
<br></br>
)
allowed
by
XML,
since
this
may
be
unsupported
by
HTML
user
agents.
Also,
DO
include
a
space
before
the
trailing
/
and
>
.
Empty
elements
in
the
XHTML
family
include:
area
,
base
,
basefont
,
br
,
col
,
hr
,
img
,
input
,
isindex
,
link
,
meta
,
and
param
.
Rationale:
HTML
user
agents
ignore
the
/>
at
the
end
of
a
tag,
but
without
it
they
may
incorrectly
parse
the
tag
or
its
attributes.
HTML
user
agents
also
may
not
recognize
the
alternate
syntax
permitted
by
XML.
If
an
element
permits
content
(e.g.,
the
p
element)
but
an
instance
of
that
element
has
no
content
(e.g.,
an
empty
paragraph),
DO
NOT
use
the
"minimized"
tag
syntax
(e.g.,
<p
/>
).
Rationale: HTML user agents may give uncertain results when using the the minimized syntax permitted by XML when an element has no content.
DO
use
external
style
sheets
if
your
style
sheet
uses
<
or
&
or
]]>
or
--
.
DO
NOT
use
an
internal
stylesheet
if
the
style
rules
contain
any
of
the
above
characters.
DO
use
external
scripts
if
your
script
uses
<
or
&
or
]]>
or
--
.
DO
NOT
embed
a
script
in
a
document
if
it
contains
any
of
these
characters.
Rationale
:
XML
parsers
are
permitted
to
silently
remove
the
contents
of
comments.
Therefore,
the
historical
practice
of
"hiding"
scripts
and
style
sheets
within
"comments"
to
make
the
documents
backward
compatible
may
not
work
as
expected
in
XML-based
user
agents.
While
XML
provides
the
CDATA
method
to
embed
data
such
as
this,
that
method
will
not
work
correctly
should
the
document
be
delivered
as
media
type
text/html
Note that if you really need to embed scripts or stylesheets, the following patterns can be used:
Portably escaping embedded script contents:
<script>//<![CDATA[ ... //]]></script>
Portably escaping embedded style contents:
<style>/*<![CDATA[*/ ... /*]]>*/</style>
@@@@Put a real example in here that works, and one that does not work@@@@
DO ensure that attribute values are on a single line and only use single whitespace characters. DO NOT use line breaks and multiple consecutive white space characters within attribute values.
Rationale : These are handled inconsistently by user agents - user agents are permitted to collapse multiple whitespace characters to a single white space character.
lang
and
xml:lang
Attributes
DO
use
both
lang
and
xml:lang
attributes
when
specifying
the
language
of
an
element
in
markup
languages
that
support
the
use
of
both.
DO
NOT
use
the
only
the
lang
attribute,
even
in
languages
that
include
it
such
as
XHTML
1.0.
Rationale
:
HTML
4
documents
use
the
lang
attribute
to
identify
the
language
of
an
element.
XML
documents
use
the
xml:lang
attribute.
CSS
has
a
"lang"
pseudo
selector
that
automatically
uses
the
appropriate
attribute
depending
on
the
media
type.
Therefore,
specifying
both
attributes
ensures
that
single
CSS
selectors
will
work
in
both
modes.
DO
use
the
id
attribute
to
identify
elements.
DO
ensure
that
the
values
used
for
the
id
attribute
are
limited
to
the
pattern
[A-Za-z][A-Za-z0-9:_.-]*
.
DO
NOT
use
the
name
attribute
to
identify
elements,
even
in
languages
that
permit
the
use
of
name
such
as
XHTML
1.0.
Rationale
:
In
HTML
3.2
and
earlier
the
name
attribute
on
some
elements
could
be
used
to
define
an
anchor,
but
HTML
4
introduced
the
id
attribute.
In
an
XML
dialect,
only
attributes
with
type
ID
are
permitted
to
be
used
as
anchors,
and
the
id
attribute
is
defined
to
be
of
type
ID
.
Relying
upon
the
id
attribute
as
an
anchor
will
work
well
in
modern
HTML
and
XHTML-aware
user
agents.
DO encode your document in UTF-8 or UTF-16. When delivering the document from a server, DO set the character encoding for a document via the charset parameter of the HTTP Content-Type header. When not delivering the document from a server, DO set the encoding via a "meta http-equiv" statement in the document (e.g., <meta http-equiv="Content-Type" content="text/html; charset=EUC-JP" /> ). However, note that doing so will explicitly bind the document to an a single content type.
Rationale : Since these guidelines already recommend that documents NOT contain the XML declaration, setting the encoding via the HTTP header is the only reliable mechanism compatible with HTML and XML user agents. When that mechanism is not available, the only portable fallback is the "meta http-equiv" statement.
DO
use
the
full
form
for
boolean
attributes,
as
required
by
XML
(e.g.,
disabled="disabled"
).
Such
attributes
include:
compact
,
nowrap
,
ismap
,
declare
,
noshade
,
checked
,
disabled
,
readonly
,
multiple
,
selected
,
noresize
,
and
defer
.
Rationale : The compact form of these attributes is not well formed XML, and therefore invalid.
DO
rely
upon
the
HTML
4
DOM
as
defined
in
The
Document
Object
Model
level
1
Recommendation
[
DOM
]
for
scripting
when
content
is
delivered
using
media
types
text/html
and
application/xhtml+xml
.
This
means,
in
particular,
that
the
names
of
elements
and
attributes
will
be
returned
(from
functions
that
return
such
things)
in
upper
case.
Rationale : Using the HTML DOM will result in maximum portability of scripts, since the HTML DOM is supported in both HTML and XHTML documents in modern user agents.
DO
ensure
that
when
content
or
attribute
values
contain
the
reserved
character
&
it
is
used
in
its
escaped
form
&
.
Rationale : If ampersands are not encoded, the characters after them up to the next semi-colon can be interpreted as the name of a entity by the user agent.
DO
use
lower
case
element
and
attribute
names
in
style
sheets.
DO
create
rules
that
include
inferred
elements
(e.g.,
the
tbody
element
in
a
table).
Rationale : These simple rules will help increase the portability of CSS rules regardless of the media type the document is processed as.
DO NOT use XML stylesheet declarations to identify style sheets.
DO
use
the
style
or
link
elements
to
define
stylesheets.
Rationale
:
Since
XML
processing
instructions
may
be
rendered
by
some
HTML
user
agents,
using
the
standard
XML
stylesheet
declaration
mechanism
may
not
work
well.
However,
since
XHTML
user
agents
are
required
to
process
style
and
link
elements
and
interpret
stylesheets
referenced
from
those
elements,
documents
constructed
to
use
them
will
work
as
expected.
DO NOT use the formfeed character (U+000C).
Rationale : This character is recognized as white space in HTML 4, but is NOT considered white space in XML.
DO
use
'
to
specify
an
escaped
apostrophe.
DO
NOT
use
'
.
Rationale
:
The
entity
'
is
not
defined
in
HTML
4.
DO NOT use the XML DTD internal subset mechanism as part of the DOCTYPE declaration.
Rationale : The subset mechanism is not supported by non-XML user agents.
DO NOT use the XML CDATA mechanism.
Rationale : This mechanism is not supported in non-XML user agents.
DO
use
explicit
tbody
elements
within
tables.
Rationale
:
While
the
content
model
of
the
table
element
permits
the
tbody
element
to
be
skipped,
in
HTML
4
this
element
is
implicit
.
HTML
4
user
agents
will
silently
add
this
element,
thus
potentially
confusing
scripts
or
style
sheets.
base
vs.
xml:base
DO
use
the
base
element
if
you
need
to
establish
an
alternate
base
URI
for
your
document.
DO
NOT
use
the
xml:base
element.
Rationale
:
Most
XHTML
Family
markup
languages
do
not
even
support
xml:base
,
relying
instead
upon
the
(X)HTML
element
base
.
HTML
user
agents
do
not
support
xml:base
at
all.
document.write
DO
NOT
use
the
Javascript
methods
document.write
or
document.writeln
to
change
the
document.
Rationale : Native XML user agents will not support this technique for creating dynamic content.
application/xml
and
the
DOM
DO
NOT
rely
upon
the
HTMLDocument
interface
from
the
Document
Object
Model
if
you
deliver
your
content
as
media
type
application/xml
.
Rationale : XML User Agents will not know that such content is related to HTML at all, and so will not reveal the (X)HTML DOM.
innerHTML
DO
NOT
use
the
the
Javascript
innerHTML
method
(supported
by
some
user
agents)
to
update
a
document
dynamically.
If
you
choose
to
use
this
method,
ensure
that
it
is
available
in
the
user
agent
and
then
ensure
that
any
content
inserted
via
the
method
is
well-formed
AND
conforms
to
these
guidelies
so
it
is
HTML
4
compatible.
Rationale : There are many other standard Document Object Model methods for updating a document that will do so more portably than this non-standard method.
tbody
elements
DO
ensure
that
if
tbody
elements
are
omitted
from
table
elements,
scripts
that
examine
the
document
tree
are
capable
of
working
both
with
and
without
the
element
(see
Guideline
19
above).
DO
ensure
that
any
CSS
background
or
overflow
properties
are
specified
on
the
html
element.
Rationale
:
In
HTML
4,
these
properties
were
often
specified
on
the
body
element.
CSS
specifies
that
in
XHTML
they
need
to
be
specified
on
the
html
element
in
order
to
apply
to
the
entire
viewport.
noscript
Element
DO
NOT
use
the
noscript
element.
Rationale : The contents of this element are treated differently depending on whether the document is evaluated as XML or HTML, as well as whether scripting is enabled in the user agent or not.
iframe
Element
DO
NOT
embed
content
in
the
iframe
element.
Rationale
:
The
contents
of
this
element
are
treated
differently
depending
on
whether
the
document
is
evaluated
as
XML
or
HTML.
The
contents
of
the
frame
can
be
imported
from
an
external
source
via
the
src
attribute.
DO
create
new
Document
Object
Model
elements
via
the
createElementNS
method
if
it
is
available.
If
it
is
not,
fallback
to
the
createElement
method.
Rationale : The createElementNS method will work as expected in both HTML and XML contexts, but it is not supported in all user agents.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>sample</title> <link href="style/style.css" rel="stylesheet" type="text/css" /> </head> <body> <div id="main"> <h1>heading</h1> <img src="http://www.w3.org/Icons/w3c_main" alt="W3C logo" /> <!-- defined as an "EMPTY" element, do not use <img></img> or <img/> --> <p>Some material & some <!-- use escaped ampersand, & --> <br /> <!-- defined as an "EMPTY" element, do not use <br></br> or <br/> --> that should be split.</p> <p></p> <!-- NOT defined as an "EMPTY" element, just no content, so do not use <p/> nor <p /> --> <input type="reset" disabled="disabled" /> <!-- defined as an "EMPTY" element, do not use <hr></hr> nor <hr/> --> <hr /> <!-- defined as an "EMPTY" element, do not use <hr></hr> nor <hr/> --> </div> </body> </html>
" HTML 4.01 Specification ", W3C Recommendation, D. Raggett, A. Le Hors, I. Jacobs, eds. , 24 December 1999. Available at: http://www.w3.org/TR/1999/REC-html401-19991224
The latest version of HTML 4.01 is available at: http://www.w3.org/TR/html401
The latest version of HTML 4 is available at: http://www.w3.org/TR/html4
" Mathematical Markup Language (MathML) Version 2.0 ", W3C Recommendation, D. Carlisle, P. Ion, R. Miner, N. Poppelier, eds. , 21 February 2001. Available at: http://www.w3.org/TR/2001/REC-MathML2-20010221
The latest version is available at: http://www.w3.org/TR/MathML2
The W3C Markup Validation Service available at http://validator.w3.org.
" XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition): A Reformulation of HTML 4 in XML 1.0 ", W3C Recommendation, S. Pemberton et al. , August 2002. Available at: http://www.w3.org/TR/2002/REC-xhtml1-20020801
The first edition is available at: http://www.w3.org/TR/2000/REC-xhtml1-20000126
The latest version is available at: http://www.w3.org/TR/xhtml1
" XHTML™ 1.1 - Module-based XHTML ", W3C Recommendation, M. Altheim, S. McCarron, eds. , 31 May 2001. Available at: http://www.w3.org/TR/2001/REC-xhtml11-20010531
The latest version is available at: http://www.w3.org/TR/xhtml11
" XHTML™ Basic ", W3C Recemmendation, M. Baker, M. Ishikawa, S. Matsui, P. Stark, T. Wugofski, T. Yamakami, eds. , 19 December 2000. Available at: http://www.w3.org/TR/2000/REC-xhtml-basic-20001219
The latest version is available at: http://www.w3.org/TR/xhtml-basic
" Modularization of XHTML™ ", W3C Recommendation, M. Altheim, F. Boumphrey, S. Dooley, S. McCarron, S. Schnitzenbaumer, T. Wugofski, eds. , 10 April 2001. Available at: http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410
The latest version is at: http://www.w3.org/TR/xhtml-modularization
" Extensible Markup Language (XML) 1.0 Specification (Second Edition) ", T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, eds. , 6 October 2000. Available at: http://www.w3.org/TR/2000/REC-xml-20001006
The latest version is available at: http://www.w3.org/TR/REC-xml
" Namespaces in XML ", T. Bray, D. Hollander, A. Layman, eds. , 14 January 1999. Available at: http://www.w3.org/TR/1999/REC-xml-names-19990114
The latest version is available at: http://www.w3.org/TR/REC-xml-names
" Associating Style Sheets with XML documents Version 1.0 ", W3C Recommendation, J. Clark, ed. , 29 June 1999. Available at: http://www.w3.org/1999/06/REC-xml-stylesheet-19990629
The latest version is available at: http://www.w3.org/TR/xml-stylesheet
In 3.5. Summary , changed 'text/html' for HTML 4 as SHOULD rather than MAY .
Updated reference to XHTML 1.0 to refer to the Second Edition.