SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 33

Hybrid View

  1. #1
    SitePoint Evangelist
    Join Date
    Jun 2011
    Location
    London UK
    Posts
    495
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)

    Xhtml 1 or html 5

    After finally reaching the stage where I have accumalted enough programming knowledge ( hopefully ) to re-design my site using CSS3, I am left with only 1 challenge: Xhtml 1 or html 5.
    From all I have read, I think I understand that xhtml gives better options to optimise for Android/Iphone/small screen platforms, but can have some compatibility problems for various browsers/systems.

    Is there a concrete downside to using Xhtml? If so, what is it?

  2. #2
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,167
    Mentioned
    453 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by benbob View Post
    Is there a concrete downside to using Xhtml?
    No, there isn't. HTML5 is not really ready for use, either, as it's still in development, so best to stick with what works for now. (Mind you, there's not much advantage using XHTML over HTML4, but it's up to you.)

    By the way, CSS3 is also in development, and the few bits of it that are supported now don't work in older browsers, so use it wisely and with caution.

  3. #3
    SitePoint Evangelist
    Join Date
    Jun 2011
    Location
    London UK
    Posts
    495
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    No, there isn't. HTML5 is not really ready for use, either, as it's still in development, so best to stick with what works for now. (Mind you, there's not much advantage using XHTML over HTML4, but it's up to you.)
    By the way, CSS3 is also in development, and the few bits of it that are supported now don't work in older browsers, so use it wisely and with caution.
    Thanks Ralph,

    As there is no "real" (if there is such a thing as real) downside, I'll take the plunge and use Xhtml as the platform. I may not really use the difference, but if I do find something useful that is specifically "X", it will save me redoing the site again. This is the second time I have to do a complete overhaul, and I am getting fed up with patching up.

    I know CSS3 is not "finished", but at the speed things are developing in the web world, I doubt any platform will ever be finished and stay unchanged for more than a year.
    With regards to this, I am mainly concerned with avoiding application of coding that creates display incompatibility problems between brosers like [text decoration - blink] not being recognised by IE because people may find it irritating. (No, the irony of MS taking action to avoid people getting irritated, is not lost on me)

  4. #4
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,167
    Mentioned
    453 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by benbob View Post
    I doubt any platform will ever be finished and stay unchanged for more than a year.
    Things seem to last longer than that on the web. Anyhow, I guess the point is to use only what you really need, as you can do pretty much anything you need to with HTML4 and CSS2.

  5. #5
    SitePoint Evangelist
    Join Date
    Jun 2011
    Location
    London UK
    Posts
    495
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ralph.m View Post
    No, there isn't. HTML5 is not really ready for use, either, as it's still in development, so best to stick with what works for now. (Mind you, there's not much advantage using XHTML over HTML4, but it's up to you.)

    By the way, CSS3 is also in development, and the few bits of it that are supported now don't work in older browsers, so use it wisely and with caution.
    Quote Originally Posted by ralph.m View Post
    Things seem to last longer than that on the web. Anyhow, I guess the point is to use only what you really need, as you can do pretty much anything you need to with HTML4 and CSS2.
    That is good to know. As you know, I am far from being able to call myself an expert ( at least without lying ) and I often get the feeling things change faster than I can learn the laterst updates.
    I fully agree with your remark to only use what you need. I subsribe to the theory that "less is more" and aim to keep my site as simple as possible without looking cheap/simplistic. Apart from the actual amount of useful information given, I try to keep it as small as possible. My basic premise being that the less code there is, the lower the chance of faults/problems/poor rendering.

  6. #6
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by benbob View Post
    [...] use Xhtml as the platform. I may not really use the difference [...] it will save me redoing the site again.
    Downsides
    ---------------

    1. You should use the XHTML syntax only if you're using the XHTML features too, otherwise it just shows a poor understanding of what XHTML stands for

    2. You're just presenting the browser with a wrong syntax each and every time it receives your page, which means extra work for it and it opens the door to potentially odd and buggy behavior from its part


    And this is true for HTML5 semantics also. Even though the DTD is common for both features, you should choose one and stick with it, you shouldn't create hybrids. Clarity on intent, consistency on code.

  7. #7
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Just don't bother with XHTML, it is dead in the water. Has been for the longest time.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  8. #8
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,167
    Mentioned
    453 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by logic_earth View Post
    Just don't bother with XHTML, it is dead in the water.
    XHTML2 is dead in the water, but not XHTML, which is perfectly fine to use and will presumably be usable for many years to come. These days, even the latest version of IE upports it (wow!), but it's worth noting that it was never supported by IE8 and under, meaning that it has to be served as text/html, which means you might as well have used HTML4 all along.

  9. #9
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,260
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    Just don't bother with XHTML, it is dead in the water. Has been for the longest time.
    I agree with this. Even pages that claim to be XHTML are nonetheless served as text/html, which means as far as the browser is concerned, it's just plain old HTML, which means there's zero benefit.
    "First make it work. Then make it better."

  10. #10
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,804
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    I agree with this. Even pages that claim to be XHTML are nonetheless served as text/html, which means as far as the browser is concerned, it's just plain old HTML, which means there's zero benefit.
    That's just because there are still people using browsers such as Internet Explorer 8 that don't support XHTML. Once those browsers are dead then XHTML will be able to be used - including all of the benefits that it offers that are not available in HTML - it will actually become eXtensible as the X in the name indicates. There is no benefit UNTIL IE8 dies and it can be served as XHTML. The benefit is that it will not need to be rewritten in order to do sithat - just a change of MIME type will do it.

    If XHTML were truly dead then why is XHTML5 currently under development?
    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="^$">

  11. #11
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by benbob View Post
    I am left with only 1 challenge: Xhtml 1 or html 5.
    Many of us use HTML5 semantics today. I use HTML5 semantics. It's viable, with the same notable exception as with XHTML: legacy IE. I'd go as far as to say XHTML is worse about that.

    The thing is, all of us will use HTML5 semantics tomorrow.

    Even more, HTML5 semantics gives you the opportunity to keep coding XHTML or just plain old HTML. It's your choice.

    But XHTML is an application of XML. And XML is long dead now.

  12. #12
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by itmitică View Post
    ...And XML is long dead now.
    I don't know where you got that idea from, but XML is far from being any where near dead.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  13. #13
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    XML may be kept on life support for now because of the compatibility issues.

    But everybody agrees XML is too verbose and it's on its way out.

  14. #14
    SitePoint Evangelist
    Join Date
    Jun 2011
    Location
    London UK
    Posts
    495
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by itmitică View Post
    XML may be kept on life support for now because of the compatibility issues.
    In your previous post, you said it was dead; now you say it is not.
    Which one is it? Dead or not?
    And who are these "everybody" that know this?

  15. #15
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Who is everybody? Where is this group of everybody you speak of? I'm going to assume you mis-understand what XML is because like I said. It is far from dead, not on life support and there are no compatibility issues keeping it alive. XML is quite alive on its own.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  16. #16
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Nitpicking are we...

    XML, as technology, is quite dead.

    XML, as use, has a few breaths left. Mostly for backward compatibility in app settings, manifests. Just because some few stubborn cling on it in their newest release, doesn't make XML livelier.

  17. #17
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Uh huh...so YOU say.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  18. #18
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    OK.

    For ME, at least, XML is dead. As in no longer a prospect. No longer relevant.

    In database world, I don't want data that can break with a little missing >. In HTML world I don't markup that can break with a little missing >. In app settings world, I don't want settings that can break with a little missing >.

    It's not that I'm not for strict and rigorous, I am. But for substance, not for structure. Much less for a superfluous verbose structure.

  19. #19
    SitePoint Evangelist
    Join Date
    Jun 2011
    Location
    London UK
    Posts
    495
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    From what I understand so far reading through loads of browser discussions, most browsers contain up to 50% "error-patch-coding" to be able to read sloppy coding. As smart phones are grabbing the web market by storm, it is well advisable to make sure your code is spot on, as phone software is more limited than computer software and thus more prone to display problems.
    Writing clean code is really not that big a chore as long as you pay attention and test it. I handwrite it using wordpad and Notepad++, which makes it easy to spot typos. After that, I run it through a validator on "strict", which will pick up the remaining bit of static.
    To chose a system because it allows for sloppy coding, is a strange way to go about imho.

  20. #20
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,260
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by benbob View Post
    To chose a system because it allows for sloppy coding, is a strange way to go about imho.
    I don't think anyone here suggested HTML "because it allows for sloppy coding." We suggested HTML because, even if you use an XHTML doctype and the self-closing slashes, browsers are nonetheless parsing your code as if it were plain HTML. The XHTML is just a facade.
    "First make it work. Then make it better."

  21. #21
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    browsers are nonetheless parsing your code as if it were plain HTML
    Not even that. That code would be "HTML in quirks mode" or "HTML with errors".

  22. #22
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    As you stated yourself, a code is only as sloppy (or as clean) as you ... code it. It has nothing to do with a system.

    I'm not sure how you handwrite code in Wordpad though. For hand-coding HTML, you need a plain text editor, which Wordpad is not.

    And HTML has a strict DTD too, not just XHTML.

    Finally, you should use XHTML only if you really use it, not as a catching net for coding errors. That's wrong. And strange. And it has the reverse effect on the browser, since you obviously won't be serving it as application/xhtml+xml or application/xml.

  23. #23
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    For the past 10 years that was the line that "helped" people to serve browsers with HTML content and HTML features in a XHTML syntax and with a HTML mime, which browsers had to correct over and over again, just so that those people feel somewhat better than others.

    Which, obviously, was, and still is wrong in more that just one way.

    If you don't use it than don't serve it. If you can't serve it, than don't build it. What future may bring, that's in the future. And XHTML has been in the future for so many years, it's become a joke.


    The bottom line is, don't use XHTML syntax if you:

    - don't use XHTML features
    - can't serve it with the right mime

    XHTML syntax alone it's really not a good indicator on how well versed one is in web development. At all.


    And let me share something with you. The moment IE8 is gone and we could start building and properly sending XHTML docs, that's the moment when the life has become much harder for browser vendors.

    Because that's the exact moment when they have to implement graceful degradation for badly written XHTML docs. Since this is the moment when HTML started to get a bad name, when they had to account for any malformed web page and still render it, no matter what.

    Or do you believe HTML couldn't have been as strict as XHTML and be able to hold rendering on stupid little errors like a little missing >? Guess what, they learned pretty fast that dumb-stopping the rendering was not the solution.

  24. #24
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,804
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by itmitică View Post
    Because that's the exact moment when they have to implement graceful degradation for badly written XHTML docs. Since this is the moment when HTML started to get a bad name, when they had to account for any malformed web page and still render it, no matter what.
    I hope not - the best part of XHTML is that browsers refuse to display the page at all if there are ANY XHTML errors. Unfortunately some browsers have already b roken the rule about refusing to serve badly written XHTML.

    What's the point of XHTML if the browsers will accept any old errors the way they do with HTML - might as well stick with HTML if you want the browser to fix your errors for you.
    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="^$">

  25. #25
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    What's the point of XHTML if the browsers will accept any old errors the way they do with HTML - might as well stick with HTML if you want the browser to fix your errors for you.
    Because that's not the main feature of XHTML, syntax strictness. Like I said before, we could have had that with HTML. HTML docs could have as well break rendering upon any error, big or small, but it turns out that that's not a valid scenario in the real world. And once XHTML joins the mainstream, breaking the rendering on any errror, big or small, it won't be a valid scenario either.

    So forget about syntax, it's a small fish to fry and strictness it's something HTML could have done it itself. Most importantly, the gains of using XHTML are things like interoperability, namespaces, new elements and such. Though since SVG and MathML are available with plain HTML in HTML5 semantics, using something like a XHTML <object> for this type of integration inside a HTML document would be best, IMO.


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
  •