HTML5 or XHTML
Permalink
Hi everyone,
What specification have you adopted?
I see HTML5 going around, but it's not even
ratified yet, it's still a draft, yet many
sites are toting it around as the next best thing.
So, have you taken the plunge, are you coding in HTML5?
Are you sticking with XHTML?
Why?
What specification have you adopted?
I see HTML5 going around, but it's not even
ratified yet, it's still a draft, yet many
sites are toting it around as the next best thing.
So, have you taken the plunge, are you coding in HTML5?
Are you sticking with XHTML?
Why?
HTML5 is the future. Plain and simple. I have some themes in the marketplace that need to be updated to HTML5.
HTML5 is popular because it works well with mobile devices. It makes responsive designs easier to develop.
I now do all my client projects in HTML5. There's sooo many cool things that you can do with HTML5 that XHTML simply doesn't support. One is the Canvas element, which makes it easy to make effects that look and feel like flash.
So, in short, go with HTML5. That way, your sites will be "future proof".
HTML5 is popular because it works well with mobile devices. It makes responsive designs easier to develop.
I now do all my client projects in HTML5. There's sooo many cool things that you can do with HTML5 that XHTML simply doesn't support. One is the Canvas element, which makes it easy to make effects that look and feel like flash.
So, in short, go with HTML5. That way, your sites will be "future proof".
The HTML5 spec is targeted to be in the recommendation phase in 2-3 years I believe and the final "ready" state won't be reached in the next 10 years if we believe Ian Hickson's statement some time ago (this might be updated though...).
But the main thing is that most modern browsers already support HTML5. If you need older IE support, then you either need a JavaScript that converts the HTML5-tags into normal HTML or wrap those tags inside a div you can style for IE. Also, if you're using canvas element or some of the other new features, then you will need special care for older browsers but there are also e.g. scripts available that make canvas support for IE at least on some level.
It depends very much on your audience. I'd say go with it but then again if you're doing mass targeted sites, I'd say you'd better support IE as well.
But the main thing is that most modern browsers already support HTML5. If you need older IE support, then you either need a JavaScript that converts the HTML5-tags into normal HTML or wrap those tags inside a div you can style for IE. Also, if you're using canvas element or some of the other new features, then you will need special care for older browsers but there are also e.g. scripts available that make canvas support for IE at least on some level.
It depends very much on your audience. I'd say go with it but then again if you're doing mass targeted sites, I'd say you'd better support IE as well.
Thanks for the input guys.
Maybe I'll give it a shot.
I just hope I don't regret it later on :p
Maybe I'll give it a shot.
I just hope I don't regret it later on :p
IMHO, It doesn't really matter.
I personally use the new shorter html5 doctype, <html> tag declaration, and <meta charset="utf-8" /> tags for a cleaner start to my html code because these work in all browsers (even ones from before HTML5 was made -- e.g. old IE's). Seehttp://diveintohtml5.info/semantics.html... for details.
But I am not really using most of the new tags because they are unnecessary and confusing (and require javascript to work in IE8 and lower). I recently purchased this e-book which was somewhat enlightening on the subject and I highly recommend it:
http://www.truthabouthtml5.com/...
The first part is about how the new tags in HTML5 (<section>, <article>, <aside>, <header>, <footer>) are confusing and pointless and you should just stick to <divs>. Very convincing argument I think.
For more advanced features of HTML5 though, such as local storage, canvas, audio/video tags, then yes that can be useful. But if you're not using those features then it doesn't really matter.
At the end of the day, all that's really important is that the site looks good in the browsers you are targeting (and screen readers if you're concerned with accessibility), and that the code is maintainable for future modification. Realistically there won't be much difference in the code between HTML5 and XHTML (or HTML4).
Just my 2 cents of course.
-Jordan
I personally use the new shorter html5 doctype, <html> tag declaration, and <meta charset="utf-8" /> tags for a cleaner start to my html code because these work in all browsers (even ones from before HTML5 was made -- e.g. old IE's). Seehttp://diveintohtml5.info/semantics.html... for details.
But I am not really using most of the new tags because they are unnecessary and confusing (and require javascript to work in IE8 and lower). I recently purchased this e-book which was somewhat enlightening on the subject and I highly recommend it:
http://www.truthabouthtml5.com/...
The first part is about how the new tags in HTML5 (<section>, <article>, <aside>, <header>, <footer>) are confusing and pointless and you should just stick to <divs>. Very convincing argument I think.
For more advanced features of HTML5 though, such as local storage, canvas, audio/video tags, then yes that can be useful. But if you're not using those features then it doesn't really matter.
At the end of the day, all that's really important is that the site looks good in the browsers you are targeting (and screen readers if you're concerned with accessibility), and that the code is maintainable for future modification. Realistically there won't be much difference in the code between HTML5 and XHTML (or HTML4).
Just my 2 cents of course.
-Jordan
Jordan,
In your coding, have you ever implemented XSL, XSLT or namespaces? I need to use namespaces (to execute a mediator pattern which is intended to reduce the clutter of jQuery chaining on a complex web-app), and in order to do that the page needs to be rendered with a MIME type of application/xhtml+xml. This forces the parsing engine to render the page in XML and NOT to back off and render it as Tag Soup when it encounters any errors because that blows out the intelligence in trusting the XML is properly formatted.
As a starting point when working with C5, someone facing this issues needs to begin with a template that can - at least - be rendered in XML strict mode. I would have thought that anyone touting that a theme is "HTML5" compliant that this would be the case. Not so. Even the "HTML5Boilerplate" template cannot be rendered in XML. When setting the MIME type of the application to /xhtml+xml causes errors it eliminates all of the uptown features that the new standards for quality code is trying to accommodate AS WELL AS making the parsing of the page extremely faster than when a page is "downgraded" to the Tag Soup portion of the browser's parsing engine ("Hello Explorer") that all browsers feed poorly formatted code to.
Do you know of any template in C5 that can be rendered in XML strict mode? Do you think Concrete5 should raise the standard for those claiming to sell HTML5 compliant themes to this (XML parse-able) level?
In your coding, have you ever implemented XSL, XSLT or namespaces? I need to use namespaces (to execute a mediator pattern which is intended to reduce the clutter of jQuery chaining on a complex web-app), and in order to do that the page needs to be rendered with a MIME type of application/xhtml+xml. This forces the parsing engine to render the page in XML and NOT to back off and render it as Tag Soup when it encounters any errors because that blows out the intelligence in trusting the XML is properly formatted.
As a starting point when working with C5, someone facing this issues needs to begin with a template that can - at least - be rendered in XML strict mode. I would have thought that anyone touting that a theme is "HTML5" compliant that this would be the case. Not so. Even the "HTML5Boilerplate" template cannot be rendered in XML. When setting the MIME type of the application to /xhtml+xml causes errors it eliminates all of the uptown features that the new standards for quality code is trying to accommodate AS WELL AS making the parsing of the page extremely faster than when a page is "downgraded" to the Tag Soup portion of the browser's parsing engine ("Hello Explorer") that all browsers feed poorly formatted code to.
Do you know of any template in C5 that can be rendered in XML strict mode? Do you think Concrete5 should raise the standard for those claiming to sell HTML5 compliant themes to this (XML parse-able) level?
In a "former life" (before working with Concrete5), I have generated fairly complex XHTML documents using XSLT (these were for an email newsletter for a very large company -- sending it to over 100,000 subscribers in several different languages). My experience with that taught me that XSLT is a total waste of time and using a more imperative/procedural language (PHP, Python, C#, Ruby, VIsual Basic, whatever) to generate the markup would have been a lot easier to work with. Declarative languages are great for straightforward tasks, but converting data to HTML/XHTML often requires a lot of complicated "if/then" scenarios and other business logic. In the end, it wasn't worth the trouble to force XSLT on the situation. Just my opinion, of course -- it's possible that your use case differs significantly and maybe XSLT is a better fit. But I wouldn't ignore the more straightforward solution of just using a "normal" programming language (e.g. PHP) to generate your markup for you. Throw in a templating library (Smarty, Haml, whatever) and you're pretty much getting all the benefits of XSLT without any of the drawbacks. (Again, this is just my opinion).
As for the whole HTML5 vs. XHTML debate, I fall firmly in the Mark Pilgrim camp that basically states "XML is the wrong tool for the job of website markup", primarily due to draconian error handling which doesn't serve the end-user well. Read this section of Dive Into HTML5 for a super-short synopsis of this opinion:http://diveintohtml5.info/past.html#xhtml...
And here's another piece that conveys the same basic idea:http://tantek.com/2010/302/b1/xhtml-dead-long-live-xml-valid-html5...
There are, of course, plenty of people that disagree with that take on things. But it doesn't matter because the HTML5 contingent has won out over XHTML and the less-strict HTML5 camp is where things are heading. In fact, the XHTML 2.0 spec was abandoned by the W3C back in 2009, see:http://www.w3.org/2009/06/xhtml-faq.html...
Notice that I haven't said anything specifically about Concrete5 yet. I don't think this issue has anything to do with Concrete5, because you as the theme developer can code up your HTML markup any which way you want (XHTML, HTML4, HTML5, just a bunch of text, whatever). This is in fact on of the great things about Concrete5 -- that it doesn't impose its own idea of what your markup should be and instead lets you do it any way you want.
I don't know of any C5 templates in the marketplace that can be rendered in XML strict mode (my line of work has me building out custom-designed themes, so I've rarely used marketplace themes and hence don't know much about what's available). I think for your use case it would make the most sense to build your own theme that is XML compliant.
As for your last question about "do you think Concrete5 should raise the standard...": if it's not apparent already, I disagree with the wording of this question. While I see how strict XML might be better for your particular use case here, I certainly don't think it's a "better" standard overall for the most common use case that C5 is intended for (informational web sites, as opposed to web applications).
Hope that makes sense.
-Jordan
As for the whole HTML5 vs. XHTML debate, I fall firmly in the Mark Pilgrim camp that basically states "XML is the wrong tool for the job of website markup", primarily due to draconian error handling which doesn't serve the end-user well. Read this section of Dive Into HTML5 for a super-short synopsis of this opinion:http://diveintohtml5.info/past.html#xhtml...
And here's another piece that conveys the same basic idea:http://tantek.com/2010/302/b1/xhtml-dead-long-live-xml-valid-html5...
There are, of course, plenty of people that disagree with that take on things. But it doesn't matter because the HTML5 contingent has won out over XHTML and the less-strict HTML5 camp is where things are heading. In fact, the XHTML 2.0 spec was abandoned by the W3C back in 2009, see:http://www.w3.org/2009/06/xhtml-faq.html...
Notice that I haven't said anything specifically about Concrete5 yet. I don't think this issue has anything to do with Concrete5, because you as the theme developer can code up your HTML markup any which way you want (XHTML, HTML4, HTML5, just a bunch of text, whatever). This is in fact on of the great things about Concrete5 -- that it doesn't impose its own idea of what your markup should be and instead lets you do it any way you want.
I don't know of any C5 templates in the marketplace that can be rendered in XML strict mode (my line of work has me building out custom-designed themes, so I've rarely used marketplace themes and hence don't know much about what's available). I think for your use case it would make the most sense to build your own theme that is XML compliant.
As for your last question about "do you think Concrete5 should raise the standard...": if it's not apparent already, I disagree with the wording of this question. While I see how strict XML might be better for your particular use case here, I certainly don't think it's a "better" standard overall for the most common use case that C5 is intended for (informational web sites, as opposed to web applications).
Hope that makes sense.
-Jordan
This is a very kind, thoughtful and intelligent response. I appreciate you taking the time and I am glad I posed the questions to you. I learned a lot.
For me, it is not XSLT that is pulling me towards XML, but management of jQuery, endless chaining of $.functions and the management of attribute-handle-names. It seemed namespaces would readily provide that solution. Looking into that solution, I read about Javascript architectural design patterns in programming (http://addyosmani.com/resources/essentialjsdesignpatterns/book/... ) by Addy Osmani. Here's a short synopsis review by Larry Ullman: (http://www.larryullman.com/2012/04/06/great-javascript-resources-by-addy-osmani/). That led to a nicely written js api written by Jack Lawson (http://thejacklawson.com/Mediator.js/) that he used to control the jQuery work in a project as it became bigger.
My particular project handles a lot of data (forms/AJAX) that varies between users (due to unique user retrievals of data within an organization) and I am trying to reduce the number of clicks by building a train of javascript events based on their specific information - hence the concern of js maintenance at the beginning. I know I can do it the traditional jQuery way, I was just looking for a better approach. (I will admit, I was wondering about XSLT too, but you cured that.)
If you have some (more) advice, I am all ears. :)
btw, I can just parse the 3-4 pages I need in XML, if in fact the namespaces approach seems beneficial.
For me, it is not XSLT that is pulling me towards XML, but management of jQuery, endless chaining of $.functions and the management of attribute-handle-names. It seemed namespaces would readily provide that solution. Looking into that solution, I read about Javascript architectural design patterns in programming (http://addyosmani.com/resources/essentialjsdesignpatterns/book/... ) by Addy Osmani. Here's a short synopsis review by Larry Ullman: (http://www.larryullman.com/2012/04/06/great-javascript-resources-by-addy-osmani/). That led to a nicely written js api written by Jack Lawson (http://thejacklawson.com/Mediator.js/) that he used to control the jQuery work in a project as it became bigger.
My particular project handles a lot of data (forms/AJAX) that varies between users (due to unique user retrievals of data within an organization) and I am trying to reduce the number of clicks by building a train of javascript events based on their specific information - hence the concern of js maintenance at the beginning. I know I can do it the traditional jQuery way, I was just looking for a better approach. (I will admit, I was wondering about XSLT too, but you cured that.)
If you have some (more) advice, I am all ears. :)
btw, I can just parse the 3-4 pages I need in XML, if in fact the namespaces approach seems beneficial.
There's not really much more I could tell you in a forum post -- it sounds like you have a very complex app, I doubt anyone could give you useful advice without seeing the actual requirements, specs, use cases, etc.
A lot of people these days are flipping the old model of HTML/JS on its head, and treating the client as the application. That is, coding the entire UI of the app in Javascript itself, and treating the server basically as a data API that gives and gets JSON data to that front-end. If you look at your app this way, it then opens up the possibility to utilize a more structured framework for the app that is in Javascript itself, such as Backbone, Spine, or Ember. I believe the problem that these frameworks attempt to solve is the problem you're having (managing complexity of front-end code).
So I'd definitely look into those and see if it matches up with your project. But other than that very high-level general advice, I don't think there's anything else useful I can provide.
Best of luck,
Jordan
A lot of people these days are flipping the old model of HTML/JS on its head, and treating the client as the application. That is, coding the entire UI of the app in Javascript itself, and treating the server basically as a data API that gives and gets JSON data to that front-end. If you look at your app this way, it then opens up the possibility to utilize a more structured framework for the app that is in Javascript itself, such as Backbone, Spine, or Ember. I believe the problem that these frameworks attempt to solve is the problem you're having (managing complexity of front-end code).
So I'd definitely look into those and see if it matches up with your project. But other than that very high-level general advice, I don't think there's anything else useful I can provide.
Best of luck,
Jordan
My own experience is quite divorced from the production trenches at
this point, but for what it's worth...
...absolute commitments to standards make a lot of sense when you have
a group of folks collaborating on something together. Show me a couple
of project teams in a couple of different countries working for a
single client with deep pockets and a common goal - and the idea of
working towards any strict XMLish standard may be a brilliant solution
to a real world problem.
Remove that need to collaborate and you've got diminishing returns.
Write code that works, is nicely formatted, and thoughtfully commented
- chances are that another decent dev will be able to take the baton
if the project is ever passed along for some reason. Go the extra mile
by choosing to re-read and clean your code from the beginning from
time to time without an immediate deadline, and chances are your
solution will be perfect for the actual life it has.
But yeah. New standards and approaches are cool and all. ;)
When I had my first kid, wifey and I read a lot of parenting books.
Interestingly, they all take polar extremes on any issue. e.g: Some
say if you don't co-sleep with your baby in the grownup's bed for the
first two years, you're torturing your kid with solitude. Others say
that's akin to sexual abuse (for at least one party - you choose) and
if you don't lock your kid in their room to "cry it out" you're
raising a useless brat.
My own experience has been the truth always lies somewhere in the
middle, and tends to change too quickly to be put in any rule-set or
formula. It's hard to get media awareness around a reasoned, balanced
approach however. Spend the time to know the problem you're actually
solving and it's usually not that hard to find the right answer.
What's the required browser compatibility list?
Will the data need to be imported/exported to some type of system in
the future, perhaps?
Are there fancy-pants production tricks that need to happen?
What's the mobile strategy?
etc..
Real answers to those types of questions should dictate how bleeding
edge you get with code.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
this point, but for what it's worth...
...absolute commitments to standards make a lot of sense when you have
a group of folks collaborating on something together. Show me a couple
of project teams in a couple of different countries working for a
single client with deep pockets and a common goal - and the idea of
working towards any strict XMLish standard may be a brilliant solution
to a real world problem.
Remove that need to collaborate and you've got diminishing returns.
Write code that works, is nicely formatted, and thoughtfully commented
- chances are that another decent dev will be able to take the baton
if the project is ever passed along for some reason. Go the extra mile
by choosing to re-read and clean your code from the beginning from
time to time without an immediate deadline, and chances are your
solution will be perfect for the actual life it has.
But yeah. New standards and approaches are cool and all. ;)
When I had my first kid, wifey and I read a lot of parenting books.
Interestingly, they all take polar extremes on any issue. e.g: Some
say if you don't co-sleep with your baby in the grownup's bed for the
first two years, you're torturing your kid with solitude. Others say
that's akin to sexual abuse (for at least one party - you choose) and
if you don't lock your kid in their room to "cry it out" you're
raising a useless brat.
My own experience has been the truth always lies somewhere in the
middle, and tends to change too quickly to be put in any rule-set or
formula. It's hard to get media awareness around a reasoned, balanced
approach however. Spend the time to know the problem you're actually
solving and it's usually not that hard to find the right answer.
What's the required browser compatibility list?
Will the data need to be imported/exported to some type of system in
the future, perhaps?
Are there fancy-pants production tricks that need to happen?
What's the mobile strategy?
etc..
Real answers to those types of questions should dictate how bleeding
edge you get with code.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
Thanks Franz (I always enjoy hearing your point of view).
It seems the main purpose of a Javascript framework is to organize/maintain the inevitable spaghetti code that oozes out under the weight of complexity. So "classes" are created to bind the logic and display. And to build such a framework would dictate you do it for the widest audience, which is proven to be HTML5 (at best), certainly not XHTML - unless you're gunning for marketshare of the smallest segment possible (and I know that would irk your CEO ire).
With Concrete5 I can perform wonderful (and various) combinations of displays and forms for any custom attribute type I can imagine. I need to introduce another framework to handle AJAX calls through their controllers and display using their views just so I can enjoy some javascript structure? For that I've got to learn another set of nomenclature and hand over the controls when I've already got the power? What I need is the maintenance of Javascript code, to make it orderly, structured, maintainable and extendable. The other stuff seems like duplication.
It's just me, no big-buck-backed enterprise. So the do-what-I-want wherewithal is feasible, but it's more about time and the point of diminished returns when it comes to my intellectual ability to stay pace with ever-evolving "frameworks." So, if "marketshare" is not an issue (because I am not selling in your marketplace) and C5 enables me to have all but an ability to manage my JS structure in a complex web app... then why not use xhtml technology if it can provide the missing link?
A document rendered as strict XML maintains it's "intelligence;" namely, namespaces. A lightweight Pub/Sub javascript api (Mediator; by Jack Lawson:http://thejacklawson.com/2011/06/mediators-for-modularized-asynchro... performs this along the namespace tree - called "channels." It has a few other features. Not much. Not a framework. But enough, and I can do the rest with C5.
I am considering whether that (XHTML, namespaces and implementing a Javascript mediator pattern using Mediator.js) completely solves my need for javascript code maintainability and structure in a complex web app design. And whether it keeps my intellectual prowess focused on using a tool (C5) that has proven sufficient and not lose time and energy into something (another JS Framework) that offers no significant ROI, comparatively speaking.
Rick
It seems the main purpose of a Javascript framework is to organize/maintain the inevitable spaghetti code that oozes out under the weight of complexity. So "classes" are created to bind the logic and display. And to build such a framework would dictate you do it for the widest audience, which is proven to be HTML5 (at best), certainly not XHTML - unless you're gunning for marketshare of the smallest segment possible (and I know that would irk your CEO ire).
With Concrete5 I can perform wonderful (and various) combinations of displays and forms for any custom attribute type I can imagine. I need to introduce another framework to handle AJAX calls through their controllers and display using their views just so I can enjoy some javascript structure? For that I've got to learn another set of nomenclature and hand over the controls when I've already got the power? What I need is the maintenance of Javascript code, to make it orderly, structured, maintainable and extendable. The other stuff seems like duplication.
It's just me, no big-buck-backed enterprise. So the do-what-I-want wherewithal is feasible, but it's more about time and the point of diminished returns when it comes to my intellectual ability to stay pace with ever-evolving "frameworks." So, if "marketshare" is not an issue (because I am not selling in your marketplace) and C5 enables me to have all but an ability to manage my JS structure in a complex web app... then why not use xhtml technology if it can provide the missing link?
A document rendered as strict XML maintains it's "intelligence;" namely, namespaces. A lightweight Pub/Sub javascript api (Mediator; by Jack Lawson:http://thejacklawson.com/2011/06/mediators-for-modularized-asynchro... performs this along the namespace tree - called "channels." It has a few other features. Not much. Not a framework. But enough, and I can do the rest with C5.
I am considering whether that (XHTML, namespaces and implementing a Javascript mediator pattern using Mediator.js) completely solves my need for javascript code maintainability and structure in a complex web app design. And whether it keeps my intellectual prowess focused on using a tool (C5) that has proven sufficient and not lose time and energy into something (another JS Framework) that offers no significant ROI, comparatively speaking.
Rick
Is that correct?