W3C home > Mailing lists > Public > public-evangelist@w3.org > October 2003

Re: WASP asks the W3 XHTML 1.0 or HTML 4.01

From: Karl Dubost <karl@w3.org>
Date: Fri, 31 Oct 2003 08:15:11 -0500
To: <public-evangelist@w3.org>
Message-Id: <41DD647C-0BA4-11D8-B46E-0003934BEBF0@w3.org>

Le jeudi, 30 oct 2003, à 12:55 America/Montreal, Jim Ley a écrit :
> http://www.webstandards.org/learn/askw3c/oct2003.html

First of all, I want people read clearly something:

	"""C. HTML Compatibility Guidelines
	This appendix is informative."""

The whole C Appendix is not normative at all.

> [in XHTML 1.0]
> "empty elements are terminated using a space and a trailing slash"
> no they're not in XHTML, they're closed by a trailing slash - the 
> whitespace is not relevant.

	Agreed. I don't often put a space in my own pages. I even tend to 
avoid it. Web authoring tool like BBEdit does it very well. You have an 
option to warn you or not about this behaviour. so you have the choice 
of doing it or not.

> Next is not strictly an error, but in the context of authoring XHTML 
> 1.0
> today, where Appendix C compliance is essential, the example has:
> <p xml:lang="fr"> ... </p>

As you said it's not an error and "The value of the xml:lang attribute 
takes precedence." It's again the choice of the user.

There's no such thing as "Appendix C compliance". It's a strong and 
wrong abuse of words for the meaning of the spec.

> This is not allowed under Appendix C. which requires that xml:lang and 
> lang be duplicated.

	Appendix C doesn't require. The section is informative.

> Also, you state that only syntax not semantics have changed, I do not 
> agree with this statement, in HTML and XHTML
> <script type="appliction/x-jims-script">
> <!--
> // -->
> </script>
> Has different semantics - in HTML the <!-- is part of a script, in 
> XHTML it is a comment.  The semantics may not matter to most people, 
> but the
> application/x-jims-script actually considers <!-- to mean write the 
> current date. and // --> to write the current time.  Utterly contrived 
> example of course, but an example of how the semantics of elements 
> have changed IMO (what's a comment in XHTML is a script in HTML)

? I don't understand this comment

> "In HTML, [...] termination of many elements [...] are allowed and
> commonplace."
> Could you provide an example of an element in HTML which is allowed to 
> not be terminated. (as opposed to a tag of course which can, AIUI it 
> is not possible to have a valid HTML document with elements not 
> closed.)

argueing on expression, between elements and tags, I guess here?


Each element type declaration generally describes three parts: a start 
tag, content, and an end tag.

The element's name appears in the start tag (written <element-name>) 
and the end tag (written </element-name>); note the slash before the 
element name in the end tag. For example, the start and end tags of the 
UL element type delimit the items in a list:

<LI><P>...list item 1...
<LI><P>...list item 2...

Some HTML element types allow authors to omit end tags (e.g., the P and 
LI element types). A few element types also allow the start tags to be 
omitted; for example, HEAD and BODY. The HTML DTD indicates for each 
element type whether the start tag and end tag are required.

Some HTML element types have no content. For example, the line break 
element BR has no content; its only role is to terminate a line of 
text. Such empty elements never have end tags. The document type 
definition and the text of the specification indicate whether an 
element type is empty (has no content) or, if it can have content, what 
is considered legal content.

> Enough of the errors, although they need fixing before the rest of the

not so many errors finally.

> document can be taken seriously, now the actual content of the 
> document:

> "Switching from HTML 4.01 to XHTML 1.0 brings almost no direct 
> benefits for the visitors of your Web site"
> Almost no? - could you expand on the benefits it does bring, as this 
> was
> what I was hoping to get from the question, and alluding to, but not 
> listing the benefits has left me just wanting more.`

	The benefits are the ones listed all along the article for people who 
need it. The points of the article is certainly to not make the switch 
a requirement, but just a choice.

	We don't explain and WE WILL NOT explain that you must switch to XHTML 
1.0, it's a choice for most of the users. Nobody is bad because they 
still use HTML 4.01. Both solutions are perfectly usable.

> "XHTML is easier to maintain"
> This glosses over the fact that there are no QA tools to ensure XHTML
> Appendix C compliance, without these, I can't see how the claim can be

Bis Repetita: There's no such things as "Appendix C compliance".

> justified - especially as one of the statements isn't even detectable 
> by the W3's own XHTML validator, or any other validator/QA tool I know 
> of.

Some of the things are detected by BBEdit for example, I don't know 
about other tools. Would it be nice if you were developping a module in 
Perl to add to the LogValidator which look at the Appendix C items.

A detailed warning analysis of the Markup validator, it would be nice 
to do. As you know, Jim, Markup validator is made by volunteers like 
Terje, Nick, Bjoern, and I'm pretty sur such a detail analysis for a 
future warning mode would be very helpful. Giving your knowledge and 
your strictness on the HTML specifications, it would be a valuable work 
for the Web community.

> "The margin for errors in HTML is much broader than in XHTML, where the
> rules are very clear"
> What are unclear about the rules of HTML4 ?

In the context of education and using HTML 4, the rules are less 
systematic. Sometimes you can avoid the end tag for an element, 
sometimes not and except if you read the DTD... you can't decide which 
ones. I have taught HTML and XHTML, and I can tell certainly that XHTML 
is easier to teach without ambiguities.
XHTML rules are systematics.

> The W3's validator, and other SGML based validation appear to have no 
> problem in validating to the HTML rules - Is the document intending to 
> suggest that the HTML 4 specification is flawed?   I have large 
> problems with the XHTML specification for example Appendix C.1 
> suggests avoiding PI's and Appendix C.14 suggests using PI's - this 
> contradiction in the specification is not what I'd call clear.

Yes it's a problem of the specification now. Appendix C is not 

> I really do appreciate the work of the QA team and the WASP, and I'm 
> sorry that my responses to their articles are generally negative, but 
> I do believe their decision to defend a bad technology decision (XHTML 
> as text/html) should not be supported, and it should have to actually 
> talk the truth and not gloss over the flaws.

It's fine Jim, often, when people review documents have a tendency to 
pick up errors or being extremely critics with them, but that's the 
goal of the review, there's nothing wrong with that. It doesn't mean 
the document is bad.

We don't defend a bad technology. we explained different choices. As a 
personal point of view, I prefer to use XHTML because it's a lot more 
convenient for me in my daily business.

Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***
Received on Friday, 31 October 2003 08:15:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:18 UTC