SitePoint Sponsor

User Tag List

Page 1 of 4 1234 LastLast
Results 1 to 25 of 77

Thread: why xhtml?

  1. #1
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)

    why xhtml?

    its been talked over a million times, i have read lots of forums and seen it in lots of places,
    if you like, you can read this before answering:
    Differences Between HTML and XHTML
    additional links shown within the thread:
    The reason for most of these html vs xhtml conversations
    W3C page on Serving XHTML 1.0
    W3C Content-Negotiation Techniques to serve XHTML as text/html and application/xhtml+xml
    XHTML media type test - results - dated

    but my question is different in a small way.

    why use xhtml if Internet explorer does not support it?

    if you like the style of xhtml why not use html 4 with xhtml like coding but with the correct headers?

    the simpler the answer the better, no one wants another xhtml vs html discussion forum, only opinions on why coding in strict html style with the correct headers is not normally used?

    and as a reminder, the question is
    why use xhtml if Internet explorer does not support it?
    Last edited by YuriKolovsky; Jan 23, 2009 at 17:05.

  2. #2
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,782
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Hi

    IE does not support the [snip]application/xhtml+xml[/snip] MIME type, and will prompt the user to download the page if it's served as such. You can make IE recognise this MIME type through a registry hack, but it will still treat it as HTML.

    There really is no reason why people use it. It's basically like a new toy. If you need the XML features of XHTML, you can serve the document as [snip]application/xml[/snip]. That is supported by IE, but XHTML's namespace is not, which means IE will see the document as generic XML. There will be no default style sheet, so you have to specify explicit rules for every element type (including display:block for all block-level elements).

    You can, of course, serve XHTML markup as [snip]text/html, but as has been mentioned above that means the document will be seen as HTML with syntax errors.

    Cheers.
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  3. #3
    SitePoint Enthusiast
    Join Date
    Nov 2008
    Posts
    65
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by YuriKolovsky View Post
    why use xhtml if Internet explorer does not support it?
    • To allow the use of other XML, such as MathML, SMIL, or SVG. These will work even if your page is served as text/html.
    • To get started quickly. If you're just getting started with front-end coding, and your teacher (person, book, website) teaches XHTML, that's what you should use. There are more important things to learn when you're starting out than the differences between HTML and XHTML.

  4. #4
    SitePoint Wizard drhowarddrfine's Avatar
    Join Date
    Aug 2005
    Posts
    3,438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by chris cressman View Post
    To allow the use of other XML, such as MathML, SMIL, or SVG. These will work even if your page is served as text/html.
    Whoops! Wait! What?
    I'm pretty sure MathML will not render correctly. SVG will but I don't recall about SMIL.

    EDIT: Hmm. Unless I'm wrong.

  5. #5
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    If you need the XML features of XHTML, you can serve the document as [snip]application/xml[/snip].
    wouldn't writing just XML be better?

    To allow the use of other XML, such as MathML, SMIL, or SVG. These will work even if your page is served as text/html.
    SVG does seem like a valid point.
    (but i also heard, that Internet explorer does not support it? is this true?)

    To get started quickly. If you're just getting started with front-end coding, and your teacher (person, book, website) teaches XHTML, that's what you should use. There are more important things to learn when you're starting out than the differences between HTML and XHTML.
    and if not? and what if he is not starting?
    Last edited by YuriKolovsky; Jan 22, 2009 at 12:18.

  6. #6
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    My answer: I don't use XHTML. I used to, because my two books started me on that side of the bed. I redo sites back to HTML4.01 Strict.

    Though I also find myself quickly changing the doctype to something ridiculous like XHTML1.1 just to see what errors I might have. To catch whatever the validator won't say with an HTML4 DTD (ignoring of course the unclosed empty tags).

    My husband's boss just like the false sense of security XHTML gives him. He knows the validator will be strict with him and doesn't want to leave it to chance with HTML4. Lots of things are perfectly valid in HTML4 that a "strict" author may not want left alone like that.

  7. #7
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Some people use it just to make it easier to test that the pages comply with decent author standards.

    The standards the validators test against are the W3C standards for browser writers and the HTML one requires browsers to allow a loot of tags to be optional which a web page author should consider to be mandatory (such as head and body tags, closing paragraphs, tbody tags in tables etc) that all make web pages far easier to maintain.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  8. #8
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by chris cressman View Post
    To allow the use of other XML, such as MathML, SMIL, or SVG. These will work even if your page is served as text/html.
    Only in severely broken user agents. HTML has no support for XML namespaces and should ignore such elements. And an HTML parser is unlikely to be able to parse an XML document anyway, due to the significant differences in NET syntax. (Not that contemporary browsers support HTML NET.)

    And even if you get it to 'work' in broken browsers, there's no way your documents will be valid HTML. (Except, possibly, in the abomination known as HTML5, where 'anything goes'.)
    Birnam wood is come to Dunsinane

  9. #9
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    My answer: I don't use XHTML. I used to, because my two books started me on that side of the bed. I redo sites back to HTML4.01 Strict.
    note taken.

    Some people use it just to make it easier to test that the pages comply with decent author standards.
    very true.

    Only in severely broken user agents. HTML has no support for XML namespaces and should ignore such elements. And an HTML parser is unlikely to be able to parse an XML document anyway, due to the significant differences in NET syntax. (Not that contemporary browsers support HTML NET.)

    And even if you get it to 'work' in broken browsers, there's no way your documents will be valid HTML. (Except, possibly, in the abomination known as HTML5, where 'anything goes'.)
    that is not really of concern until every browser makes it work, which is going to take a while...

    taking all into account, and considering that i will avoid svg, smil, mathml
    the solution sounds like the one offered above
    Stomme poes:
    Though I also find myself quickly changing the doctype to something ridiculous like XHTML1.1 just to see what errors I might have. To catch whatever the validator won't say with an HTML4 DTD (ignoring of course the unclosed empty tags).
    just making the website in html 4 and swapping occasionally to check validation for errors.

    best of two worlds

  10. #10
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    What we really need is a decent HTML author validator that takes into account all the things that a decently written web page should incorporate.

    The W3C HTML browser validator leaves out the half of the validations that browsers need to have as optional which should be mandatory for web page authors.

    A decent author validator would do away with the need to use pretend XHTML just to get access to a proper validator.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  11. #11
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    What we really need is a decent HTML author validator that takes into account all the things that a decently written web page should incorporate.

    The W3C HTML browser validator leaves out the half of the validations that browsers need to have as optional which should be mandatory for web page authors.

    A decent author validator would do away with the need to use pretend XHTML just to get access to a proper validator.
    this is how the ideas are made and later incorporated into W3C

    so the conclusion is simple, we need a proper HTML 4.0 validator until a version of XHTML that is supported by ie gets released with its own validator,

    in both cases, its just a case of validation and that is why it is used by the general public, its just so much easier to have your code graded...

    that answers pretty nicely why xhtml is generally used. (unless i understood something wrong)

  12. #12
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Well, now, the HTML validator is doing its job. The DTD says "these are the rules" and the validator merely looks to see if your code matches the rules. The rules say you can start a <p> and don't have to end it-- you can write a page this one and it's perfectly valid.

    So, the answer then is "custom DTDs". Which was something XHTML promised, if you used the "X" in it. Like, we now consider it Good Form to close our li's and p's but it's not part of the rules we're writing by. It's optional.

  13. #13
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    So, the answer then is "custom DTDs".
    i just happened to be reading about them, they do seem complicated, but if a good one for html 4.0 gets made and accepted, one that does not accept non closed tags, and maybe uses xhtml style of markup, then the mass public will swap.

    but until then, we either code in html 4.0 occasionally testing in validators and such, or take it to the next level by making custom DTDs, too bad not one client will realise anything of this.

    but if a web developer is making a website for himself, it might not be a bad idea.

  14. #14
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Maybe I've misunderstood what some have been saying.

    Validation: The W3C validator will check syntax against the declared DTD. HTML DTDs follow html rules and xhtml DTDs follow xhtml rules. If you want xhtml 'strictness' in your html, force the validator to use xhtml strict as the DTD. You will have the expected namespace and short form tag errors, but it will check for missing html, head, and body tags, and for missing end tags on elements such as p and option. (tbody is required in the DOM, but is optional in your markup for either html or xhtml)

    Usage: It doesn't make a hill of beans difference which syntax you prefer to follow. Think of them as dialects of the same language, html. As long as you use an .html, .htm, .php, or .hotchamama extension that your server delivers as MIME type text/html, the browser will treat it as html. It doesn't matter what your DTD or html-equiv says. It's html if the server says it is. Change the extension to .xhtml, and Apache's default config will say it's of MIME type application/xhtml+xml, and the browser will believe it.

    Extensibility: Is fun. The reason I use an xhtml DTD is that I maintained a lan that used the extensibility quite heavily. Extending xhtml is much simpler than building pure xml documents; it's exactly the same as authoring html, just different. As a result, I settled on the xhtml syntax for myself to avoid silly errors as I moved from one dialect to the other. I have also hacked Emacs, and configured Tidy, my main authoring tools, to reflect xhtml's grammar.

    Choice: XHTML looks to be a dead end, due to MSFT's obdurate attitude. Unless you have compelling reason otherwise, or have a long ingrained habit such as mine, go with the html DTD.

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  15. #15
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Choice: XHTML looks to be a dead end, due to MSFT's obdurate attitude. Unless you have compelling reason otherwise, or have a long ingrained habit such as mine, go with the html DTD.
    yep

    Maybe I've misunderstood what some have been saying.
    to make it clear: xhtml is for learning purposes only, maybe for validation at times, but html 4 is the way to go as soon as you get your roots in xhtml.
    sounds confusing, maybe this is why there is so much discussion about this.

    Extensibility: Is fun.
    fun is not always critical, nor necessary, but it is fun

    Usage: It doesn't make a hill of beans difference which syntax you prefer to follow. Think of them as dialects of the same language, html.
    visually no difference, using the page, also no difference, but
    it does, deep in the dark parts of html and stuff lurches a whole bunch of errors, that i don't plan to release.


    im just building a clear idea in my mind, of how things should be done, and when and how the different aspects of web design should be used.

    to repeat what i just wrote:
    xhtml is for learning purposes only, maybe for validation at times, but html 4 is the way to go as soon as you get your roots in xhtml.

    is this correct? or completely wrong?

  16. #16
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by gary.turner View Post
    Choice: XHTML looks to be a dead end, due to MSFT's obdurate attitude. Unless you have compelling reason otherwise, or have a long ingrained habit such as mine, go with the html DTD.
    It doesn't have a great deal of use for public web pages at the moment but that doesn't mean it is dead.

    With the way Internet Explorer use is falling it may even become practical for web use by the end of next year.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  17. #17
    SitePoint Enthusiast
    Join Date
    Nov 2008
    Posts
    65
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by chris cressman View Post
    To allow the use of other XML, such as MathML, SMIL, or SVG. These will work even if your page is served as text/html.
    Sorry for posting this. It's incorrect. I think I was (incorrectly) remembering James Edwards' Sitepoint article on HTML vs XHTML. What he actually said is that he uses content negotiation to send XHTML to browsers that support it. In those browsers, he can use SVG, and his solution degrades gracefully in browsers that don't support XHTML (they get HTML).

    So, to return to the question, "why use xhtml if Internet explorer does not support it?," one reason is that other browsers do support it. By using content negotiation, you can get the benefits of XML (assuming you need them) in most browsers, while degrading gracefully in IE.

  18. #18
    SitePoint Zealot
    Join Date
    Mar 2008
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    XHTML (Extensible HyperText Markup Language) is defined and described in the W3C XHTML 1.0 Recommendation (Second Edition) XHTML Documents should be served as Content (MIME) type application/xhtml+xml to have XML functionality as prescibed by the Recommendation.

    Appendix C of the Recommendation (HTML Compatibility Guidelines) provides information for Web authors who wish to produce XHTML documents that will render in HTML specific user agents. Such documents must be served as Content (MIME) type text/html -- they are really HTML rather than XHTML documents. Practically all extant XHTML pages are being served this way.

    This situation will prevail until Microsoft changes its stance on support for the Content (MIME) type application/xhtml+xml.

    Some Web Service Provider implementations do not recognize this content (MIME) type. In that event, the web author must contact his or her Web Service Provider to try and convince them to adopt application/xhtml+xml as the content (MIME) type to associate with XHTML documents. If that doesn't work -- and it sometimes doesn't -- then the web author is faced with the task of producing and loading up to the server an .htaccess file that provides the association. Content (MIME) type can also be established via server side scripting.

    Current XHTML with XML compliant browsers such as Firefox, Mozilla, Opera, Safari, et al. will retrieve and render XHTML documents served as content (MIME) type application/xhtml+xml as intended - with full XML functionality.

    MSIE Browsers will not retrieve and render XHTML served as content (MIME) type application/xhtml+xml correctly. MSIE 6.0 release 2900 and 7.0 will display such pages alright but will not render xml content. MSIE 6.0 release 2800 and earlier Browsers present a download screen -- selecting OPEN displays a plain, text only page (sans style sheet) and again will not render xml. IE6 Browsers render pages headed by the XML prolog in Quirks mode.

    This is a dilemma for web authors and the W3C which has attempted to resolve this situation by embracing Content Negotiation -- usually via PHP on the server side -- in order to offer a choice of content (MIME) type text/html or application/xhtml+xml XHTML documents to browsers so that they can render them according to their capabilities -- thus only XML compliant browsers will be served fully functional XHTML documents.

    I have composed the great majority of my Web pages using HTML 4.01 (strict) Markup. (actually using ISO-HTML for the page "core"). However, now that the Semantic Web is evolving as a viable implementation I am converting some of my sites to XHTML+RDFa (now a registered DTD for the W3C SGML Validator -- but not yet for the preferred XML Schema Validator) or XHTML 1.0 (strict). I serve most pages via content negotiation. I am now using GRDDL (Griddle) to extract, transform and output Dublin Core (DC) Metadata for my Roman Coin pages as part of a collaborative construction of an online data base -- XHTML does play a big part in the Semantic Web.

    JFP

  19. #19
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    One of the biggest problems to resolve if you do use content negotiation is that if you do anything of any significance with JavaScript in the page that you then need two copies of the JavaScript and to serve up the appropriate one of those based on the MIME type you serve the page as since the DOM calls in XHTML are different from the HTML ones and there is no way to tell from within the JavaScript (that I know of) to tell whether to use the HTML calls or the XHTML calls (eg. createElement or createElementNS).
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  20. #20
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by gary.turner View Post
    Usage: It doesn't make a hill of beans difference which syntax you prefer to follow. Think of them as dialects of the same language, html.
    No, please don't do this! XHTML is not a 'dialect' of HTML; it is an application of XML that defines the same semantics as HTML.

    HTML and XML are two fundamentally different languages, even if they share a common ancestor (SGML). The fact that there are some superficial similarities shouldn't dupe you into believing they're one and the same.

    XHTML is not 'HTML that looks like XML'. It is 'XML that looks like HTML'. The difference is huge, and anyone who doesn't understand this difference really shouldn't attempt to write XHTML.

    On the other hand, all the abuse of pretend-XHTML over the last decade has ensured that XHTML is dead as a dodo anyway, so perhaps it doesn't matter.
    Birnam wood is come to Dunsinane

  21. #21
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    No, please don't do this! XHTML is not a 'dialect' of HTML; it is an application of XML that defines the same semantics as HTML.
    I agree, saying XHTML and HTML are different dialects is like saying chalk and cheese are two varieties of food. Which proves that you can't just judge on superficial appearances.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  22. #22
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    No, please don't do this! XHTML is not a 'dialect' of HTML; it is an application of XML that defines the same semantics as HTML.

    HTML and XML are two fundamentally different languages, even if they share a common ancestor (SGML). The fact that there are some superficial similarities shouldn't dupe you into believing they're one and the same.
    If the documents are both served as text/html, they are not fundamentally, only syntactically, different. Which, being the point I was making.

    As long as we are not serving the xhtml document as xhtml, e.g. application/xhtml+xml, it is simply a variant of html—a dialect (a variety or subdivision of a language) of the language.

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  23. #23
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No, if we are serving the document as text/html then it is HTML. Not a variant of HTML, but HTML. Invalid HTML, to boot, for anything but the simplest of documents. HTML with syntax errors. I wouldn't call that a 'dialect' or 'variant'.
    Birnam wood is come to Dunsinane

  24. #24
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    No, if we are serving the document as text/html then it is HTML. Not a variant of HTML, but HTML. Invalid HTML, to boot, for anything but the simplest of documents. HTML with syntax errors. I wouldn't call that a 'dialect' or 'variant'.
    which also happens to fail in internet explorer.

    i myself am a solid firefox fan, but i still see very many people use ie.

    in my head it looks like this:
    1. xhtml in text/html mode works everywhere but its xml abilities are broken in every browser possible.
    2. xhtml in application/xml mode works everywhere with its xml abilities except internet explorer.
    3. html 4 works everywhere but has no xml abilities.
    (3. basically the same as 1.)

    so unless i really really need the features of xhtml which i think most designers/developers dont even know about, i would stick to html 4.

    the solutions to this problem are:
    1. use xhtml in its proper mode, and ignore ie completely, and say, use a "modern" browser to view site (not very nice).
    2. use xhtml in html mode and pretend your using the capabilities of xhtml.
    3. use html 4 and have it working in all browsers, but miss out on the xml features of xhtml, which is not that fatal for most websites.
    4. have a server side langauge manipulate the page format depending on the brower used, to use 100&#37; of the xhtml capabilities in "proper" browers and have a proper html 4 website for ie.

    as it looks, for a person who specialises in IE only web design, he should not even think about xhtml, not even know it exists.

    while the other browser specialists should also use html, unless they really need the abilities of xhtml, in which case use server side solutions to degrade gracefully for it (and add a huge load of unnecessary work).

    but most of the general designer/developer population will just go with the flow of xhtml in text/html and not bother with these mind breaking problems.


    am i thinking correctly?

  25. #25
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by YuriKolovsky View Post
    1. xhtml in text/html mode works everywhere but its xml abilities are broken in every browser possible.
    It's not quite right to say that its XML abilities are broken, because it is HTML and cannot be expected to have any XML abilities.

    Quote Originally Posted by YuriKolovsky View Post
    2. xhtml in application/xml mode works everywhere with its xml abilities except internet explorer.
    With application/xml it will work, to a degree, in IE. It will be recognised as XML, but not as XHTML.
    With application/xhtml+xml it won't work at all.

    Quote Originally Posted by YuriKolovsky View Post
    3. html 4 works everywhere but has no xml abilities.
    Right, and very few people need XML abilities on their web pages.

    Quote Originally Posted by YuriKolovsky View Post
    am i thinking correctly?
    I can't give an answer to that but, for what it's worth, you're thinking much along the same lines as me.
    Birnam wood is come to Dunsinane


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •