XHTML 2.0 issues

-----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