- From: Karl Dubost <karl@w3.org>
- Date: Fri, 31 Oct 2003 08:15:11 -0500
- To: <public-evangelist@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? http://www.w3.org/TR/html4/intro/sgmltut.html """ 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: <UL> <LI><P>...list item 1... <LI><P>...list item 2... </UL> 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 normative. > 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