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?

73 comments

  1. Backward Compatability by dJCL · · Score: 3, Insightful
    I would love to code XHTML strict, but there is the problem of my users, you see, they are not technical, they don't all upgrade thier browser when they can, even when they are told too. I have to code in many ways to the lowest common denominator, then add or modify features for the better browsers and try to avoid breaking things.


    If you're on a controlled intranet or something similar and can control the browser used, your set, but I wish the real world was like that.


    This is one reason that I love templates thou, I have a work in progress template for my main site that is XHTML strict, so browsers that support it can have it.


    Enjoy!

    --
    On Arrakis: early worm gets the bird. Magister mundi sum!
    1. 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.

    2. Re:Backward Compatability by jdclucidly · · Score: 4, Interesting

      I think you're partially misinformed. XHTML will work in pretty much everything in existance. CSS, OTOH, is another story.

      Are we talking about content or design here?

      Because a number of sites (like this very popular one, Wired.com) use XHTML quite effectively with all known browsers. Sure, some browsers like Netscape Navigator will not render the design but all of the content is still accessible. Hell, I can even browse the thing in Lynx!

      So, I think the better question is: can the browsers display the content? And the answer is yes. Can they display all the new wiz-bang CSS layout stuff? The answer is probably. (Given that about 98% of the market is browsers that can.) Remember, it's far more important that your content is logically structured and accessible (which is what XHTML does) than it is that it looks classy (CSS).

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

    4. Re:Backward Compatability by AShocka · · Score: 1

      What to do, you can see by all the discussion here, that even when you follow standards, to get the most out of your efforts you have probably end up doing non standard things to trick the non standard compliant browsers into behaving in a standard type way.

      It's a vicious cycle. But still, these days, there are far more benefits to being as standard compliant as possible

      I think this is a legitimate strategy to serve documents in a correct manner because of browser bugs, especially as it is controlled in the server configuration, and especially as MS is too lazy to invest money to update IE. But maybe sticking to XHTML Strict DTD 1.0 is sufficient

    5. Re:Backward Compatability by Anonymous Coward · · Score: 0

      I have to say this is fucking stupid. Every other version of HTML was distingished by the !DOCTYPE -- what makes XHTML 1.1 so special that one has to reconfigure MIME types for it?

      Once again the W3C has proven themselves to be jackoffs rather than trying to advance the state of the art in useful ways. $10 says you guys will be having this same conversation 2 years from now.

    6. Re:Backward Compatability by Markusis · · Score: 1

      Well, technically it isn't breaking the spec, just bending it really far. The spec actually reads that html 4.01 _should_ be served as text/html, xhtml 1.0 _should_ be served as application/xhtml+xml, xhtml 1.1 _should_not_ be served as text/html, and it is very likely that the xhtml 2.0 spec will say that xhtml _must_not_ be served as text/html. So, while the spec strongly recommends against serving xhtml as text/html, if it keeps IE rendering the page, then I'm happy.

      This was all taken from Mark Pilgrim's "Dive into XML" article available here.

    7. Re:Backward Compatability by Dracos · · Score: 1
      I have to code in many ways to the lowest common denominator

      If all the people out there would just grow some balls and future proof their sites by implementing modern standards now, the sooner this problem will go away. A little "Your browser sucks, download Mozilla" won't hurt anyone. Then delete iexplore.exe to make them use Moz... nobody will miss the popups.

    8. Re:Backward Compatability by Etyenne · · Score: 1

      If only IE would support transparent PNG images.

      It does, in indexed mode (aka PNG8).

      In The Gimp, create a new image with Fill Type set to transparant. Right-click the image, "Image", "Mode", "Indexed". Save as PNG. Bingo, PNG with transparency that work in IE.

      More precisely, IE does not support the alpha channel of PNG.

      --
      :wq
    9. Re:Backward Compatability by hether · · Score: 1

      I hope you are kidding. I know that when designing a website for a client saying "Your browser sucks, download Mozilla" could definitely hurt. And deleting files? Come on. That could even be considered malicious.

      Sometimes you just have to code for what's out there. Try to change the world along the way, but realize that you're not going to convince everyone right away. There are ways to design for the standards and achieve backwards compatability at the same time.

      --

      Most people would die sooner than think; in fact, they do.
    10. Re:Backward Compatability by JimDabell · · Score: 1

      Well, technically it isn't breaking the spec, just bending it really far.

      No, it is actually breaking the spec. You (and Mark) are referring to an unofficial Note produced by a member of the W3C. A quote from that document:

      This document is a Note made available by the World Wide Web Consortium (W3C) for your information. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.

      I am referring to RFC 2854. This RFC provides the list of document types that may be sent as text/html. It includes XHTML 1.0, but not any other type of XHTML. In particular, even some forms of XHTML 1.0 are unsuitable for being labelled as text/html.

    11. Re:Backward Compatability by JimDabell · · Score: 1

      I have to say this is fucking stupid. Every other version of HTML was distingished by the !DOCTYPE -- what makes XHTML 1.1 so special that one has to reconfigure MIME types for it?

      Alternately, what makes XHTML 1.0 so special that it is allowed to be sent as text/html? After all, there are situations where XHTML treated as tag soup means something different to the HTML equivelant.

      $10 says you guys will be having this same conversation 2 years from now.

      But of course we will. There won't be a new version of Internet Explorer out within two years, so we'll be stuck with text/html for at least that long.

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

    2. Re:no problems here... by donutz · · Score: 1

      For instance, Pocket IE renders them as content.

      Pocket IE just plain sucks. Hopefully the new "Windows Mobile" Pocket IE has addressed this issue.

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

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

  6. cliff: the chart is lousy. by Trelane · · Score: 4, Insightful

    The chart you supplied is lousy. Either it's vastly out of date, or it's deliberately slanted against non-IE browsers.

    For one, it simply lists an x for what is apparently full support, an (s) for somewhat supported, and nothing for no support. This is a terrible way of comparing things, since different browsers have different levels of support and different bugs in their implementation. CSS2 support is notoriously problematic, iirc. Not to mention that having "DHTML" and "JavaScript" support categories after this x/(s)/ fashion is fairly ludicrous. What about the various W3C CSS and DOM levels, and even the various components within DOM level 2?

    But the most blatant problem with the table is the fact that it covers Internet Explorer 6, Netscape 6, Netscape 4, and Opera 3.02(!), amongst others. While IE6 is current, NS4 and Opera 3.02 certainly are not! Not to mention that NS7, while quite nice, is lacking a lot from the cutting-edge Mozilla 1.3 and 1.4 versions.

    Anyone have a better comparison chart? Please post 'em below!

    --

    --
    Given enough personal experience, all stereotypes are shallow.
    1. Re:cliff: the chart is lousy. by JimDabell · · Score: 3, Informative
    2. Re:cliff: the chart is lousy. by AShocka · · Score: 1

      That addresses CSS, but not HTML markup or programming the DOM, which put together unfortunately makes a Matrix so vast that even Neo couldn't master the knowledgebase

      .
  7. Worked fine for me by Anonymous Coward · · Score: 0

    I have done a bit of XHTML developing. I wanted to use it instead of HTML4.01. So i started using XHTML instead of HTML. So far I think i have had great success in IE6,Netscape7, and Opera(6|7). Actually .. i think i have had more problems with CSS1 than XHTML. But I should note I was using XHTML Transitional.

  8. Thoughts on IE and Moz by Anonymous+Brave+Guy · · Score: 1

    IE handles XML+XSLT+CSS pretty well, certainly in version 6.

    Mozilla's support would be OK, but it suffers from the same overly nitpicky irritation as it does with HTML+CSS: it stubbornly refuses to acknowledge that a file could possibly be XML or whatever unless the MIME type is correct. Given that even fewer servers, particularly those run by ISPs for their personal subscribers rather than run by companies for themselves, get the MIME type right for X* than they do for HTML+CSS, Moz is out of the race as a serious contender no matter how good its standards support may be.

    In an attempt to preempt the inevitable slashbot responses, yes, I agree that standards are important, but they are only a means to an end. If you stick to standards so religiously that you can't actually do the job -- in this case, displaying the content as the provider and end user want -- what's the point?

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    1. 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.

    2. Re:Thoughts on IE and Moz by JimDabell · · Score: 4, Insightful

      Mozilla's support would be OK, but it suffers from the same overly nitpicky irritation as it does with HTML+CSS: it stubbornly refuses to acknowledge that a file could possibly be XML or whatever unless the MIME type is correct.

      Stubborn? It's a required part of the HTTP specification. Every browser other than Internet Explorer gets this right.

      Given that even fewer servers, particularly those run by ISPs for their personal subscribers rather than run by companies for themselves, get the MIME type right for X* than they do for HTML+CSS, Moz is out of the race as a serious contender no matter how good its standards support may be.

      Granted, there are a few wonky servers out there, but they aren't anywhere near as widespread as you make out. If the server you are on is serving your files incorrectly, and you cannot fix this yourself, then complain. You are getting a substandard service.

      I agree that standards are important, but they are only a means to an end.

      If Mozilla and other browsers do the exact opposite of what the public specifications require, and instead blindly copy Internet Explorer, then they have essentially given control of that specification to Microsoft. How can this be a good thing?

    3. Re:Thoughts on IE and Moz by Anonymous+Brave+Guy · · Score: 1
      If I tell a browser to display something as text/plain, I don't want it rendered as html.

      Unfortunately, you are in a tiny minority. The vast majority of web sites I've seen trying to deliver XML content but sending it with a text/plain MIME type wanted it interpreted as XML.

      By all means leave the standard compliant interpretation in Moz, but at least provide an override to deal with the vast majority of cases where it's a simple error on the part of the server administrator (who frequently has nothing to do with either the information provider nor the end user).

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    4. Re:Thoughts on IE and Moz by Anonymous+Brave+Guy · · Score: 1
      It's a required part of the HTTP specification. Every browser other than Internet Explorer gets this right.

      And that makes what, 10% of the end user market between all of them? That's probably generous.

      Granted, there are a few wonky servers out there, but they aren't anywhere near as widespread as you make out. If the server you are on is serving your files incorrectly, and you cannot fix this yourself, then complain. You are getting a substandard service.

      Yes, I'm getting a substandard service. And right now, as far as I can see, I'd get the same substandard service from every other major UK ISP I know about. And yes, I have mailed my ISP about it, long ago, but nothing's been done. Short of setting up my own server, at great expense I can't afford, I have no option but to rely on ISPs, who aren't exactly well-known for getting this sort of thing right.

      If Mozilla and other browsers do the exact opposite of what the public specifications require, and instead blindly copy Internet Explorer, then they have essentially given control of that specification to Microsoft. How can this be a good thing?

      OK, reality check please. I use a browser because I want to see the information. That information may not be sent perfectly to spec, and as I've said elsewhere I have nothing against defaulting to standard-compliant behaviour. However, failing to acknowledge that this is a common error in the protocol, and for that matter that Microsoft does effectively define the standard web formats today given their market penetration, is simply burying your head in the sand. Providing a compatibility option wouldn't be rocket science.

      I don't want to see Microsoft control the web any more than the next guy. But refusing to accept that it currently holds a dominant position, and sticking to open standards on principle even when that fails to achieve what the user wants, is not the way to reduce the influence of Microsoft and the market share of their closed standards. It's a fight no free alternative, not even the likes of Mozilla or OpenOffice, can possibly win.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    5. Re:Thoughts on IE and Moz by Anonymous Coward · · Score: 0

      You can't even override your mime types with .htaccess at your ISP?

    6. Re:Thoughts on IE and Moz by __past__ · · Score: 1

      Indeed, an option "Interpret this document as if it were of mime type ..." would be tremendously useful in lots of other contexts. Especially in situations where some clever admin decided to send you source code as application/x-c-source or whatever, and I just want to read it in the browser, some way to tell it "this is text/plain, dammit!" would make the world a less annoying place.

    7. Re:Thoughts on IE and Moz by Anonymous Coward · · Score: 0

      I can't, but that proves how silly this is. The server uses a file extention to MIME mapping file. The client uses a MIME to file extention mapping file. Why bother?

      Your .htaccess file is never going to know about all 10,000 existing file extensions. (Like the Apple server that was oblivious to their own SMI disk image format.) Until we get decent meta-data into our filesystems, forget aobut MIME.

    8. Re:Thoughts on IE and Moz by Anonymous Coward · · Score: 0

      Using PHP, I can override any file's content-type. It's really as easy as adding a header line.

    9. Re:Thoughts on IE and Moz by iangoldby · · Score: 1

      Given that even fewer servers, particularly those run by ISPs for their personal subscribers rather than run by companies for themselves, get the MIME type right for X* than they do for HTML+CSS...

      Have you tried using an .htaccess file? Some ISPs at least allow it.

      AddType application/xhtml+xml xhtml

      and variants may help. I haven't tried this myself though, as I'm quite comfortable serving up xhtml as html-lookalike 8-)

    10. Re:Thoughts on IE and Moz by adelton · · Score: 1

      It would be nice to have one XHTML file on disk that would be served as application/xhtml+xml to clients that Accept it and as text/html to the others. Guess that could be done with mod_rewrite. However, you'd also need not to include the <?xml ... ?> declaration and processing instructions in that case, and for that you'd already need content handler (assuming Apache) that would work on the data in the stream, not just the meta information.

      Just switching everything to application/xhtml+xml will not work if a reasonable percentage of user agents won't render it.

    11. Re:Thoughts on IE and Moz by iangoldby · · Score: 1

      It can be done with mod_rewrite - a quick search on Google will show how.

      You don't need to worry about the <?xml ...?> - the spec says it's optional, and in fact it is better to leave it out for IE6's sake, because it causes IE6 to enter quirks mode.

    12. Re:Thoughts on IE and Moz by JimDabell · · Score: 1

      I can't, but that proves how silly this is. The server uses a file extention to MIME mapping file

      Err, no. That is one mechanism, and probably the most convenient from your perspective, but it is by no means the only mechanism.

      The client uses a MIME to file extention mapping file. Why bother?

      Because there are no file extensions in URLs. A period is just a period. Who cares what mechanism you use - unless you are assuming that everybody uses the same mechanism as you, which is just plain wrong.

      Your .htaccess file is never going to know about all 10,000 existing file extensions.

      Why should my .htaccess file need to know 10,000 file extensions? Most sites only serve a dozen or so, most of them are covered by the default Apache setup, and the others you wouldn't like to be part of your web browser.

      Until we get decent meta-data into our filesystems, forget aobut MIME.

      You are confusing filesystem hierarchies with URLs - in many cases there may be a one-to-one mapping, but this certainly isn't a reliable assumption.

      As an example, please let me know what you think the mime type for .content files is. Over here, it varies between at least three different mime-types, and in many cases, there isn't a file involved at all.

  9. Why I gave up on XHTML for now by Anonymous Coward · · Score: 0

    Yes, you can do XHTML and serve it as text/html and have it work pretty good. But what's the point? It's not actually XHTML when served that way, it's just regular HTML. For that reason, I just went back to HTML 4.01, which can be coded pretty similarly to XHTML anyway and still validate.

    1. Re:Why I gave up on XHTML for now by JimDabell · · Score: 1

      What? XHTML served as text/html validates just fine.

    2. Re:Why I gave up on XHTML for now by Anonymous Coward · · Score: 0

      You're missing the point. XHTML served as text/html is not really XHTML, it's just HTML with a fancy new name and a new pair of shoes. My point was that XHTML and HTML 4.01 can be coded almost identically and still validate (just make sure you close all your tags).

  10. Compliance and awareness by fm6 · · Score: 1
    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?
    I think you answered your own question. As you point out, support for XHTML is "vague". That's another way of saying that compliance is very bad.

    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.

    Of course, your XHTML tags don't specify exactly how your document is presented, you have to put formatting information somewhere else. That somewhere else is in style sheets. And CSS2 support sucks, especially in Internet Explorer. So you can't just write a CSS2-compliant style sheet and assume it will display the same way no matter what your browser is.

    Perhaps I'm overstating the compliance issue. Certainly awareness is a big problem as well. Most web developers just don't see any reason to worry about the difference between align="center" and style="text-align: center;". Come to think of it, I think the current version of Mozilla Composer is the first one that complies with XHTML this way.

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

    2. Re:Compliance and awareness by dwerg · · Score: 1
      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!)
      No, not just that. The main reason converting html to an xml specification is to allow user agents to use strict parsing and thus making the browser footprint smaller.
    3. Re:Compliance and awareness by fm6 · · Score: 1

      Is that an official goal? I was unaware. If so, don't hold your breath: no browser vendor is going to abandon html backward-compatibility in our lifetimes.

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

    2. Re:some of my experiences by Ark42 · · Score: 1

      Also if you use a media="all" netscape will ignore it..

    3. Re:some of my experiences by grolim13 · · Score: 1

      No it won't. Much to my chagrin they "fixed" that bug in 4.7something.

    4. Re:some of my experiences by redwolfoz · · Score: 1

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

      A very handy hack for dealing with NN4, but don't forget that it works on all level 4 browsers.

      Also worth remembering that NN4 can deal with some CSS, so use it and have a gracefully degrading web page that doesn't lock out the people who are stuck with crappy browsers.

      --
      and the werewolves came...
      and they ate him...
      and they drank his beer...
  12. Cruft and slop by fm6 · · Score: 1

    OK, I got sloppy about describing XHTML. But 1.0 transitional, is, well, transitional. The ultimate goal is ... well, see my previous post.

  13. Re:Backward Compatability / Forward Compatability by AShocka · · Score: 1

    You may loose your normal view of page layout formatting, but if you structure your XHTML Strict logically, it will still be a readable and navigateable document.

    If you structure your document well, with Strict DTD, you can apply different CSS to different media, and it takes very little editing and effort to do so.

    You can create printer friendly pages, mobile device pages, etc CSS, from exactly the same XHTML markup by applying different styles and displaying or hiding different sections.

    This also makes Strict more attractive to documents stored in XML and rendered through XSLT. It makes the target format more flexible, and also makes it much more easy to radically change the design (if need be), via some changes to the Style Sheets, which is no where near as easy when trying to attempt the same in Transitional DTDs.

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

    1. Re:Warning: Google by Anonymous Coward · · Score: 0

      Isn't the proper content type application/xhtml+xml?

    2. Re:Warning: Google by Anonymous Coward · · Score: 0

      Not necessarily application/xhtml+xml, you can use also application/xml and text/xml.

      http://www.w3.org/TR/2002/NOTE-xhtml-media-types -2 0020430/

      For browsers, usually the 3 give the same behavior.

    3. Re:Warning: Google by Anonymous Coward · · Score: 0

      Yes, that page says "SHOULD" use for application/xhtml+xml.

    4. Re:Warning: Google by Tassadar99 · · Score: 1

      Who cares, stupid {fool, dumb, idiot} coward?

      --
      Hardware is what you kick, Software is what you curse.
  15. viruses by Anonymous Coward · · Score: 0
    It is this "double-guessing" behaviour that has encouraged and propagated viruses. If there was only one way to specify the type we would not have programs like Outlook look at the Mime-Type (oh, an image!) while the "smarter" IE looks at the extension instead because it thinks it knows better (hmm, a vbs script - let's fire it up!).

    Plus, if you have ever tried to write a CGI to make the browser download a file instead of displaying it, you have probably seen how annoying can IE's behaviour be, when it insists on displaying GIFs and such because it decides it knows better.

    There is a problem with software that assumes everybody in the world is an idiot. People don't realize that "small" compatibility problems are Microsoft's way of forcing its own incompatible standards, thus forcing their own clients. It does not have to be too obvious or too complicated, just a small "feature" is enough.

    1. Re:viruses by Anonymous+Brave+Guy · · Score: 1
      It is this "double-guessing" behaviour that has encouraged and propagated viruses.

      I disagree. I think it's a poorly thought out security policy that runs executable code without proper checks that has done that. The fact that the flaw was in how MIME types were handled is coincidental. There are no MIME types in propagating a Word macro virus, but the underlying problem is the same.

      People don't realize that "small" compatibility problems are Microsoft's way of forcing its own incompatible standards, thus forcing their own clients.

      If another client provided an option to be compatible with the Microsoft client used by 90% of the world, then users wouldn't be forced to use Microsoft's, would they? :-)

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    2. Re:viruses by Anonymous Coward · · Score: 0

      I disagree. I think it's a poorly thought out security policy that runs executable code without proper checks that has done that. The fact that the flaw was in how MIME types were handled is coincidental.

      A firewall could easily filter out executables by using a mime-type whitelist. Except for the fact that Internet Explorer ignores the mime-type in many situations, meaning that the security measure you just put in place is absolutely useless.

    3. Re:viruses by Anonymous+Brave+Guy · · Score: 1
      A firewall could easily filter out executables by using a mime-type whitelist.

      That's just covering up a symptom of the underlying problem. Why do applications like web browsers, word processors and spreadsheets need the ability to run code, and automatically at that, when that code can damage the data on my computer?

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    4. Re:viruses by Anonymous Coward · · Score: 0

      No, the underlying problem is that people are stupid and run executables they get from untrusted sources. They'll even save executables and run them from their desktop if they think that they are going to get something out of it.

      Bottom line: IE is going against standards and making life difficult for those of us who are security conscious.

      http://www.pivx.com/larholm/unpatched/

      It's a fucking liability.

    5. Re:viruses by Anonymous+Brave+Guy · · Score: 1
      No, the underlying problem is that people are stupid and run executables they get from untrusted sources.

      You can't blame the end users for the sort of screw-ups we're talking about. There is little need for any web browser or word processor to provide scripting facilities that can affect data on my hard drive anyway. Even if the facilities are there, the problem is that "autoexec" scripts for WP documents, or automatically rendering HTML e-mail as if it were a web page, scripts included, allow the end user to run executable code when they wouldn't expect to be doing so.

      And if you're going to talk about liabilities, you might start with relying on a "standard" such as MIME types that is violated by large numbers of content providers, and by the browser that dominates the market. Such a standard isn't really standard at all, is it?

      I'm sorry, but your whole argument is just aiming at the wrong target.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  16. 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

    1. Re:Article at xml.com... by Neon+Spiral+Injector · · Score: 1
      The problem with the mod_rewrite suggested in that article, is the:
      RewriteCond %{REQUEST_URI} \.html$
      I follow the "cool URIs don't change" rules, and don't link to any .html pages, they are all served without extensions. So with no .html ending my REQUEST_URI the REWRITE will never be triggered.
  17. ISO HTML by joeljkp · · Score: 1

    If you want to be standards-compliant, and don't need the extras that XHTML provides, check out ISO/IEC 15445:2000 and the associated User's Guide.

    --
    WeRelate.org - wiki-based genealogy
  18. Marketshare by Farley+Mullet · · Score: 1

    This isn't a troll. I browse with either Safari or a Mozilla derivative, and use xhtml+css whenever I have to make a web page. That being said, if marketshare is the driving factor, then there's only one answer: MSIE for Windows. If you check out, say, Google's Zeitgeist survey, it's clear that the overwhelming majority of web surfers use MSIE, and that's what you have to cater too. Unfortunately for the rest of us.

  19. I use XHTML 1.1 Strict by MrWorf · · Score: 1

    And it's good fun. Sure, sometimes you miss the good old frames or the target attribute on your links (solvable via javascript) but all in all, using XHTML has made the layout on my site (www.sensenet.nu) alot easier. Also, the use of stylesheets meant that I could easily custimize/skin the site as needed.

    The only problem as I see it, is that XHTML 1.1 and CSS isn't always good. Just a simple thing such as aligning text & images in the center of a div means that I need to resort to tables since <center> isn't allowed, and there is no horizontal-align (only text-align which "SHOULD" apply to text only, but some browsers seems to know better (ie, worse)).

    As for compatibility, Opera, IE and Mozilla has sucessfully rendered my pages. Ofcourse, there are some minor bugs (Mozilla sets borders on hidden form field, Opera adds lots of space between lines on <ul> lists) but all in all, I like it.

    Now, if only pseudoclasses worked as advertised on all browsers, my work would be alot easier :)

    Anyway, thats my five cents...

    1. Re:I use XHTML 1.1 Strict by JimDabell · · Score: 1

      Just a simple thing such as aligning text & images in the center of a div means that I need to resort to tables since isn't allowed, and there is no horizontal-align (only text-align which "SHOULD" apply to text only, but some browsers seems to know better (ie, worse)).

      The text-align property applies to inline elements, including inline replaced elements such as images. That is all you need, and pretty much all browsers that support CSS understand this.

      Internet Explorer has problems relating to horizontal alignment of block display elements, but this is a separate issue.

  20. OT: Nitpicking a phrase by JamesOfTheDesert · · Score: 1
    I have to code in many ways to the lowest common denominator ...

    I see this phrase a lot, and nine times out of ten, the writer should be saying, "the higest common factor."

    You're likely coding for the *most* features supported by all of the browsers, i.e., the largest set of supported HTML features. For example , the lowest common denomintor would be something like HTML 1 or 2; the highest common factor is likely HTML 3.2

    --

    Java is the blue pill
    Choose the red pill
  21. Thoughts on IE and Moz-A $ for your principles. by Anonymous Coward · · Score: 0

    "Providing a compatibility option wouldn't be rocket science."

    Which isn't the point. If you ever wondered why some software is the size it is, now you know.

    "I don't want to see Microsoft control the web any more than the next guy. But refusing to accept that it currently holds a dominant position, and sticking to open standards on principle even when that fails to achieve what the user wants, is not the way to reduce the influence of Microsoft and the market share of their closed standards. "

    So what is your plan, and how will bending your principles to more closely align with Microsoft's reduce the influence of their closed standards? You can't have your cake and eat it to. That's the price of principles.

    As has been pointed out time and again. You can't face Microsoft and win by playing by their rules. Go study the hustory of those companies that did and failed. Now study OSS and see why they haven't stomped us out, and never will. Aint principles grand?

    1. Re:Thoughts on IE and Moz-A $ for your principles. by Anonymous+Brave+Guy · · Score: 1
      Which isn't the point. If you ever wondered why some software is the size it is, now you know.

      It is entirely the point. Compatibility with existing software, particularly such dominant software as IE, is vital to any competitor that hopes to go anywhere. Can you name a single widely-used and successful product that has taken the crown in its field from an incumbent market leader without being compatible with it?

      So what is your plan, and how will bending your principles to more closely align with Microsoft's reduce the influence of their closed standards? You can't have your cake and eat it to. That's the price of principles.

      I'm not bending any of my principles. I value a useful product that is compatible with its peers above some theoretical advantage of compliance with a standard to which more than 90% of users do not adhere. One of the great claims of the whole "open whatever" movement is that it promotes compatibility and you can't be locked out. And yet here is a leading open product deliberately locking itself out of being compatible with the tool most people use.

      As has been pointed out time and again. You can't face Microsoft and win by playing by their rules. Go study the hustory of those companies that did and failed. Now study OSS and see why they haven't stomped us out, and never will. Aint principles grand?

      You can face Microsoft, play by their rules but better, and win. Linux, Apache and Java come to mind as examples where Microsoft has lost overall control of a market it previously dominated to a superior product.

      Now study OSS and ask yourself why tools like Mozilla and OpenOffice still have a market penetration that barely registers, when Mozilla is superior to IE in several important ways, and OpenOffice is a plausible and much cheaper alternative to Word for casual home users. They have the same disadvantages as so much open source: incompatibility, poor usability and poor marketing compared to the big players.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  22. XHTML media type test by hexene · · Score: 1

    See this table for information on which browsers do or do not support the "application/xhtml+xml" media type. The only present browser that is a cause of problems with it is Internet Explorer.

  23. XML UTF-8 support by vrykolaka · · Score: 1

    No browser on Mac (I did not check iCab) are able to support UTF-8 as an XML declaration

    <?xml version="1.0" encoding="utf-8"?>

    Actually, I have to add an HTML declaration

    <meta http-equiv="content-type" content="text/html; charset=utf-8" />

    Removing it will make my pages appear "hieroglyphic". So I conclude it is not supported yet. What about IE6?

    --
    -- Force & respect, Vrykolaka
  24. I don't trust him one bit... by James+Littiebrant · · Score: 1

    For crying out loud he WILLINGLY USES Internet Explorer! This usualy denotes phychoticness or what many psychiatrists use as a diagnosis "you are wack." But perhaps he is not all lost, he does use safari and mozilla...