Re: xhtml compatibility guideline

Hi Jacob!

Jacob Kjome <hoju@xxxxxxxx> writes:
> >The XHTML case is fine, it's the assumption that all non-xhtml browsers
> >behave correctly that bothers me.  It's the assumptions about how invalid
> >html behaves that has cause much grief.
> 
> Yes, I suppose.  Those kinds of assumptions have lead to lots 
> browser-specific workarounds.  

It certainly caused me a lot of pain trying to parse html.  Sticking to
valid documents eliminates a lot of need for anything browser-specific.
I get very nervous around anything that isn't valid (in this case,
XMLC is still generating valid XHTML, so I am not going to protest too
loudly); but its enabling disfunctional behavior.  The parsing problems
go beyond browsers; validators, test suite drivers, etc; anything that
wants to look at the contents of a document.

> Yes, but currently this is a bit out of scope for Barracuda since we 
> haven't created components that are XHTML capable.  I believe Christian was 
> going to whip these out in short order, though.  Hopefully we'll be fully 
> XHTML compatible for the next release.   I've been discussing this more 
> without assuming Barracuda will be there; just XMLC.

Ok, just hoping to learn from Barracuda's experience; but maybe this can
make Barracuda's life easier.
 
> Browser detection is fine, but not always 100% reliable.  

What I am hoping here is that any browser that is modern enough to
handle XHTML would send the right accept headers.   So one doesn't
have to actually detect browser version, just pay attention to what
the browser is asking for. 

> Like I said 
> above, we are only feigning compatibility when we say render a BR tag as 
> <br /> rather than <br/>.  If one doesn't really want to do browser 
> detection, writing tags with the extra space is the next best thing and 
> doesn't hurt anything, so why not do it? 

In this case, I think (hope) it's not too much more work to actually do the
right thing.  This seems to be:

    - If the browser sends an accept header that allows XHTML, write the
      DOM as XML (with approriate mime type).
    - If the browser doesn't explictly allow an XHTML response, 
      write the DOM as HTML (with approriate mime type).

this could actually work independently of the original document format;
a document that started out as HTML can be written as XHTML.

Of course, all of this is just me typing e-mail, there are probably some
other underlying issue that might make it a bit harder.

Mark