SitePoint Sponsor

User Tag List

Page 11 of 11 FirstFirst ... 7891011
Results 251 to 265 of 265
  1. #251
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i don't challenge your point on how it should go down.

    serving xhtml as text/html and having namespaces with it, makes it "ok" in all browsers, even ie. so, i'm gaining. even if i'm relying on browsers to sort the mess up. invalid html, as you put it, but also invalid functional xhtml.

    i'm seeing here apps like lotus webmail. made specifically for ie, with xhtml doctype. that works. that's how it goes down. so what was their motivation, knowing that xhtml will be served as text/html.

  2. #252
    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 noonnope View Post
    serving xhtml as text/html and having namespaces with it, makes it "ok" in all browsers, even ie.
    Er no. I tried the example below. Served as real XHTML it works nicely in Opera, Firefox and Chrome. Served as HTML there is no SVG rendered in either browser (nor IE).

    Code XML:
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
      <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
        <title>SVG Test</title>
      </head>
      <body>
        <h1><abbr>SVG</abbr> Test</h1>
        <svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="300px" height="300px">
          <svg:circle cx="120" cy="150" r="60" style="fill:gold"/>
          <svg:polyline points="120 30, 25 150, 290 150" stroke-width="4" stroke="brown" style="fill:none"/>
          <svg:polygon points="210 100, 210 200, 270 150" style="fill:lawngreen"/>
        </svg:svg>
        <p>There should be an <abbr>SVG</abbr> example above this text.</p>
        <script type="application/javascript">
          alert(document.getElementsByTagName("h1")[0].tagName);
        </script>
      </body>
    </html>

    Quote Originally Posted by noonnope View Post
    invalid html, as you put it, but also invalid functional xhtml.
    No, please understand this: it isn't XHTML at all! It looks like it to you, but not to a browser. It is HTML. That's why the SVG example above doesn't work when served as text/html: HTML doesn't support XML namespaces.

    And even if you don't include SVG, MathML or similar, it's still not XHTML. Look at the JavaScript alert in the example above. When served as application/xhtml+xml the tag name is displayed in lowercase, since it uses the X(HT)ML DOM. When served as text/html the tag name is displayed in uppercase, even though it is specified in lowercase in the markup, since it uses the HTML DOM. It is HTML. It's not 'functional' XHTML or any other form of XHTML. It just looks like it to the human observer peeking at the source code.
    Birnam wood is come to Dunsinane

  3. #253
    SitePoint Evangelist Karpie's Avatar
    Join Date
    Jul 2007
    Location
    Perth, Australia
    Posts
    445
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    While I prefer HTML over XHTML (though I am the sole voice of reason for that one in my group), I must say, I wish XHTML 2.0's new tags and features had been used instead of HTML5's.

    Do not like HTML5...

  4. #254
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @Karpie: I agree wholeheartedly. With your whole post!
    Birnam wood is come to Dunsinane

  5. #255
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by noonnope View Post
    i don't challenge your point on how it should go down.

    serving xhtml as text/html and having namespaces with it, makes it "ok" in all browsers, even ie. so, i'm gaining. even if i'm relying on browsers to sort the mess up. invalid html, as you put it, but also invalid functional xhtml.

    i'm seeing here apps like lotus webmail. made specifically for ie, with xhtml doctype. that works. that's how it goes down. so what was their motivation, knowing that xhtml will be served as text/html.
    @AutisticCuckoo

    i must apologize. your info is reliable, mine is not. also, thank you for taking the time to correct my error.

  6. #256
    SitePoint Author silver trophybronze trophy

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

  7. #257
    SitePoint Addict
    Join Date
    Jun 2007
    Location
    Sydney, Australia
    Posts
    253
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What happened to AutisticCuckoo ?

  8. #258
    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)
    He is fine and healthy but for personal reasons doesn't want to post.

  9. #259
    SitePoint Zealot
    Join Date
    Dec 2008
    Posts
    118
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Is there any issue with writing XHTML, serving as xml, then using xsl (client side) to convert to HTML?

    (BTW Autistic Cukoo's example works fine for me served as text/html so long as you remove the svg: namespace prefixes).

  10. #260
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by djeyewater View Post
    Is there any issue with writing XHTML, serving as xml, then using xsl (client side) to convert to HTML?
    What's the benefit over using HTML?

    Quote Originally Posted by djeyewater View Post
    (BTW Autistic Cukoo's example works fine for me served as text/html so long as you remove the svg: namespace prefixes).
    That's because browsers use HTML5 parsers these days and HTML now supports inline SVG and MathML.
    Simon Pieters

  11. #261
    SitePoint Zealot
    Join Date
    Dec 2008
    Posts
    118
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan View Post
    What's the benefit over using HTML?
    Means the pages can be parsed as XML if needed.
    I think facebook opengraph and some other stuff also make use of xml namespaces, so are okay for XML / XHTML, but not HTML.
    Main reason though is just that my site is already coded in XHTML. The site uses some RDFa, at the time I wrote it I think RDFa support only existed for XHTML. Though I just checked now and it seems there is a working draft for RDFa support in HTML.

    What I'm not sure of really is if serving XML with an XSL that just copies the nodes but has an output type of html is any different (other than the error handling) to just serving the page as text/html.
    Quote Originally Posted by zcorpan View Post
    That's because browsers use HTML5 parsers these days and HTML now supports inline SVG and MathML.
    I didn't realise that, thanks. I don't think I'd ever use SVG personally (other than via Raphael).

  12. #262
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by djeyewater View Post
    Means the pages can be parsed as XML if needed.
    It would always be parsed as XML. And then again as HTML (in most browsers), after the transformation.

    Quote Originally Posted by djeyewater View Post
    I think facebook opengraph and some other stuff also make use of xml namespaces, so are okay for XML / XHTML, but not HTML.
    Facebook opengraph doesn't actually use XML namespaces. I would be surprised if what they do even works at all in XML.

    They use XML-looking invalid HTML and don't do any namespace processing.

    It looks like the current opengraph spec has migrated to the HTML-friendly version of RDFa, which doesn't use colons in attribute names.

    Quote Originally Posted by djeyewater View Post
    Main reason though is just that my site is already coded in XHTML. The site uses some RDFa, at the time I wrote it I think RDFa support only existed for XHTML. Though I just checked now and it seems there is a working draft for RDFa support in HTML.
    Yeah. There's also a competing spec called microdata which was specifically designed to integrate well with HTML. Schema.org went with microdata instead of RDFa.

    Quote Originally Posted by djeyewater View Post
    What I'm not sure of really is if serving XML with an XSL that just copies the nodes but has an output type of html is any different (other than the error handling) to just serving the page as text/html.
    Yes, it's different. The "html" output mode in XSLT predates HTML5. It doesn't work correctly for some things. For instance, I think inline SVG doesn't work, even though it works in normal text/html now. Script scheduling is different (in Firefox at least). You also break incremental rendering, most likely. I think browsers are not interested in "fixing" any of this, because supporting client-side XSLT was a mistake to begin with. (Browsers also aren't interested in supporting any XSLT versions other than 1.0.)

    Quote Originally Posted by djeyewater View Post
    I didn't realise that, thanks. I don't think I'd ever use SVG personally (other than via Raphael).
    Simon Pieters

  13. #263
    SitePoint Zealot
    Join Date
    Dec 2008
    Posts
    118
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Thanks for all the info! I think I will switch to XML + XSL for now then (I need to use some external js that doesn't work with XHTML), and then look at migrating the site to HTML5 (possibly with microdata instead of RDFa).

    Regarding XSL, I actually thought it was quite a good idea. In theory I think you should be able to use it as a client side templating system. So the first hit on the site would be larger as the XSL needs to be downloaded, but subsequent hits should be faster as only the actual data used in the page would need to be downloaded.

  14. #264
    SitePoint Zealot
    Join Date
    Dec 2008
    Posts
    118
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I've found one of those "things" that is different in using HTML output by XSLT now - in Google Chrome a <br /> is processed to <br><br>. Strangely it doesn't do the same things with <img /> and <input /> though.

  15. #265
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That seems like a bug, but is easy to explain:

    The output of the XSLT transform (in Chrome) is a serialization of the transformed tree, where empty elements are serialized as start tag followed by end tag. (The HTML output mode shouldn't emit end tags for HTML4 "EMPTY" elements per the XSLT spec, IIRC.) This is then parsed using the HTML parser. "</br>" is parsed as if it were "<br>" (this doesn't happen for img or input), per the HTML spec.
    Simon Pieters


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
  •