I think we will have to choose here, I don't think it'll be easy to make a cms that can handle both at the same time. See http://xhtml.com/en/future/x-html-5-versus-xhtml-2/ for a comparison. I think supporting XHTML2 will require major changes.
The biggest problem is the different heading/section approaches of the two standards, where HTML5 is backwards compatible and and XHTML2 uses the newer and what I think to be, better structure.
So which is the way to go?

EDIT: I made a mistake when I read the text, numbered headings are supported in XHTML2, but I'd still want to use the new way.

Subscribe...

Seems like I have to bump this thread up a bit...

I got an idea for a XHTML 2.0 heading system: Make a document outline tree with drag and drop support for repositioning sections and changing level. Alternatively it could be made into a DOM Inspector like tree showing images and embedded flash objects as right-clickable items for edit-menus.

Silverstripe (the company) is developing new projects on HTML 4.01 Strict, and moving away from XHTML 1.0 Transitional. So we tend to put our money on HTML 5, but I don't see the necessity to rush any silverstripe implementations, the standard is still early draft stage - we have more immediate problems to attend to.

As an owner of a web development company I think this issue is very important. As I only provide compliant websites to my client's and have been hoping to do this exclusively via the SS framework / cms system, the future direction of whether SS goes HTML5 or XHTML2.0 is an important one for me.
I accept that the time to make a final decision is probably some time away, however I for one would like to be kept informed of the intentions of SS (the company).

Could we have some arguments 'for & against' both standards please?

I have learned from ex colleagues within MS & Adobe, that there is significant & major development of future WEB 2.0 technologies that are based around the pending XHTML 2.0 standard and that the majority will not be compliant for deployment within HTML 5.0.
I must admit that I have not looked at the HTML 5.0 implications, but if only for the reasons I give above I suggest more comment / argument on this subject.

Secondly: If SS (the company) is of a mind to move away from XHTML 1.0 Transitional towards HTML 4.01 Strict then could you please declare such A.S.A.P as future technologies relying on XML and other extensibility factors for data & other transfers are important in my own companies future and I would rather know now as opposed to spending the next 12-24 months of my time developing web applications around SS then having to throw them in the bin.

Regards

Jonathan

While I am eating this slice of humble pie!! Let me update this post with something that I have just been told: You can feed XML data etc within HTML 5.0, it would appear that you just have to alter the namespace to a compliant w3c xml one.

Second slice of pie!!: While such as XForms within XHTML 2.0 may be cool, WForms 2.0 will eventually be part of HTML 5.0.

Last piece of pie!!!: HTML 5.0 has been specified to make such as Forums, e-commerce etc easier to implement.

Jonathan

These are all valid points. The main advantage of XHTML 2 is that it is truly xml based and supports multiple namespaces, for example you could create a page containing both XHTML (as the base markup language) and embedd SVG images as well as using MathML for your mathematical formulas. I don't think that is possible by using HTML 5.

See http://xhtml.com/en/future/x-html-5-versus-xhtml-2/ for one persons view of the matter.

Personally I would prefer XHTML 2 over HTML 5.

EDIT: I think HTML 5 might include some support for MathML, but by using its own element names.
EDIT2: I just noticed that I posted the same link twice in this thread. Sorry about that.

thanks for getting the discussion going, jonathan and saimo.

keep in mind, silverstripe the company does commercial client-work, so using HTML 4.01 in these projects does not necessarily impact the way silverstripe the product goes. silverstripe cms can handle both standards just fine from a templating perspective.

generally we're trying to make a product thats output agnostic to a certain extent, you're just modifying chunks of content that could be output as json, xml, html or xhtml (hence we have a RESTful interface in development). markup thats produced by the core or modules is a sticky point, as it will have to decide for one standard (e.g. how to render navigational menus). this is especially tricky when the markup-producer doesn't control the output format (e.g. a HTML5-gallery inside a XHTML2 template). its gonna be interesting to see how other products deal with this disparity.