Re: xhtml compatibility guideline

Hi Petr,

Petr Stehlik <pstehlik@xxxxxxxxxx> writes:
> > The suggestion to output <br /> is a suggestion because a few common browers
> > that don't understand xhtml are able to render this invalid html in some
> > reasonable manner.  This is only going to work with bug-compatible browsers.
> 
> "bug-compatible"? 

<br /> is not valid html, so it's making the assumption about how browsers
behave when you feed them garbage.

> And BTW, it wasn't about <br> only - it was a general
> suggestion for all single tags (input, select etc).

understood
 
> I knew that. I just thought it would be cool to follow the compatibility
> suggestions - especially in case when someone tries to produce XHTML
> readable by current browsers (see my previous reply to Jacob that
> suggested to add a new XMLC command line switch).

Sorry, misunderstood what you were saying.  This could be done as an output
option, not necessary to make it compile-time.

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

The idea here would be to send HTML browsers that don't understand XHTML,
and XHTML to those that do.  Are the XHTML-compatible browsers sending
Accept headers with that information?
 
> I think that if XMLC had an option "produce XHTML compatible with 6.0
> browsers" (or something alike) it could:
> 
> 1) emit an extra space before the "/>" of single tags (br, input, select
> etc.)
> 
> 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).

Both this mime type and the encoding are intended to be defaults that refelect
the original document (although it sounds like "text/xml" isn't the right for
XHTML). Both different encodings and HTML vs XHTML can be change at output
time.

> What do you think?

I think it would help keep things sane for all users if only valid output
was generated for their browser.  Since these are dynamic documents, 
it should be possible to do this in a straight-forward manner.

MArk