RDFa 1.1 should be ready by the time D8 comes out. The RDFa Core 1.1 Last Call Working Draft was published in Oct last year as planned in the RDFa WG charter, so if all goes well, we should have the RDFa 1.1 Rec published this year.

@scor - great news, so, at least provisionally, could we say from the RDFa perspective its a green light for HTML5 in D8?

@mike, yes for sure, I can see this (accessibility reviews and testing) being interwoven into each issue, with issues converting to documentation post commit. I think we'll need a bigger testing team in D8 than D7, something we'll need to start thinking about very shortly.

Yesterday in Dries keynote he talked about mobile and interoperability, the points surrounding that discussion are exactly what I am talking about in 3. Make Drupal 8 markup agnostic, this is what we need to do first.

Ok, but how do we do that? Are there other examples we can draw on? It's also going to make it more difficult to search for & resolve problems that come up if everything is abstracted that extra step on the theme layer.

Agree that it's a great goal. Just not sure how to implement it and know the ramifications.

First step could be just getting the hard coded stuff out - so functions that are not themeable that have hard coded markup need to call theme functions, at the very least this makes it possible to be agnostic (in the theme layer) because then ALL markup is overridable. Thank-fully there does not appear to be much of this.

@Dave Reid - I updated the battle plan to point to the sandbox, looks like this first one is all form elements stuff, you want to use that for core html like templates or can we set up another branch?

sun has a module called markup_test in his sandbox, perhaps we could use this to test the new elements, I can't find it in the new git repo, I only have an old version I pulled out of CVS some time ago.

@Jeff Burnz - just let me know who needs commit access to it and I'll add them so they can create they're own part branches, we also probably need to figure out how we want to chunk this up to fit into the initiative. Along with adding the new FAPI elements it would probably make sense to add to that the usage of those elements in core's form API functions.

For starters if we look at the templates in Drupal core we should able to par this down to a set likely candidates for HTML5 - clearly some of these do not need to change, some have very minor changes and some will take major overhauls.

Mostly these can grouped by module, which I think could make sense. My original plan was to open an issue per module and work on any templates, theme_functions, preprocess and process functions etc for that module. So take an overview of all the markup for that module - for example Aggregator module, decide what needs to change/what doesn't then write a patch. This call all be done in the sandbox

So we need to distill a list of likely candidates from that list that could change, and list them in order of importance (things will big changes are important, things with minor or no changes are least important).

There are other things we could start attacking such as contextual links (e.g. <menu type="context">), so potential candidates for conversion need to be identified, listed and worked trough in due course. I don't have a plan of attack for these cases.

So as a first suggestion:

1. Figure out which templates are likely candidates.
2. List them out with the functions that pertain to them.
3. Do the conversion for each module in one hit.
4. Breakdown the list of theme_functions, filter out the ones that pertain to a module directly (already covered in 1-3), list which ones will change in order of importance.
4. Tick these off our list as we go.

As for git well, it seems excessive to have a branch for each module, so maybe we just need one branch for all of this?

Does this makes sense? Can we do this better? Certainly I am all ears.

#16 I think offline storage/cache manifests are great progressive enhancements and I definitely think we should be heading that direction.

We were discussing something similar allowing library selection in #1077878: Add HTML5shiv to core: in keeping with the idea that Drupal should be output agnostic, we should consider getting rid of the idea that every javascript library that core themes need must to be in core; that some frameworks or libraries should be up to the theme to include.

Regarding a replaceable jQuery, I had a thought: if we take the idea that Drupal's HTML output should be abstracted to keep with the idea that Drupal should be output agnostic, there might be a new construct, output engine. So, there'd be an HTML output engine, a JSON output engine, etc.

Drupal using HTML might rely on jQuery so heavily that it's a good idea it stays in core as part of the HTML output engine, but it could be removed from say, misc/. That way, contrib could create a new output engine that's mostly identical to core's HTML output engine but uses a framework other than jQuery instead.

@16/18 - ok I have updated the GP, we should most certainly looking at these other API's in particular for the mobile ecosystem, clearly legacy browser support dies in for these API's but in the mobile space support is good and getting better.

Added a new discussion #1094324: Add new theme_functions for consistency - Discussion, this is going to relevant to HTML5 so we can globally override all markup much more easily, for example to switch aggregator to consistent use of <time> element we need to override a bunch of templates, would be much better to override just one theme function - this is a simple abstraction and we need to look at doing this more in D8 core.

FYI - as a proof of concept I make a simple theme that uses polyfil markup instead of the shiv: http://drupal.org/sandbox/jmburnz/1096046 I couldn't find anything like this around as a good example (a few tidbits here and there) so I made my own.

FYI, there is no official battle plan yet, and I'm pretty sure that document is going to live elsewhere, so I'm tempted to mark this closed. However, we're having a meeting on Tuesday to discuss this in IRC. Please join us if you're interested in helping out: http://groups.drupal.org/node/151294 :)