- From: Christian Wolfgang Hujer <Christian.Hujer@itcqis.com>
- Date: Wed, 2 Jun 2004 12:06:45 +0200
- To: www-html-editor@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear XHTML 2.0 authors / editors, I have just read the most recent working draft of XHTML 2.0 (6 May 2003). Thank you for the great work you do for the web. To the issues: 1. DTD Bias (3.1.1.) Will the constraint 4 remain or wouldn't it be better to change it in a way that a document must at least have at a minimum a DOCTYPE declaration, a Relax NG reference or a Schema reference? Sometimes DOCTYPE declarations aren't quite handy (if they were, there wouldn't be Schema ;-), so why still constraint to DTDs... 2. Allow any element to be an image map? (6.7. Image Map Attribute Collection) I'd say yes. Validation is impossible for "no". And why not? 3. Style Attributes and Generic XML (6.9. Style Attribute Collection / 17. XHTML Style Attribute Module) The statement "There is currently no way to declare what attribute within a given namespace contains "styling" information in a way that a Generic XML processor can discern." is not 100% true. XML Formatting objects have their namespace, and any Generic XML processor with at least Namespace support will report these attributes properly. Which of course is not sufficient for XHTML which usually would be rendered using CSS, not FO. What about suggesting a CSS Namespace and a CSS style attribute, like this: xmlns:css="http://www.w3.org/2004/06/CSS" css:style="..." Make a recommendation out of it... This issues another topic: Should it be class or css:class for css classes? Oh my god am I lucky I'm in the position to think about this just for fun, not because I have to write technical reports masses of people are depending on... ;-) 4. footer PR #744 (7. XHTML Structure Module) I'm against. First someone wants a footer. Then someone else wants a header. Finally we'd have start-regions, end-regions, before-regions and after-regions, switch the prefix and the postfix and end up with XSL Formatting Objects... A <section class="footer"/> should be enough. (While it really makes sense to differ between section and div). 5. security tag (7. XHTML Structure Module) Since I cannot understand what security ramifications should be there, I'd say no. 6. content model of address element (8.1 The address element) Oh, what are you gonna do, invent a set of new elements? <address> <name><firstname>Christian</firstname> <names>Wolfgang</names> <lastname>Hujer</lastname></name> <street><streetname>Ahornstr.</streetname> <number>48</number></street> <zip>D-82377</zip> <city>Penzberg</cite> <country>Germany</country> </address> My opinion on this is: Don't reinvent the wheel. If someone wants to put his / her address in parsable format on his website, he should use the existing vcard rfcs for this. Most people will be confident with <address><l>...</l><l>...</l><l>...</l></address>. Developing an address markup would be a specification of its own. 7, Deprecate h1-6? (8.5 The heading elements) Yes, deprecate them. 8. Remove or rename hr (8.6 The hr element) I'd say rename it. Having a separator is often helpful. There are situations where section, paragraph or div changes simply won't do (even considering the possibilities given by CSS). But hr is too presentational, while separator is more logical. 9. nr element (9. XHTML Inline module) I'd say no nr element, too specific. 10. br element still needed (9. XHTML Inline module) I agree. Keep the br element. There are situations where a paragraph needs a semantic break without starting a new paragraph. 11. strong (9.11. The strong element) What's best? a) <em>...</em> and <em class="strong">...</em> b) <em>...</em> and <strong>...</strong> c) <em>...</em> and <em><em>...</em></em> pro a) less elements pro b) people are used to it pro c) nesting works fine contra a) class inflation contra b) strong is strong emphasis so basically it's em contra c) nesting em for strong emphasis only is overkill I don't care, you can remove it, I think I could live with a) and c). 12. Could param be an attribute? (14.2. The param element) I would introduce such a param attribute without removing the param element. Think about the XSLT users. If one of them wants to modify a parameter, she'd have to tokenize the attribute value first - ugly thing in XSLT, I tell ya ;-) I hope reading my feedback wasn't too dry, worth the time and helped a bit, at least by seeing how one of "your users" thinks about the issues. Thank you, bye - -- ITCQIS GmbH Christian Wolfgang Hujer E-Mail: Christian.Hujer@itcqis.com WWW: http://www.itcqis.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQFAvabEMgwgpCF2K9sRAvJ9AJ9tElAmrbTUk5Jowx55KO0pKMtpYgCfYhDG JY69+C0mRQ+o/PWEvCTFPOo= =a6Uo -----END PGP SIGNATURE-----
Received on Wednesday, 2 June 2004 08:21:44 UTC