Re: xhtml compatibility guideline

Hi Petr,

See my reply to Mark's email first, then read comments 
below....

At 11:44 AM 12/22/2002 +0100, you wrote:
> I understand. But since the
> original static design is in XHTML and is
> tuned up to look well on most browsers I believe I should keep the
> output formatted in XHTML again, just for sure.
>
> I think that if XMLC had an option "produce XHTML compatible with
> 6.0
> browsers" (or something alike) it could:

This is not necessary.  Like said in my response to Mark's email,
standards compliant browser that natively understand XHTML like Mozilla
don't care whether the markup is <br /> or <br/> or, for that
matter,
<br          
/>.  It is all valid XML.  On the other hand, older browsers
that don't natively understand XHTML will handle <br /> better than
<br/>.  So, there is no reason at all to do anything other
than *always* output shortcut tags as <br /> rather than
<br/>.  A switch could be supplied to output <br/>, but
there isn't much of a compelling reason to provide such a thing since
<br /> is compatible with all browsers and should cause no issues
that I know of in any of them (please point out cases where I am wrong
here).


> 1) emit an extra space
> before the "/>" of single tags (br, input, select
> etc.)

Note that  select tags will never be <select />.  They
*require* and end tag in XHTML (and html, for that matter).  There
are actually very few tags which are shortcut tags in XHTML.  These
include <br />, <hr />, <area />, <base />,
<basefont />, <col />, <frame />, <img />,
<input />, <isindex />, <link />, <meta />, and
<param />.  Of those, many are either deprecated or only
validate in html loose dtd.  When using XHTML, you should avoid
those tags which aren't valid in html 4.0.1 Strict or XHTML 1.0 strict or
XHTML1.1 anyway.

> 2) change the
> pregenerated methods buildDocument() and the other one to
> contain "text/html" instead of "text/xml" so that
> _javascript_ would work
> as expected (see my reply to Jacob).

Yes, the content-type should be user-definable for compatibility with
older browsers which don't understand application/xhtml+xml.  since
XMLC, by default uses text/xml for XHTML, that absolutely needs to be
fixed because it is entirely incorrect although, in XMLC's defence,
application/xhtml+xml is a recently defined mime-type.  Either way,
if this was user-defineable, this wouldn't be an issue.


Jake