Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 31
  1. #16
    Regular Coder
    Join Date
    Jun 2002
    Location
    Sheffield, UK
    Posts
    552
    Thanks
    0
    Thanked 0 Times in 0 Posts
    so which browsers will actually render XHTML documents served as text/xml, application/xml and/or application/xhtml+xml?
    "To be successful in IT you don't need to know everything - just where to find it in under 30 seconds"

    (Me Me Me Me Me Me Me Me Me)

  2. #17
    Senior Coder gsnedders's Avatar
    Join Date
    Jan 2004
    Posts
    2,340
    Thanks
    1
    Thanked 7 Times in 7 Posts
    Safari, and I think FireFox and Opera 7 will as well.

  3. #18
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    Opera only started supporting the <script> tag in 7.5 when served as application/xhtml+xml and the like. Commands like document.write() don't work in Gecko either, when it is served as an XML mime-type, because the root document is XMLDocument and not HTMLDocument. I don't know anything about how Safari handles an XML mime-type, other than it does.

  4. #19
    Regular Coder
    Join Date
    Nov 2002
    Posts
    672
    Thanks
    1
    Thanked 1 Time in 1 Post
    What does it mean to be "served as"? I've never heard of a server treating XHTML any different than HTML. Does this new file type mean anything when rendering? Is XHTML supposed to have it's own unique file extension if we want to distinguish it from the ordinary htm files? Was it a mistake that I used an XHTML 1.1 DTD on my pages instead of XHTML 1.0 Strict? What's going on with this?

  5. #20
    Senior Coder gsnedders's Avatar
    Join Date
    Jan 2004
    Posts
    2,340
    Thanks
    1
    Thanked 7 Times in 7 Posts
    XHTML 1.1 must be served as application/xhtml+xml, however, XHTML 1.0 can be served as text/html. As for the extension, you can use .xhtml, however I would advice against it, and use .html

  6. #21
    J&J
    J&J is offline
    New Coder
    Join Date
    Sep 2003
    Location
    your temp folder
    Posts
    89
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Cool try unicode to ward off spam

    Personally, I use unicode to display my email address & prevent spam. Web pages display it correctly, but spambots don't understand it. If you don't know how to convert it to unicode -- here's a website that does it for you, free:

    http://andrew.hedges.name/experiments/obfuscator/


    Just enter your email address on the left, & the unicode version will be shown on the right.
    ~ J&J ~
    "Sometimes I feel like I'm rearranging deck chairs on the Titanic."


    Work | Family | Community

  7. #22
    Regular Coder
    Join Date
    Nov 2002
    Posts
    672
    Thanks
    1
    Thanked 1 Time in 1 Post
    Quote Originally Posted by J&J
    Personally, I use unicode to display my email address & prevent spam. Web pages display it correctly, but spambots don't understand it. If you don't know how to convert it to unicode -- here's a website that does it for you, free:

    http://andrew.hedges.name/experiments/obfuscator/


    Just enter your email address on the left, & the unicode version will be shown on the right.
    So that's what unicode is? I thought it was ASCII (when the numbers are converted to hex, they match the numbers a hex editor will display for ascii text). I've always used only #64 to encode the @ sign since it's the most important part. Without that, the rest is insignifigant to the rest of the contant that may appear on the page. It's a nice link though.

  8. #23
    Senior Coder
    Join Date
    Feb 2003
    Location
    Ontario, Canada
    Posts
    1,223
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Isn't it highly likely that someone will write a spambot that looks for @ and its unicode equivelant? Wouldn't seem like something terribly hard to do...

    I think it'd be clever to just encode the surrounding parts of the @. What're the odds of one looking for &xxx;@&xxx;&xxx;&xxx; ?

    I just don't show my email anywhere and force visitors to use my contact <form> :P Those spammers will clue in eventually I betcha.

  9. #24
    Regular Coder
    Join Date
    Jun 2002
    Location
    Sheffield, UK
    Posts
    552
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Opera seems to ignore the CDATA dec when it's ecnased in /* */ CSS comments, anybody know what a good fix would be?
    "To be successful in IT you don't need to know everything - just where to find it in under 30 seconds"

    (Me Me Me Me Me Me Me Me Me)

  10. #25
    Senior Coder
    Join Date
    Jun 2002
    Location
    near Oswestry
    Posts
    4,508
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by ReadMe.txt
    Opera seems to ignore the CDATA dec when it's ecnased in /* */ CSS comments, anybody know what a good fix would be?
    A fix would be not to do it - a commented CDATA section is a contradiction: a non-XML-aware browser doesn't understand CDATA, so it serves no purpose, and an XML-aware browser should require the /* */ to be inside the CDATA section.

    There's no correct way to do that trick. Just put the styles in an external file.
    "Why bother with accessibility? ... Because deep down you know that the web is attractive to people who aren't exactly like you." - Joe Clark

  11. #26
    Master Coder
    Join Date
    Feb 2003
    Location
    Umeå, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    Quote Originally Posted by brothercake
    A fix would be not to do it - a commented CDATA section is a contradiction: a non-XML-aware browser doesn't understand CDATA, so it serves no purpose, and an XML-aware browser should require the /* */ to be inside the CDATA section.
    What? XML parsing precedes XML "rendering" (for lack of a better word for it) precedes parsing of any embedded content in another language, such as CSS or JavaScript. Thus, there would be no such requirement. Let's illustrate it:

    Source
    Code:
    <head>
    <style attributes>
    selector {
         property : value; /* <![CDATA[ <a & comment> ]]> */
        }
    </style>
    </head>
    XML Parsing
    Code:
    01. Start Element head
    02. Text "\u000a"
    03. Start Element style
    04. Attributes attributes
    05. Text "selector {\u000a    property : value; /* "
    06. Start CDATA
    07. Text " <a & comment> "
    08. End CDATA
    09. Text " */\u000a    }\u000a"
    10. End Element style
    11. Text "\u000a"
    12. End Element head
    XML "rendering"
    Code:
    Element head
    > Text "\u000a"
    > Element style
    > > Attributes attributes
    > > Text "selector {\u000a    property : value; /*  <a & comment>  */\u000a    }\u000a"
    > Text "\u000a"
    Which means that the content sent to the CSS parser will be as follows:
    Code:
    selector {
        property : value; /*  <a & comment>  */
        }
    Last edited by liorean; 08-30-2004 at 08:22 PM.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  12. #27
    Regular Coder
    Join Date
    Jun 2002
    Location
    Sheffield, UK
    Posts
    552
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by brothercake
    A fix would be not to do it - a commented CDATA section is a contradiction: a non-XML-aware browser doesn't understand CDATA, so it serves no purpose, and an XML-aware browser should require the /* */ to be inside the CDATA section.

    There's no correct way to do that trick. Just put the styles in an external file.
    well i needed it to be inline to hide from NS4, so since i was using an accept sniffer to server up different doctypes i served up uncommented cdata blocks with the xml mimetype and regualr old style html comments for the old doctype.
    "To be successful in IT you don't need to know everything - just where to find it in under 30 seconds"

    (Me Me Me Me Me Me Me Me Me)

  13. #28
    New Coder
    Join Date
    Jun 2005
    Posts
    35
    Thanks
    0
    Thanked 0 Times in 0 Posts
    A current observation using CDATA as opposed to <!-- is that babelfish (the page translator) currently seems to only recognize the latter.

  14. #29
    Regular Coder
    Join Date
    Nov 2002
    Posts
    672
    Thanks
    1
    Thanked 1 Time in 1 Post
    For validation, this has never let me down:

    Code:
    <script type="text/javascript">
    //<!CDATA[
    
    /*For loops and other things using the less than and greater than sign won't throw you errors now */
    
    //]]>
    But for pure XHTML (served as application/xhtml+xml), would it be more preferable for the script type to be application/x-javascript instead?

  15. #30
    Senior Coder
    Join Date
    Jun 2002
    Location
    near Oswestry
    Posts
    4,508
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Tails
    But for pure XHTML (served as application/xhtml+xml), would it be more preferable for the script type to be application/x-javascript instead?
    Surely "text/ecmascript" is technically most correct?
    "Why bother with accessibility? ... Because deep down you know that the web is attractive to people who aren't exactly like you." - Joe Clark


 
Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

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