SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 35 of 35
  1. #26
    SitePoint Addict SilentBobSC's Avatar
    Join Date
    Mar 2005
    Location
    South Carolina
    Posts
    226
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by molona View Post
    But how do you serve it? As text/html or as an application? Only XHTML 1.0 can be served as text and then it is like regular HTML (although with few differences such as not using capital letters for the tags, and so on).
    The system I work with most frequently is DotNetNuke, the skins I create usually use the XHTML 1.0 Transitional Doctype to account for the varied code output by both the core CMS as well as 3rd party modules.

  2. #27
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,862
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by SilentBobSC View Post
    The system I work with most frequently is DotNetNuke, the skins I create usually use the XHTML 1.0 Transitional Doctype to account for the varied code output by both the core CMS as well as 3rd party modules.
    Sounds like you are using HTML.

    XHTML pages don't display at all if there is any validation error (or your visitor is using Internet Explorer 8 or earlier).
    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="^$">

  3. #28
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by molona View Post
    XHTML doesn't stand for anything in particular as far as I know (or at least, the W3C don't say that each letter is a reference to a particular word)
    Just a quick correction for you molona, XHTML does stand for something (and it is "Extensible Hypertext Markup Language"), it inherited the Extensibility X from XML

  4. #29
    SitePoint Zealot
    Join Date
    Mar 2008
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Two handy references:

    Activating Browser Modes with Doctype - Choosing a Doctype

    Web-Sniffer HTTP Request & Response Header Viewer - can be employed to check how any Web Page is being served to various Graphical Browsers (specified via User Agent window).

    James

  5. #30
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,862
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by jamesicus View Post
    Two handy references:

    Activating Browser Modes with Doctype - Choosing a Doctype

    Web-Sniffer HTTP Request & Response Header Viewer - can be employed to check how any Web Page is being served to various Graphical Browsers (specified via User Agent window).

    James
    Theymay be useful references but neither of them has anything whatever to do with this topic since neither of them relate to the difference between HTML and XHTML. The first reference is about the doctype and the second about what HTTP protocol the page is using but neither covers the MIME type which is what determines whether a page is HTML (with MIME type text/html) or XHTML (with MIME type application/xml+xhtml).
    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="^$">

  6. #31
    SitePoint Zealot
    Join Date
    Mar 2008
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    Theymay be useful references but neither of them has anything whatever to do with this topic since neither of them relate to the difference between HTML and XHTML. The first reference is about the doctype and the second about what HTTP protocol the page is using but neither covers the MIME type which is what determines whether a page is HTML (with MIME type text/html) or XHTML (with MIME type application/xml+xhtml).
    You are wrong. Doctype - its use and effect - has been referenced several times in this thread and use of the Web-Sniffer HTTP Request & Response Header Viewer will certainly reveal the MIME type. Please check things out before you opine so imperiously.

    James

  7. #32
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Off Topic:

    imperious opining! : )

  8. #33
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,862
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by jamesicus View Post
    You are wrong. Doctype - its use and effect - has been referenced several times in this thread and use of the Web-Sniffer HTTP Request & Response Header Viewer will certainly reveal the MIME type. Please check things out before you opine so imperiously.

    James
    The doctype has nothing to do with whether it is HTML or XHTML only whether the CSS should be treated as standard mode (if a valid doctype is present) or quirks mode (if no doctype or invalid doctype).

    Examining the headers doesn't help any in actually setting the page to use the appropriate MIME type. So that web sniffer only touches peripherally on the topic.

    Just because people sometimes go off the topic in a thread (in this one mostly due to misunderstanding what a web browser does with a doctype) doesn't mean that others shouldn't try to bring it back on topic.

    Doctypes have nothing whatever to do with whether a web page is HTML or XHTML. You can use either a HTML or XHTML doctype to define your HTML page. You must use an XHTML doctype for an XHTML page but since both HTML and XHTML can use an XHTML doctype iit does not tell you anything about whether the page is HTML or XHTML.

    To set up an XHTML page you need to do one of the following.
    1. Set up your web server so that it has an extension defined for web pages that will insert the appropriate MIME type.
    2. If you don't have access to the server config file then you can add an appropriate line to the .htaccess file (or equivalent for servers not using Apache).
    3. You can use a server side language to insert the MIME type header in front of the page content (as I did with the example XHTML page that I posted earlier in the thread).

    Iif you don't do any of those things then you are not usiing XHTML but are instead using HTML regardless of what doctype you use.

    Trying to open the web page in Internet Explorer is a much easier way to check if the page is HTML (displayed) or XHTML (offered for download) than using any sort of sniffer that you can download or run from a web site since most people already have a copy of Internet Explorer (the ultimate XHTML sniffer) installed on their computer and they don't have to bookmark it to fiind iit again since it is easy to find on their computer whenever they need to check if a web page is HTML or XHTML.
    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="^$">

  9. #34
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    Browsers do care, if you actually use
    XHTML 1.0 is nothing more than a reformulation of HTML 4.01 as an application of XML 1.0. The only purpose for its existence was so that you could parse it with an XML parser and include elements from other XML namespaces. Since Internet Explorer doesn't support it and most markup authors don't know what they are doing, XHTML markup is almost always served as HTML. That means none of the alleged benefits apply; rather the opposite: you depend on (non-standardised) browser error handling since all you are really using is invalid HTML.


    That's most likely because you are serving your 'XHTML' as HTML and because you are using a limited subset of XHTML syntax. IE supports most of HTML and its error handling lets you get away with the invalid markup.
    The idea that serving HTML content as XML is pointless is incredibly short sighted

    By allowing the document to be parsed as XML, it allows it to interact seamlessly with other XML technologies. For example. XSLT. It's incredibly useful to transform XML data into an XHTML document using XSLT (either server side or clientside) it allows for separation of content and presentation.

    Whether or not end users web browser's can handle the XHTML page correctly is almost irrelevant, it's the fact that external web services can use your website with far greater ease because it's well formed, easy to parse and easy to load content from is where serving as XML really shines is.

    The non-standardised error handling isnt a problem, because the only major browser which doesn't support XHTML is IE, which handles the errors in the way we want. Everything else can correctly parse the XHTML.

  10. #35
    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 TomB View Post
    The idea that serving HTML content as XML is pointless is incredibly short sighted
    Is it? People have been using pretend-XHTML since 1999 and it's still as pointless today as it was 10 years ago. And 10 years is a pretty long time on the web.

    Quote Originally Posted by TomB View Post
    By allowing the document to be parsed as XML, it allows it to interact seamlessly with other XML technologies.
    But it mustn't be parsed as XML if it's served as text/html! That says it's HTML and should be parsed as HTML or SGML.

    Quote Originally Posted by TomB View Post
    For example. XSLT. It's incredibly useful to transform XML data into an XHTML document using XSLT (either server side or clientside) it allows for separation of content and presentation.
    Yes, (server-side) XSLT can be very useful. Keep your input data as XML and apply XSLT to transform it to a format that web browsers can handle.

    So you use XSLT to transform the XML data into HTML. If, one day in the distant future, XHTML becomes a viable, well-supported option and you need to use elements from other XML namespaces, guess what: change <xsl&#58;output method="html"/> into <xsl&#58;output method="xml"/>, modify the doctype declaration and add the XHTML namespace to the <html> tag. And you're done.

    In other words: using XSLT is no excuse for serving the result as pretend-XHTML. XSLT can serialise the DOM as HTML just as well as XML.

    Quote Originally Posted by TomB View Post
    Whether or not end users web browser's can handle the XHTML page correctly is almost irrelevant, it's the fact that external web services can use your website with far greater ease because it's well formed, easy to parse and easy to load content from is where serving as XML really shines is.
    Again you are mistaken. If you serve the document as text/html it must not be parsed as XML. You may as well try to load it into PhotoShop and claim it's a JPEG image.

    If you use XML+XSLT on your server, you can easily serve content as HTML to browsers and XML or XHTML to web services.
    Birnam wood is come to Dunsinane


Tags for this Thread

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
  •