SitePoint Sponsor

User Tag List

Page 9 of 9 FirstFirst ... 56789
Results 201 to 215 of 215
  1. #201
    Caveat surfer Buddy Bradley's Avatar
    Join Date
    May 2003
    Location
    Cambridge, UK
    Posts
    2,366
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dualism
    In an XHTML document, you cannot set the charset in the a <meta> tag, it has to be done with something like this:
    Code:
    <?xml version="1.0" encoding="utf-8"?>
    .
    That's not quite right - the code you posted can be used to set the encoding of an XML document if you don't want it to use the default utf-8 or utf-16; but if you want to send a different charset you have to send it in the HTTP-header, which can't be accomplished using normal page code - it is either set on the server, or can be added on the fly using a server-side language such as PHP.
    Quote Originally Posted by Dualism
    When editing it through that, however, you must rename your XHTML files .xhtml or .xht. One question I have is what happens if you use PHP on the page as well. Does that still apply?
    You don't have to rename your files, you can set any extension to be parsed in whatever way on the server. Same with PHP files.
    Quote Originally Posted by Dualism
    ...some "advanced authors" are able to send XHTML as application/xhtml+xml to browsers that support it, but also as text/html to browsers that won't support true XHTML, such as Internet Explorer...I'd be very interested to see if this type of solution is available, as it will solve many problems than a lot of us here seem to be having.
    That is called "content negotiation" - and if you Google that, the first result (apart from Apache's server manuals) is our own Autistic Cuckoo's article. Have a read through that for details on how to do it (hint: it involves buffering the output while you parse all the XHTML-specific bits out of it).

  2. #202
    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 Buddy Bradley
    That's not quite right - the code you posted can be used to set the encoding of an XML document if you don't want it to use the default utf-8 or utf-16; but if you want to send a different charset you have to send it in the HTTP-header, which can't be accomplished using normal page code - it is either set on the server, or can be added on the fly using a server-side language such as PHP.
    You can use the XML declaration to specify the encoding, provided that you don't send one in the Content-Type HTTP header. Since XML is supposed to be a self-describing markup language, some claim that it is 'harmful' to send the encoding as a HTTP header. I haven't thought too much about it.

    The XML specification only requires conforming user agents to support UTF-8 and UTF-16, but I guess most will also support a number of other encodings. ISO&#160;8859-1 is probably one of them.

    If you use a different encoding than UTF-8 or UTF-16, I'd recommend specifying it in the XML declaration (regardless of whether you do it in the HTTP header). If the document is saved to disk, the parser needs this information.

    Quote Originally Posted by Buddy Bradley
    That is called "content negotiation" - and if you Google that, the first result (apart from Apache's server manuals) is our own Autistic Cuckoo's article.
    Oh, I didn't realise it had climbed that high on Google.

    Quote Originally Posted by Buddy Bradley
    Have a read through that for details on how to do it (hint: it involves buffering the output while you parse all the XHTML-specific bits out of it).
    There are several ways of doing this, and the method I've outlined in that article is one of them. This presumes that the files are stored as XHTML 1.1, maintaining as much compatibility with HTML as possible. Using string replacement or regular expression to convert XHTML into HTML is an evil thing to do, though. You need to be very careful with how you write your markup, or it can come back to bite you. If you also accept external input, such as blog comments, you must validate them very carefully.

    Many sites use what I call 'content type negotiation,' i.e. they'll use the Accept header to decide whether to send application/xhtml+xml or text/html, but they will still send the same XHTML 1.0 markup. As long as it follows all the guidelines in Appendix C, that's OK, too.
    Birnam wood is come to Dunsinane

  3. #203
    Caveat surfer Buddy Bradley's Avatar
    Join Date
    May 2003
    Location
    Cambridge, UK
    Posts
    2,366
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo
    You can use the XML declaration to specify the encoding, provided that you don't send one in the Content-Type HTTP header.
    Oopsie. Can I pretend that's what I meant..? <- dunce hat

  4. #204
    CSS & JS/DOM Adept bronze trophy
    Join Date
    Mar 2005
    Location
    USA
    Posts
    5,482
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Dualism, XHTML can be tag soup just as much as HTML can. It's a separate matter.

    Quote Originally Posted by AutisticCuckoo
    There are several ways of doing this, and the method I've outlined in that article is one of them. This presumes that the files are stored as XHTML 1.1, maintaining as much compatibility with HTML as possible.
    Don't you mean XHTML 1.0?

    I've heard that you can do the content negotiation with .htaccess as well as with a server side language like PHP.

    Unless you want to use fancy things that require XML, I recommend just sticking with HTML 4.01.
    We miss you, Dan Schulz.
    Learn CSS. | X/HTML Validator | CSS validator
    Dynamic Site Solutions
    Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.

  5. #205
    One website at a time mmj's Avatar
    Join Date
    Feb 2001
    Location
    Melbourne Australia
    Posts
    6,282
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dualism
    in the second post in this thread, there was a link to this document, which contained a link to here. In that second document, Hickson explains why it's incorrect to use text/html with XHTML and the problems it'll cause later on, but also outlines the limitations to using true XHTML by using the application/xhtml+xml MIME type. However, he does note in an Appendix B that some "advanced authors" are able to send XHTML as application/xhtml+xml to browsers that support it, but also as text/html to browsers that won't support true XHTML, such as Internet Explorer. Now, if that's the case, I'd be interested to know why there hasn't been more discussion on doing this.
    I think that Hixie isn't saying that XHTML should never be served as text/html to a browser that will accept application/xhtml+xml. His page is more of a generic rant about the state of XHTML support and the fact that we have to resort to measures such as using text/html, even though it is a solution with many problems.

    I think Hixie would agree that if your document is XHTML 1.0 and it would otherwise work if it were application/xhtml+xml, then it is quite acceptable to send it as text/html to existing browsers until there's a more practical alternative. I don't think that serving text/html to some browsers and application/xhtml+xml is very practical for many people. Maybe I'm putting words in Hixie's mouth.
    [mmj] My magic jigsaw
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The Bit Depth Blog Twitter Contact me
    Neon Javascript Framework Jokes Android stuff

  6. #206
    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 Kravvitz
    Don't you mean XHTML 1.0?
    No.

    I use only 'xml:lang' in my markup ('lang' is not allowed in XHTML 1.1). The replacement function replaces 'xml:lang' with 'lang' (among other things).

    @Thomas, I think Hixie's point is that there are bigger differences between XHTML and HTML than just case-sensitivity, well-formedness and quoted attribute values.
    Birnam wood is come to Dunsinane

  7. #207
    CSS & JS/DOM Adept bronze trophy
    Join Date
    Mar 2005
    Location
    USA
    Posts
    5,482
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok, so you give XHTML 1.1 to browsers that support it and HTML 4.01 to browsers that don't. Seems like a lot of extra server load to me.

    Right, XHTML 1.1 removed a bunch of HTML attributes that have XML equivalents.
    We miss you, Dan Schulz.
    Learn CSS. | X/HTML Validator | CSS validator
    Dynamic Site Solutions
    Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.

  8. #208
    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 Kravvitz
    Ok, so you give XHTML 1.1 to browsers that support it and HTML 4.01 to browsers that don't. Seems like a lot of extra server load to me.
    It's negligible, actually. It's absolutely silly, though, since I can't use any X(HT)ML features anyway: it must be possible to convert to HTML through simple string manipulation.

    I'm currently rewriting the blog system from the ground up, and the new version will most likely serve HTML 4.01 Strict to all browsers.
    Birnam wood is come to Dunsinane

  9. #209
    SitePoint Enthusiast smashingjay's Avatar
    Join Date
    Apr 2005
    Location
    Bridgewater, Nova Scotia, Canada
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just my $0.0248 CAD ($0.02 USD).

    I have scanned the W3C reccommendation and read most of this thread and have become uncertain as to any conclusion.

    The w3c seems to suggest in the Appendix C that there is room to have HTML compatibility for XHTML docs. In addition, I found evidence that there is a benefit for certain projects, despite current browser support, to use XHTML strict, even if it isn't being served as such, as it sets a stage for a certain level of forward compatibility, which according to the w3c is a benefit of using XHTML.

    It certainly depends on the project, whether that level of forward compatiblity will be required, but when thorough planning concludes that a site is going to be the basis for future incorporation of more advanced features of XHTML, that you are not, at that time going to have to rewrite or revise the code for that purpose.

    Obviously there are tons of sites that need no more than to use HTML4.01 and CSS for delivery. In addition, regardless of doctype, all documents should be written to the higher standard not the bottom standard. Write your HTML 4.01 cleanly and standardly (don't mix tag cases just 'cause its allowed etc.) and validate, validate, validate!

    As a result of this thread I think we should all consider our selected doctype's purpose for the benefit of the project and not our egos.

    Jay
    SmashingRed Web and Marketing
    Affordable Websites & Marketing Solutions
    for Real Small Business.

  10. #210
    SitePoint Member Dualism's Avatar
    Join Date
    Oct 2004
    Location
    Pocatello, Idaho
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Buddy, mmj, and AutisticCuckoo: Thanks for the clarifications. I'm still new at this, so I was just sort of grasping at straws.
    Learn something about everything and everything about something.

  11. #211
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo
    It's negligible, actually. It's absolutely silly, though, since I can't use any X(HT)ML features anyway: it must be possible to convert to HTML through simple string manipulation.

    I'm currently rewriting the blog system from the ground up, and the new version will most likely serve HTML 4.01 Strict to all browsers.
    Instead of converting to HTML through simple string manipulation could you not use XML parsers in PHP to go through, convert the template to HTML and save it. You should, if you use the right logic, be able to do it quite easily.

    Just a thought, never implemented it myself

  12. #212
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm currently rewriting the whole system. The information will be stored in XML and read into a DOM tree, on which I can apply server-side XSLT to generate all sorts of output: HTML, XHTML, RSS, Atom, ...
    Birnam wood is come to Dunsinane

  13. #213
    SitePoint Member Dualism's Avatar
    Join Date
    Oct 2004
    Location
    Pocatello, Idaho
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ... o.O

    Just listening to you say that makes my head spin. I feel so far behind the learning curve that it'll take forever to catch up to the really competent people. I'm going to go cry now.
    Learn something about everything and everything about something.

  14. #214
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just imagine what it's doing to my head then.
    Birnam wood is come to Dunsinane

  15. #215
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    I thought staring at code effected your eyes it most.


    The goalposts always move so nobody is always proficient.


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
  •