SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 77

Thread: why xhtml?

  1. #26
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    With application/xml it will work, to a degree, in IE. It will be recognised as XML, but not as XHTML.
    then you might as well use normal xml

  2. #27
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Of course.
    Birnam wood is come to Dunsinane

  3. #28
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    then the question that i have seen no solution to in so many forums, is finally solved, for me.


    I can't give an answer to that but, for what it's worth, you're thinking much along the same lines as me.
    lets see how many more will share our opinions.

  4. #29
    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, 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'.
    Invalid against an html DTD, true. If you author a document against the xhtml 1.0 DTD, the W3C clearly says you may serve it as text/html. You have a perfectly valid document served with a perfectly valid http-equiv server response header. Only in some Philadelphia lawyer-ish way could that be called invalid.

    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

  5. #30
    SitePoint Zealot
    Join Date
    Mar 2008
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    While I am sure that most Web designers are familiar with Ian Hickson's 2002 treatise Sending XHTML as text/html Considered Harmful there may be some who have not read what was something of a "bomb shell" at the time.

    Note especially Appendix B (Advanced Authors) where Hickson discusses Content Negotiation, serving XHTML 1.1 as text/html, the use of XHTML 2.0 and the danger of Markup cut and paste.

    James
    Last edited by jamesicus; Jan 23, 2009 at 09:37. Reason: added info

  6. #31
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    yes i happened to have read that too some time ago, i should have thought of posting it.
    i will move the link to the top if you don't mind?

  7. #32
    SitePoint Zealot
    Join Date
    Mar 2008
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by YuriKolovsky View Post
    yes i happened to have read that too some time ago, i should have thought of posting it.
    i will move the link to the top if you don't mind?
    I don't know what the Forum rules are regarding this. As far as I am concerned, please feel free to copy the link to the top if that is permitted -- I would prefer to keep my post intact here as I believe it fits with the progression of the discussion.

    James

  8. #33
    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
    Invalid against an html DTD, true.
    And those are the rules user agents are following (well, they should, but they're all buggy). A 100% HTML compatible browser would render a pretend-XHTML document somewhat differently from what the author intended.

    Quote Originally Posted by gary.turner View Post
    If you author a document against the xhtml 1.0 DTD, the W3C clearly says you may serve it as text/html.
    They say it in an informal note, which means it carries no more weight than if you or I say it. And your statement is not entirely correct; only the small subset of XHTML 1.0 that complies with the rules in Appendix C of the specification is 'allowed' to be served as text/html. Not XHTML 1.0 markup in general. That's because the whole thing relies on undocumented browser bugs.

    Quote Originally Posted by gary.turner View Post
    You have a perfectly valid document served with a perfectly valid http-equiv server response header.
    So if I publish a book and claim that it's English because it passes a Swedish spell-checker, you'd consider it to be valid English? Whether it's valid XHTML or not is completely irrelevant if you serve it as HTML, because it will – must! – be parsed and interpreted as HTML.

    And the <meta/> element is completely ignored if the server sends a real Content-Type HTTP header. Besides, you cannot specify the MIME type in a meta element, because a user agent needs to know it before it starts handling the content.

    Quote Originally Posted by gary.turner View Post
    Only in some Philadelphia lawyer-ish way could that be called invalid.
    I won't pretend to understand that reference, but anything served as text/html must be treated as HTML by user agents. If it doesn't comply 100% with the rules of HTML, then it is invalid from a user agent point of view.

    I can't understand why this is so extremely difficult a concept to understand. (I'm not directing this to you personally, Gary; I've been going for years about this without getting through to a number of people who are obviously very intelligent and clear-headed).
    Birnam wood is come to Dunsinane

  9. #34
    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
    Invalid against an html DTD, true. If you author a document against the xhtml 1.0 DTD, the W3C clearly says you may serve it as text/html. You have a perfectly valid document served with a perfectly valid http-equiv server response header.
    No you don't.

    The browsers don't use the DTD to determine what type of content it is, they use the MIME type. If the MIME type is text/html then the content is considered to be HTML and not XHTML. Appendix C of the XHTML specification telly you how to write XHTML so that those parts that are invalid HTML will not cause the page to fail to work. It doesn't mean that those invalid parts are not there. The main one of these is to add a space in front of the / in self closing tags so that the / is the only thing in the attribute that the browser doesn't recognise rather than its being part of the prior attribute and messing that up too.

    It is perfectly possible to write a valid XHTML web page where almost nothing in the page is able to be understood as HTML.

    There are also lots of coding techniques perfectly valid in XHTML which will pass the XHTML validator but will totally fail if the page is served as HTML - for example <script type="text/javascript" src="my.js"/> which will not even work if you add the space before the / because the script tag in HTML requires a closing tag whereas in XHTML it is allowed to be self closing.
    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="^$">

  10. #35
    SitePoint Zealot
    Join Date
    Mar 2008
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There is good, concise information here: W3C page on Serving XHTML 1.0 - XHTML & MIME types, 'Standards' vs 'Quirks' modes, The XML declaration, etc.

    Edit - added:

    Here is a useful W3C page: W3C Content-Negotiation Techniques to serve XHTML as text/html and application/xhtml+xml


    James

  11. #36
    SitePoint Zealot
    Join Date
    Mar 2008
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Although now somewhat dated, the XHTML media type test - results tabulation provides some very useful data and information.

    James

  12. #37
    SitePoint Evangelist happyoink's Avatar
    Join Date
    Jan 2008
    Location
    UK
    Posts
    503
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @chris cressman,

    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.
    I firmly believe that novice coders should learn the differences between XHTML and HTML and the reasons why XHTML exists. I think that should be one of the first things they should learn. In my opinion it's a mistake to blindly follow the 'teacher' especially since there are misunderstandings about the differences floating around and even teachers in this area make mistakes unless they have years of solid experience in both XHTML and HTML along with everything else behind them. Learn the differences and the reasons behind them and then go with the most appropriate language for the project.

    @AutisticCuckoo,

    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.
    I agree, which is why I think novices should learn about the differences between XHTML and HTML at the start (along with other things, of course), and about why there are differences, etc. It's also why I code in HTML 4 Strict rather than in XHTML. In fact the only time I use XHTML is when I'm attempting to code a WordPress theme or a vBulletin style, etc - and even then (especially with WordPress), I use the Strict doctype. I have no other use for XHTML because I don't dabble with XML or any other technology.

  13. #38
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    browsers use DTD (Document Type Definition,)to define the html or xhtml specifications and to determine what mode to run, quirks, standards or almost standards.

    The DTD sets out
    the rules and grammar for that flavor of markup, enabling the browser to render the
    content accordingly.
    -source: the ultimate html reference book.

    as i understood it, the DTD will tell the browser how to read the document in the MIME type that it is served.

    If you author a document against the xhtml 1.0 DTD, the W3C clearly says you may serve it as text/html.
    a person CAN create a valid and working document in xhtml that works bug free in text/html mime type, but what is the point in achieving the miraculous achievement? feeling of self accomplishment? wordpress?
    not exactly practical when creating a world wide website, in my opinion.

  14. #39
    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 YuriKolovsky View Post
    as i understood it, the DTD will tell the browser how to read the document in the MIME type that it is served
    Browsers use the MIME type to determine how to render the document. The doctype does not get used to determine the rendering when the MIME type says it is HTML. It does actually get used properly for some of the other MIME types though in some browsers that support those types.
    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="^$">

  15. #40
    SitePoint Zealot
    Join Date
    Mar 2008
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A nice treatise relating to DocType sniffing by Henri Sivonen: Activating Browser Modes with Doctype

    James

  16. #41
    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 Silver Firefly View Post
    @I agree, which is why I think novices should learn about the differences between XHTML and HTML at the start
    In fact, I think it would be best if novices wouldn't bother with XHTML at all. You need to be a fairly advanced developer to have any use whatsoever for XHTML.

    Quote Originally Posted by YuriKolovsky View Post
    as i understood it, the DTD will tell the browser how to read the document in the MIME type that it is served.
    No, it tells a validating parser what the syntactic rules are for a markup language. Browsers don't use validating parsers; their 'knowledge' of HTML semantics is built-in.

    Quote Originally Posted by YuriKolovsky View Post
    a person CAN create a valid and working document in xhtml that works bug free in text/html mime type
    Not really. Any non-trivial XHTML document (e.g., one that contains a link to a CSS style sheet) will rely on buggy parsers to render as intended. If the browsers' parsers worked properly, an XHTML/Appendix C document served as text/html would contain occasional slash characters scattered over the page.
    Birnam wood is come to Dunsinane

  17. #42
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Not really. Any non-trivial XHTML document (e.g., one that contains a link to a CSS style sheet) will rely on buggy parsers to render as intended. If the browsers' parsers worked properly, an XHTML/Appendix C document served as text/html would contain occasional slash characters scattered over the page.
    its possible, it wouldn't necessarily have any css though...

    Browsers use the MIME type to determine how to render the document. The doctype does not get used to determine the rendering when the MIME type says it is HTML. It does actually get used properly for some of the other MIME types though in some browsers that support those types.
    No, it tells a validating parser what the syntactic rules are for a markup language. Browsers don't use validating parsers; their 'knowledge' of HTML semantics is built-in.
    so for most browsers the DTD will be used only for w3c markup validation purposes?
    i know it also triggers modes for browsers or am i wrong here?

  18. #43
    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
    its possible, it wouldn't necessarily have any css though...
    No, but that's why I said a 'non-trivial XHTML document'. And even if it doesn't have a style sheet (or if it includes it via a style element and an @import rule) it might contain one or more <img/>, <br/> or <hr/> elements, or other empty elements using NET syntax. And that syntax is different between HTML and XML.

    Quote Originally Posted by YuriKolovsky View Post
    so for most browsers the DTD will be used only for w3c markup validation purposes?
    i know it also triggers modes for browsers or am i wrong here?
    Browsers wouldn't normally care about the doctype declaration at all; its original purpose was for validating only. But nowadays, as you mentioned, browsers look at the doctype declaration to determine the rendering mode they'll use for CSS. It's really got nothing whatsoever to do with the doctype declaration or the DTD, and assuming that a document without a doctype declaration (or one without the FSI) should automatically cause CSS declarations to be applied incorrectly is not theoretically justified. It's just a numbers game, and the effect is that we now have to use a doctype declaration with a redundant FSI if we want our CSS to be applied according to W3C recommendations (or as close to that as contemporary browsers get).
    Birnam wood is come to Dunsinane

  19. #44
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    browsers look at the doctype declaration to determine the rendering mode they'll use for CSS. It's really got nothing whatsoever to do with the doctype declaration or the DTD
    that is confusing, what do you mean when you say It's ?

  20. #45
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    'It's' is a contraction of 'it has', where 'it' refers to the rendering mode mentioned in the preceding sentence. Being repetitive, I could have written,
    browsers look at the doctype declaration to determine the rendering mode they'll use for CSS. The rendering mode has really got nothing whatsoever to do with the doctype declaration or the DTD
    I'm sorry for the confusion.
    Birnam wood is come to Dunsinane

  21. #46
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    browsers look at the doctype declaration to determine the rendering mode they'll use for CSS. The rendering mode has really got nothing whatsoever to do with the doctype declaration or the DTD
    much better.
    but doesent it say:
    browsers look at doctype declaration to determine the rendering mode
    rendering mode has really got nothing to do with the doctype declaration

    so doctype has to do with rendering but rendering has nothing to do with the doctype?

    my confusion must be because of the lack of sleep i got.

  22. #47
    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
    much better.
    but doesent it say:
    browsers look at doctype declaration to determine the rendering mode
    rendering mode has really got nothing to do with the doctype declaration
    Yes, but …

    Quote Originally Posted by YuriKolovsky View Post
    so doctype has to do with rendering but rendering has nothing to do with the doctype?
    … no, that's not how it is. The doctype and the rendering have nothing to do with one another. Browsers look at the doctype declaration when choosing the rendering mode, but it's not the DTD itself they're interested in; only how the author wrote the declaration. If it's missing, or if it only contains an FPI, they guess that it's old-school and should be rendered in quirks mode. If it contains an FPI and a (redundant) FSI, they guess that it's modern and should be rendered in accordance with the CSS specification.

    But the doctype declaration doesn't really have anything to do with rendering, either. It's just the vehicle that browser vendors have chosen to use since doctype sniffing was first introduced in IE5/Mac (I believe).

    An analogy might be looking out the window before leaving for work, to check if it's raining. If lots of people out there are wearing rain coats, you may assume that it's, in fact, raining and that you should wear one too (or carry an umbrella). But you don't really know if it's raining just by looking for rain coats. It might be a recent fashion statement to wear rain coats regardless of weather. You're just using the presence of rain coats as something on which to base a guess about precipitation, just like browsers use the presence of an FSI in the doctype declaration as something on which to base a guess about standards compliance.
    Birnam wood is come to Dunsinane

  23. #48
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    oh, now i get it.
    Browsers look at how the doctype declaration was written at the top of the page when choosing the rendering mode, but not at the doctype.

    An analogy might be looking out the window before leaving for work, to check if it's raining. If lots of people out there are wearing rain coats, you may assume that it's, in fact, raining and that you should wear one too (or carry an umbrella). But you don't really know if it's raining just by looking for rain coats. It might be a recent fashion statement to wear rain coats regardless of weather. You're just using the presence of rain coats as something on which to base a guess about precipitation, just like browsers use the presence of an FSI in the doctype declaration as something on which to base a guess about standards compliance.
    nice analogy.

  24. #49
    SitePoint Evangelist happyoink's Avatar
    Join Date
    Jan 2008
    Location
    UK
    Posts
    503
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    In fact, I think it would be best if novices wouldn't bother with XHTML at all. You need to be a fairly advanced developer to have any use whatsoever for XHTML.
    I agree that novices wouldn't have any need for it but that doesn't mean they shouldn't learn about the differences between XHTML and HTML.

  25. #50
    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
    oh, now i get it.
    Browsers look at how the doctype declaration was written at the top of the page when choosing the rendering mode, but not at the doctype.
    Precisely.

    (Actually, some browsers make a minor difference in rendering mode depending on whether the declaration is for a Strict or a Transitional DTD. But they still don't look at the actual DTD itself.)

    Quote Originally Posted by Silver Firefly View Post
    I agree that novices wouldn't have any need for it but that doesn't mean they shouldn't learn about the differences between XHTML and HTML.
    You're right. Of course the should. But they shouldn't have to worry about that as they get started. They should first learn HTML properly. XHTML can come later, since it's not very useful after all. And it's not necessary for most of us, either.
    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
  •