SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 70 of 70
  1. #51
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For instance, if you style the TBODY element but don't have the <tbody> or </tbody> tags in the markup then the rendering will differ depending on whether you serve it as text/html or XML.
    HTML Code:
    <table>
     <tr><td>foo</td></tr>
    </table>
    Code:
    tbody { background:lime; }
    Simon Pieters

  2. #52
    CSS & JS/DOM Adept bronze trophy
    Join Date
    Mar 2005
    Location
    USA
    Posts
    5,482
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ah. That makes sense. Thanks, Simon.
    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.

  3. #53
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @zcorpan: Thanks for covering those replies.

    Quote Originally Posted by Ferrarislave
    Approximetly how long have you been doing xhtml/css?
    I first started using HTML 1993/94 (can't remember exactly). Just for personal use, mind you. Back in those days there were no ways to style your content at all, which is why the structuralist view comes rather naturally to me.

    I was late to jump on the CSS bandwagon, since I believed for a long time that rendering and styling should be left to the user agent. Can you tell I'm not into marketing? So it wasn't until 2000 that I started using CSS.

    I first played with 'XHTML' (served as text/html, of course) in 2001, I think. A year later I read Hixie's article and realised how foolish this whole thing was. I then got into the whole content negotiation thing ...

    Now I'm trying to make others understand the fundamental differences between HTML and XHTML. Some accuse me of being 'anti' XHTML, which is not true. Using XHTML would be great, if only it worked.
    Birnam wood is come to Dunsinane

  4. #54
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    159
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo
    Now I'm trying to make others understand the fundamental differences between HTML and XHTML. Some accuse me of being 'anti' XHTML, which is not true. Using XHTML would be great, if only it worked.
    Why are there so many books that tell us we should be using xhtml, and why is there this big "standards compliance" movement (Jeffrey Zeldman, Jeremy Keith et al) that insists we should be using xhtml/ css, if it "doesn't work"? What is the argument for using xhtml as opposed to html 4.01?

    I've come across the arguments against using xhtml before, but what's your take on what we should be doing?

  5. #55
    Non-Member
    Join Date
    Jan 2006
    Location
    Chicago, Illinois
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Enoch Root
    Why are there so many books that tell us we should be using xhtml, and why is there this big "standards compliance" movement (Jeffrey Zeldman, Jeremy Keith et al) that insists we should be using xhtml/ css, if it "doesn't work"? What is the argument for using xhtml as opposed to html 4.01?

    I've come across the arguments against using xhtml before, but what's your take on what we should be doing?
    He answers that question more then once in this thread. It is OK to use XHTML; however, it is of no benefit to you at the moment if you serve it as text/html. The only benefit you might possibly have in the future is if you serve your pages as true XHTML. Currently the only differences between HTML 4.01 Strict and XHTML 1.0 Strict are the closing tags. I perfer the syntax, and im used to it, so I stick to XHTML. It is not technically "correct", but I still do it because there is no harm in it.

    Once again, thanks to Tommy for explaining the topic so indepth. I truely didn't understand any of it prior to read this topic. Kudos!

  6. #56
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    159
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up

    Quote Originally Posted by Ferrarislave
    He answers that question more then once in this thread. It is OK to use XHTML; however, it is of no benefit to you at the moment if you serve it as text/html. The only benefit you might possibly have in the future is if you serve your pages as true XHTML. Currently the only differences between HTML 4.01 Strict and XHTML 1.0 Strict are the closing tags. I perfer the syntax, and im used to it, so I stick to XHTML. It is not technically "correct", but I still do it because there is no harm in it.

    Once again, thanks to Tommy for explaining the topic so indepth. I truely didn't understand any of it prior to read this topic. Kudos!
    Yes, it's threads like these that make one realise how much one still doesn't know.

  7. #57
    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 Enoch Root
    Why are there so many books that tell us we should be using xhtml
    I can think of two answers to that question:
    1. Those authors aren't fully aware of the differences between XHTML and HTML, but believe the former to be a newer and cooler version of the latter.
    2. I have missed some important detail that actually makes XHTML (served as text/html) better than HTML.


    Quote Originally Posted by Enoch Root
    and why is there this big "standards compliance" movement (Jeffrey Zeldman, Jeremy Keith et al) that insists we should be using xhtml/ css, if it "doesn't work"?
    I don't know if Jeffrey Zeldman still advocates XHTML indiscriminately. When he wrote Designing With Web Standards, XHTML was all the rage and the harsh reality had not yet been exposed.

    I'm not sure Zeldman/Keith insist on XHTML. A web standards evangelist would rather advocate semantic markup separated from presentation and behaviour. Strict/Transitional then becomes a much more important issue than HTML/XHTML.

    Quote Originally Posted by Enoch Root
    What is the argument for using xhtml as opposed to html 4.01?
    You're asking the wrong guy here, remember?

    XHTML proponents like to emphasise that well-formed XML-based markup makes the document's contents easier to use with tools other than browsers. That is true. The question is how often this is useful, but it's an undeniable advantage of XHTML. It presumes, however, that the XHTML is served as an application of XML; if it's served as text/html, user agents must parse and interpret it as HTML.

    XHTML proponents also say that XHTML is superior to HTML because it allows CDATA sections and inclusion of elements from other XML namespaces. That is also true but, again, requires the document to be served with an XML MIME type.

    Another common argument is that XHTML is more 'future-proof' than HTML. The difference, if there is one at all, is negligible provided that you write your HTML in a good way (i.e., as similar to XHTML as possible). XHTML2 is not going to be backwards compatible with XHTML1. That means you'll probably need to rewrite XHTML1 documents as well as HTML4 documents in order to convert them to XHTML2.

    Other 'advantages' one often hears are that XHTML is more strict or more semantic than HTML (not true; they are identical in that respect); that CSS can only be used with XHTML (certainly not true); that XHTML – even when served as text/html – is rendered more quickly than HTML (not true; actually the opposite since XHTML UAs don't use incremental rendering as of yet); and that mobile phone browsers can only handle XHTML (not true, since that would limit the 'Web' to a few thousand pages for those users).

    Quote Originally Posted by Ferrarislave
    Once again, thanks to Tommy for explaining the topic so indepth. I truely didn't understand any of it prior to read this topic. Kudos!
    You're welcome!
    Birnam wood is come to Dunsinane

  8. #58
    Pedantic Semantic blain's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    528
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ferrarislave
    It is not technically "correct", but I still do it because there is no harm in it.
    XHTML served as text/html can be harmful, see link

    Sending XHTML as text/html Considered Harmful
    Technology is dominated by two types of people:
    those who understand what they do not manage,
    and those who manage what they do not understand.

  9. #59
    SitePoint Wizard bronze trophy Tyssen's Avatar
    Join Date
    Oct 2005
    Location
    Brisbane, QLD
    Posts
    4,067
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmmm, I was just going to say that probably the main advantage of the current popularity of XHTML is that it is leading more and more people to look into standards-driven coding, but Ian Hicks' article seems to suggest that it is actually leading people into potentially troubled waters because they're dealing with things they don't fully understand.
    I'm not sure which I think is worse - people still old school coding with no doctypes and combining content and presentation or people making an effort to learn semantic coding but using incorrect doc/mimetypes.

  10. #60
    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 Tyssen
    I'm not sure which I think is worse - people still old school coding with no doctypes and combining content and presentation or people making an effort to learn semantic coding but using incorrect doc/mimetypes.
    If their only 'mistake' is using the 'wrong' MIME type, there's neither harm nor foul in my opinion. Only a bit of ignorance.

    But people who use an XHTML doctype declaration with uppercase element type selectors in their CSS, or use document.write() to generate parts of the page, or use .innerHTML in their scripts ... those are the ones who have harmful behaviour. For themselves, and perhaps for others as well. In other words, people who rely on HTML-only features and still believe they're using XHTML. That's what Hixie means by 'harmful'.

    Especially when they also boast an 'Valid XHTML 1.0 Strict' icon on their site.
    Birnam wood is come to Dunsinane

  11. #61
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    159
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Tommy - I guess I don't know quite as much as I thought I did - or to put it more accurately, I knew a lot of this but hadn't totally understood it. Is there a book you'd recommend that covers this area - I feel as a webmaster I ought to understand this as fully as possible - but I don't want to keep bugging you about it

  12. #62
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I haven't seen any book that explains this (but that doesn't mean that there aren't any).
    Feel free to 'keep bugging' me.
    Birnam wood is come to Dunsinane

  13. #63
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    159
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo
    I haven't seen any book that explains this (but that doesn't mean that there aren't any).
    Feel free to 'keep bugging' me.
    Ok


    What are the benefits of serving XHTML with the correct mime type?
    How is it actually done?

    If you've answered this before, can you ref. the thread and I'll read it.

  14. #64
    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 Enoch Root
    What are the benefits of serving XHTML with the correct mime type?
    The benefit is that it will actually be recognised as XHTML by user agents that support it.

    You'll be able to use CDATA sections within your markup; mix in MathML, SVG, or elements from other XML namespaces; and you can link your style sheets through PIs instead of <link/> tags.

    Quote Originally Posted by Enoch Root
    How is it actually done?
    Your web server must send the proper HTTP headers. It cannot be done with markup within the document or with client-side scripting, because the user agent needs to know the content type before starting to parse the document.

    You can make your web server send the right Content-Type header, but how you do that depends what server you're using. In Apache, you can set the application/xhtml+xml MIME type for files with a '.xhtml' or '.xht' extension by the following directive (in a .htaccess file or in /etc/httpd.conf):
    Code:
    AddType application/xhtml+xml .xhtml .xht
    You can also use server-side scripting to send the right header, like the header() function in PHP.

    If you observe certain constraints when writing your markup, you can use content negotiation to serve XHTML as application/xhtml+xml to user agents that support that, and HTML to others. I've written a short article about content negotiation with PHP that may be of interest. If you can do this, though, you may just as well use HTML 4.01 Strict, because you can't use any of the 'benefits' of XHTML anyway.
    Birnam wood is come to Dunsinane

  15. #65
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    159
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Good morning Tommy

    Ok, I've been doing some reading overnight. The way I read it it, XHTML should be served as application/xhtml+xml, but can be served as text/html, as long as certain backward-compatibility rules are followed. (I guess at the moment I am serving it as text/html, sometimes without following those rules. I knew about some of the rules but didn't realise they were connected with this issue). I can see that this is not technically correct - but it works, and is less complicated than the alternatives. But I should at least make sure my colleagues and I are sticking to those backward-compatibility rules!

    Reading the article on the Wasp site - http://www.webstandards.org/learn/ar...skw3c/sep2003/
    The benefits of serving as application/xhtml+xml are a bit vague - "browsers will handle code more efficiently", "fast track rendering" etc. Also you mention "it will actually be recognised as XHTML by user agents that support it". I'm tempted to ask, "so what?". Currently it is recognised as html, and it works for everyone. But here I can see your point - we might just as well write HTML 4.01 and not have to worry about these issues! I also know that in order to persuade people we should be serving as application/xhtml+xml, I'd need more concrete arguments. Managers will see that the existing set up works, and will not be worried about such details. Developers will have to change the way they write css (and some of them are still using table based layouts and old school javascript stuff). I have enough trouble at the moment trying to convince reasonably standards-savvy developers that footers ought to be placed at the bottom of a page!

    I guess it boils down to three alternatives:
    1. Use HTML 4.01
    2. Use XHTML, served as text/html, using compatibility rules
    3. Use content negotiation to serve as xhtml+xml to decent browsers and text/html to IE

    Realistically I can see what will happen. People will see that serving XHTML as text/html works. They won't see the advantages of serving as xhtml+xml, and they will see HTML 4.01 as a backward step. The middle compromise, I agree seems wrong, and isn't really "standards compliant". Maybe it's nevertheless the most pragmatic choice?

    Re: content negotiation. For corporate reasons I am using Microsoft solutions, so it's currently .asp moving toward .net, and IIS5.

  16. #66
    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 Enoch Root
    The way I read it it, XHTML should be served as application/xhtml+xml, but can be served as text/html, as long as certain backward-compatibility rules are followed.
    Yes. The reason for these 'compatibility' rules is that when served as text/html the document is HTML to all intents and purposes. Thus it must be possible to parse and interpret as HTML, which means that you can't do anything like this:
    HTML Code:
    <script type="application/javascript" src="x.js"/>
    (Although it's perfectly valid XHTML, it will ruin the page completely when interpreted as HTML, because the parser will be looking for a non-existing </script> end tag.)

    Another way to phrase the MIME type issue is this: "If you want to use any XML features of XHTML, it must be served as application/xhtml+xml, application/xml or text/xml."

    Quote Originally Posted by Enoch Root
    The benefits of serving as application/xhtml+xml are a bit vague - "browsers will handle code more efficiently", "fast track rendering" etc.
    That's indeed vague, and not particularly correct either. An XML parser can be marginally faster than an SGML parser, but to say that it 'will handle code more efficiently' is not really true. And the speed difference should be negligible for any reasonably sized document. The download speed is likely to be much more of a bottleneck in any case.

    The 'fast track rendering' is also incorrect. With contemporary browsers it's rather the opposite. All HTML parser/rendering engines support incremental rendering, i.e., that the elements are rendered as soon as the browser has read it. But no browser currently supports incremental rendering for X(HT)ML, AFAIK. That means that the entire document must be downloaded and parsed before rendering starts. The total time (download+parse+render) is about the same (maybe a hair faster for XHTML), but the perceived speed is better for HTML, because something happens sooner on the screen. Again, the differences are probably not detectable for 'normal' pages.

    Quote Originally Posted by Enoch Root
    Also you mention "it will actually be recognised as XHTML by user agents that support it". I'm tempted to ask, "so what?". Currently it is recognised as html, and it works for everyone.
    Certainly. But you cannot use any features that XHTML has but HTML doesn't. You cannot use CDATA sections. You cannot include MathML, SVG, ... You will have to use a validator to find well-formedness errors, because user agents apply HTML rules when parsing and will do the best they can if elements are incorrectly nested (an XML parser must abort).

    If all you need is that it 'works for everyone', HTML 4.01 Strict is probably the doctype you should use.

    Quote Originally Posted by Enoch Root
    I also know that in order to persuade people we should be serving as application/xhtml+xml, I'd need more concrete arguments.
    I doubt that there are any. Personally, I'd feel foolish relying on parser bugs (to avoid sprinkled slashes about the page), but I realise that few others care about such things.

    And there's no harm in using XHTML-P ('P' for 'pretend', my tongue-in-cheek name for XHTML-as-text/html), as long as you also make sure that it still works when served with the 'proper' MIME type. This is often overlooked (or, more likely, unknown by the authors). An 'XHTML' document that doesn't work when processed as XHTML is 'harmful' IMHO.

    This is not mentioned explicitly in the XHTML 1.0 specification, which is a shame. The spec authors probably thought it was self-evident, but it apparently isn't.

    Quote Originally Posted by Enoch Root
    and they will see HTML 4.01 as a backward step.
    Which is rather ironic, since that's what they're using (as far as browsers are concerned).

    Quote Originally Posted by Enoch Root
    Re: content negotiation. For corporate reasons I am using Microsoft solutions, so it's currently .asp moving toward .net, and IIS5.
    My script can easily be ported to ASP. I don't know .NET, but I'd be surprised if it weren't possible there, too. OTOH, for obvious reasons Microsoft are probably a bit reluctant to shine too much light on that whole MIME type issue.
    Birnam wood is come to Dunsinane

  17. #67
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo
    All HTML parser/rendering engines support incremental rendering, i.e., that the elements are rendered as soon as the browser has read it. But no browser currently supports incremental rendering for X(HT)ML, AFAIK.
    Opera 9 supports incremental rendering for XML, and Henri Sivonen is currently working on it for Gecko.
    Simon Pieters

  18. #68
    SitePoint Zealot
    Join Date
    Sep 2005
    Posts
    159
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is all very interesting. If nothing else it serves as a heads up; prior to yesterday I would have expected my sites to work if served as application/xhtml+xml. Now I am at least aware that they probably won't, and can take steps to make sure nothing nasty happens in the future. I will pass this on to colleagues as well. Now each time I write a site using XHTML-P , I will feel like I am doing something I shouldn't (like smoking in the toilets, or spending someone else's money).

    Thanks for your patient and detailed replies, Tommy.

  19. #69
    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 zcorpan
    Opera 9 supports incremental rendering for XML, and Henri Sivonen is currently working on it for Gecko.
    Well ... Opera 9 is still in beta and if Henri is still working on it, then my statement is still correct ... technically.
    Birnam wood is come to Dunsinane

  20. #70
    SitePoint Addict RamsayX's Avatar
    Join Date
    Oct 2003
    Location
    Canada
    Posts
    324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think this thread should be stickied, for all us XHTML-P'ers out there
    Personal Portfolio
    Paul O'B is the CSS god


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
  •