Slashdot Mirror


Browser Support for XHTML?

eLoco asks: "What support do today's browsers have for XHTML? Maybe a better question would be: what support do the major browsers in current use have for formatting/display of XML with DTD defined? I don't have any browser prejudice per se (I use MSIE, Mozilla, Safari/KHTML, and Opera depending on the system I am working on and my mood), but I am primarily interested in the browsers with greater 'market share,' since my main reason for asking is this: If at least the "main" browsers in current use have decent support (vague, I know) for XHTML/XML rendering, why haven't we all converted over yet?" While it doesn't cover all browsers out there, this chart serves as a good starting point. For those of you working with application/xhtml+xml files, what issues have you run into when serving up your files to various browsers?

14 of 73 comments (clear)

  1. XHTML test suite by icemax · · Score: 5, Informative

    is right here! Seeing how you have all these browsers, run them against this suite, and see how they faire. Nothing like the fresh scent of google.

    --


    __________
    Love conquers all... except CANCER
  2. no problems here... by jdclucidly · · Score: 4, Informative

    I've been using XHTML for all of my web developement for quite some time now. And in XHTML 1.0 Strict, mind you. Just stay away from using tables for layout and use CSS to accomplish your formatting and you'll be fine.

    The only quirk I ran in to was the new IE 6 "standards compliance mode" which should be rename "less-messed-up mode". While it fixes some bugs, it created new ones. To avoid developing for IE6's new quirks and to keep my documents compliant by having the !DOCTYPE declaration in there, I add the ?xml... declaration to the top of my files to kick IE back in to its 5.5ish quirky existance.

    Of course, IE still doesn't support the object tag correctly but will they ever?

    1. Re:no problems here... by JimDabell · · Score: 2, Informative

      To avoid developing for IE6's new quirks and to keep my documents compliant by having the !DOCTYPE declaration in there, I add the ?xml... declaration to the top of my files to kick IE back in to its 5.5ish quirky existance.

      There are problems with including the XML declaration/PIs in documents that you later serve as text/html, outlined in Appendix C of the XHTML 1.0 Recommendation. For instance, Pocket IE renders them as content.

  3. Need a jump start?? by Monty67 · · Score: 5, Informative

    Check out http://www.meyerweb.com/eric/css/edge/.
    Author of Cascading Style Sheets: The Definitive Guide. Or http://bluerobot.com/web/layouts/

    Both sites offer ready to go, CSS ideas that make moving to XHTML an absolute breeze. And the older browsers (including Netscape) have been covered.

    Excellent resource.

  4. Moz been left out by Wuffle · · Score: 4, Informative

    It seems that the chart linked to has no mentions of Mozilla/Netscape 7, which imo probably has the best support for the widest range of standards. Here's a page detailing the various XML stuff Mozilla supports.

  5. Re:Backward Compatability by Markusis · · Score: 5, Informative

    I am the president of a Linux Users Group and I maintain the website we have. LUGSB The site is fully XHTML1.1 and CSS2 compliant. (There are links at the bottom of the page that will validate it) For the most part support is very good. All of the layout is done with CSS. (there isn't one table on the site) A lot of it even works with NN4. But, the beauty with CSS layout and semantically correct XHTML is that it degrades really nicely. So, if someone hits my site with lynx it still renders in a very readable way with important links at the top and the data presented nicely. Try reading slashdot with lynx and having to wade through all the links that normally show up on the left side bar before you get to the articles. How annoying is that?
    We also serve the pages as application/xhtml+xml to mozilla and other gecko based browsers. If you send that to IE it won't work. I think it just prints out the XHTML instead of rendering it. But, if you send the same data as text/html it works fine. If only IE would support transparent PNG images.
    I think the best bet is drop support for Netscape 4.x. When I say drop support, I mean, make sure that the content of the site is still accessible even if NN4 users lose a little bit of the layout, it pays off with the benefits of CSS and XHTML.

    Just my 2 cents.

  6. Re:Backward Compatability by JimDabell · · Score: 3, Informative

    The only mime-type you should serve XHTML 1.1 as is application/xhtml+xml. If you serve it as text/html, you are violating the spec. The only type of XHTML you are allowed to serve as text/html is XHTML 1.0 that follows Appendix C of the XHTML 1.0 Recommendation.

    Also, when you serve it as text/html, the only thing browsers see is tag soup - they don't treat it as XHTML, just run-of-the-mill HTML that doesn't quite match HTML 4.01.

  7. Re:Thoughts on IE and Moz by Anonymous Coward · · Score: 1, Informative

    So, let me get this straight. The browser should override the way someone else is specifically sending something? What if the browser guesses wrong? If I tell a browser to display something as text/plain, I don't want it rendered as html.

  8. Re:cliff: the chart is lousy. by JimDabell · · Score: 3, Informative
  9. Re:Compliance and awareness by JimDabell · · Score: 4, Informative

    Question: What's the problem XHTML is supposed to solve? Answer: the fact that too much web content only works correctly on a particular browser. (And often at a particular resolution!) XHTML does this by re-introducing the strict content-presentation separation that is an essential feature of markup languages, but which HTML basically ignores.

    This is untrue. XHTML 1.0 (the only XHTML viable to the public web) is a direct translation from the SGML-based HTML 4.01. As such, it comes in three flavours:

    • XHTML 1.0 Transitional (includes the cruft that you claim is not in XHTML)
    • XHTML 1.0 Strict (The XHTML you describe)
    • XHTML 1.0 Frameset (ick)

    Later XHTML specifications build on XHTML Strict, but you can't use any of them with Internet Explorer without violating RFC 2854.

  10. some of my experiences by jilles · · Score: 4, Informative

    I try to make valid XHTML 1.0 strict pages. Of course if you turn your back for a second it is easy to let some none standard stuff slip in. But on the whole my sites should (mostly) validate as xhtml 1.0 strict.

    The nice thing about XHTML is that it is really straightforward to maintain. It's HTML the way it is supposed to be. If you don't use CSS to style it, it probably renders something usefull in any browser in use today. The problem is that you need to use CSS to provide layout and that no browser fully supports the CSS standards correctly. Mozilla does a nice job but does have many known bugs if you try to do some more exotic stuff. Internet explorer comes along nicely, as long as you avoid specific constructions. Opera and KHTML probably don't do a bad job either but I don't test for those.

    Overall I am positive about XHTML. I deliberately do not support netscape 4 (the handfull of users of that product have plenty of alternatives) and that does make life easier. If only it didn't try to interpret the CSS!

    The only downside of XHTML is that you have to use CSS, which IMHO is a very flawed language for what it's supposed to do. It is way too complex and that is also the reason why there is currently no fully compliant implementation available. In addition it is awfully limited in what it can do. It can be very frustrating to get very basic designs implemented in CSS. E.g. there is no obvious, clean way to get a status bar below three variable height columns. There's several dirty ways of doing it, though.

    Annoyingly, Internet Explorer always manages not to support features you absolutely need to get an elegant design working in it (this is not a problem with CSS of course). Really the only reason people resort to javascript for making menus is internet explorer's lack of support for CSS. You can do collapsible, nested menus with just a handfull of straightforward lines of CSS.

    Mozilla does a lot better and you are unlikely to run into bugs unless you really know your way around CSS. Typically the stuff that doesn't work requires a CSS expert to explain to mere mortals what it was supposed to do in the first place.

    I recently browsed through the CSS3 specs and I really hope to see some good implementations of it soon. It solves a lot of problems. Unfortunately I am very pessimistic about seeing any compliant implementations of it in wide use in the near future.

    Lately I have been giving some thought to doing mozilla only designs. It would make life much more pleasant. Unfortunately over 80% of my visitors are stuck with internet explorer.

    --

    Jilles
    1. Re:some of my experiences by mnewton32 · · Score: 2, Informative

      I deliberately do not support netscape 4 (the handfull of users of that product have plenty of alternatives) and that does make life easier. If only it didn't try to interpret the CSS!

      if you load an external stylesheet using the @import command, NN4 doesn't know what you're on about and ignores the stylesheet altogether.

  11. Warning: Google by ptaff · · Score: 2, Informative

    I try to be as strict as possible. For this reason, I send my webpages (written in pure XHTML1.1) with a proper content-type: text/xml (XHTML should NOT be sent as text/html)

    Google will not correctly index pages sent as text/xml: it will simply write "File format: unrecognized", even with the proper !DOCTYPE, even with the html tag :( cloak your pages, everybody!

    MSIE has this nasty problem with the XHTML1.1 doctype, gives an error. Documents should be sent as text/html too. I guess it won't be fixed in the standalone version which is now to be discarded by Microsoft.

    The best way I've found to make browsers digest the HTML entities (we're not all using 7-bit clean languages!) is to never use entities, use plainly the numerical code.

    Apart from that, Mozilla is a great platform for XHTML, and even MathML and SVG (if your build has that enabled). So the modular nature of XHTML is becoming more and more useful ;) Great thing about Mozilla is its XML debugger: a "mismatched td in line 1226" is something you _need_.

    You must be careful with javascript in Mozilla too... old tricks a la document.write won't work; you have to do it the 'right way': through the DOM. And SGML comments wrapping STYLE and SCRIPT sections must be enclosed in proper CDATA marks.

    For those who complain that CSS is too complicated, it's just a matter of knowing, not understanding. The only thing you have to understand is that some elements are blocks, others are lines. All is declarative, there's not even a for loop or an if to confuse you :) After you know the names of the properties, it's really very easy.

    To conclude, yes, XHTML is the right way, but you have to polish it, like you'd do in other real programming languages. It's not for Aunt Sally anymore!

  12. Article at xml.com... by h3 · · Score: 2, Informative

    This article has a great discussion on transitioning to XHTML and suggests a very cool trick for how to handle browsers that don't like application/xhtml+xml:

    http://www.xml.com/pub/a/2003/03/19/dive-into-xml. html

    -h3