Re: xhtml compatibility guideline

Hi Mark,

See comments below...

At 11:08 AM 12/22/2002 -0800, you wrote:

> Hi Jacob
>
> Jacob Kjome <hoju@xxxxxxxx> writes:
> > When you say "this is only going to work with bug-compatible
> browsers", are 
> > you implying that browsers which only understand standards compliant
> XHTML 
> > won't understand <br /> as opposed to the "correct"
> <br>?  There is nothing 
> > in the XML or XHTML specs that I know of which forbid the extra
> space 
> > between the tag name and the ending "/".
>
> When I said bug-compatible, I was refering to browser that are
> interperting
> the document as HTML are treating "<br />" as
> "<br>", as neither "<br />" or
> "<br/>" are valid HTML.  XML allows spaces between
> an empty tag name and the
> /, so "<br />" should be fine with any XHTML 
> parser.

Ok, then we are on the same page.

> > The whole reason
> for the recommendation of doing <br /> is so that both 
> > standards compliant XHTML-capable *and* older browsers can
> understand the 
> > same XHTML markup.  The latter case being one where the older
> browser is 
> > fooled into thinking that it is normal html instead of
> XHTML...basically 
> > taking advantage of the way the html parser works in those older
> browsers.
>
> 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.  However, in this case, we are just
making a minor attempt at browser compatibility through a simple means
rather than making any specific assumption about any specific
browser.  I think we are saying, "well, we tried to throw you a
bone of compatibility, but if you still can't render this, then
tough!".


> > So, doing <br
> /> rather than <br/> doesn't hurt anything and it helps the
> > older browsers understand the markup while the opposite renders
> properly 
> > only in new standards compliant browsers.  Since there is no
> harm in doing 
> > <br />, why not do it by default for all XHTML output? 
> No switches 
> > needed....although one could still be there if one really just wants
> <br/>.
>  
> Avoiding extra switches is a very good thing.

Yep

> Reading though the
> XHTML 1.0 spec HTML comatiblity guidelines, it seems there
> is a bit more to what they suggest than just than just formatting of the
> empty
> tag.  Given that this is dealing with dynamic docuuments instead of
> static
> files, isn't it possible to always generate valid documents?
>
> Doesn't Barracuda have some browser support detection?  What's the
> experience
> there?

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.

Browser detection is fine, but not always 100% reliable.  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 the
end, I'd rather than pages render crappy on old browsers to encourage
users to upgrade to something reasonably current.  

Jake


> Mark
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc