As the title states in response to #963832: Decide how to use HTML5 in Drupal 8. Lets draw up the battle plan.

Comments

Jeff Burnz’s picture

Issue tags: -html5, -Front end

For those coming into this issue please refer in the first instance to the HTML5 Initiative handbook pages - http://drupal.org/community-initiatives/drupal-core/html5

That is where the main plan now resides, this issue should probably be closed as a duplicate to the handbook pages.

scor’s picture

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.

mgifford’s picture

I'd add documentation & accessibility testing to this.

Like with the Git upgrade, it's going to mean a lot of changed documentation.

There's going to have to be a lot of review about how AT works with this markup. What the standards do vs how the tech implements it......

Thanks Jeff!

Jeff Burnz’s picture

Issue tags: +markupmarines, +html5

@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.

Mark Trapp’s picture

Tagging.

Jeff Burnz’s picture

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.

mgifford’s picture

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.

Jeff Burnz’s picture

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.

mgifford’s picture

I hope that @jensimmons' talk is recorded so you can watch it Jeff. She did a great job earlier today in the core stream.

I think it was Jeremy who suggested beginning with relatively easy engineering pieces like the form elements. That should be relatively straight forward compared to many of the semantic issues.

Jeff Burnz’s picture

Sure I'll try to catch it if its been recorded, if you mean Jeremy Keith I'm going to attend one of his workshops later this year, so should be a good chance to talk about D8 HTML5.

Surely the FAPI stuff must be low hanging fruit, so yes that has to be a focus.

Dave Reid’s picture

I've opened up a core sandbox for the HTML5 initiative at http://drupal.org/sandbox/davereid/1086890 and already have the HTML5 elements merged in.

Jeff Burnz’s picture

@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.

Dave Reid’s picture

@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.

Jeff Burnz’s picture

@Dave Reid - ok, I'll take commit access.

Perhaps we can go through the candidates for conversion and distill a list of likely candidates.

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

http://api.drupal.org/api/drupal/modules--system--theme.api.php/group/th... holds a list of theme_functions, many of these have nothing to do with a template and need review, some might disappear in D8 or be significantly re-factored (e.g. theme_breadcrumb), there may many instances where nothing will change, for example does it make sense to change something like theme_exposed_filters? Maybe, maybe not (just as an example).

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.

Jeff Burnz’s picture

git clone --branch 8.x http://git.drupal.org/project/drupal.git

Woot! Sorry, off topic, couldn't help it.

jpsoto’s picture

I suggest to include other "guiding principle": to explore the new HTML5's APIs; particularly off-line application cache, client-side data storage.
http://ofps.oreilly.com/titles/9780596805784/ch05.html
http://ofps.oreilly.com/titles/9780596805784/ch06.html
http://interfacethis.com/2011/is-html5-ready-for-prime-time-vs-native/

A long-term goal could be Drupal web apps supporting off-line operation (i.e. mainly oriented to the mobile ecosystem).

A colateral thought, regarding of mobile web apps, is jquery (80K); including ballasts as IE tricks. D8 should increase flexibilty to dynamically select JS frameworks. What's about jquery-compatible syntax frameworks (as ZeptoJs), twenty times lighter?
http://zeptojs.com/

bowersox’s picture

sub

Mark Trapp’s picture

#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.

Jeff Burnz’s picture

@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.

alanburke’s picture

Subscribe

johndp’s picture

subscribe

Jeff Burnz’s picture

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.

Jeff Burnz’s picture

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.

adellefrank’s picture

subscribing

rvilar’s picture

subscribing

sun’s picture

seutje’s picture

I hate just writing "subscribing" :(

hansyg’s picture

subs

Jacine’s picture

Issue tags: -markupmarines +Front end

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 :)

lpalgarvio’s picture

Issue tags: +html5, +Front end

sub

some reading,
HTML5 vs XHTML5
HTML vs XHTML

i grew up on HTML4.x but then quickly changed to XHTML1.x ;)

Jeff Burnz’s picture

Since http://drupal.org/community-initiatives/drupal-core/html5 is the main resource perhaps we should close this issue?

Jacine’s picture

Status: Active » Closed (duplicate)

Yeah, I think that's probably best.