DrupalCon Core Conversation: HTML5 + Drupal 8

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
jensimmons's picture

I've been having a lot of conversations about HTML5 and Drupal 8 this week while in Chicago — both with people here and with people back in New York. And the Core Conversation proposal deadline is coming up soon!

This is what I'm thinking. Let's present a real-world "This Is What We Think Should Be Done". As a call-to-action, where people can get involved and there are leaders driving each thing.

I'm thinking of submitting this proposal. And present as a team, team-tag style (one person do each section):

  1. Open with a 5 min overview to propose our roadmap to getting HTML5 into Drupal 8.
  2. Do 10 mins on Field API & how Drupal needs to change ASAP to support the HTML5 Form API.
  3. Do 5 mins on theme mark-up: how the core tpls need to change. And the doctype.
  4. Do 5 mins on the baked-into-core hardcoded HTML like $submitted, $styles / $scripts, menu markup, and whatever else is a PITA. (There's no time to go into detail. More like just present a hit list of Stuff That Needs To Get Done.)
  5. 5 min: Open the question of getting something like Semantic CCK into core. What might the process be for a site builder to create an entity, and specify the default markup for each field. We'll need time to figure something out / design the UI. But we should make this a sub-project.
  6. Quickly, that there might be something cool to do with web workers, offline storage, communication apis, web sockets, web storage. Or if we have ideas of what those things might be, present those.
  7. What else?

Clearly, there's barely any time in 30 mins. But we can use this opportunity to set out a clear road map, and a call to action. Then in the second half of the session, we breakout and people start getting involved, and start writing patches... and through the week.... keep going. Or people who don't get involved directly, they understand what's going on, and how to use the D7 modules to do many of these things now.

I'd like people to leave with a sense that this is urgent! And that while much can be done in contrib, many things cannot / or X, Y and Z are the pain points we will struggle with until A, B, and C gets into core.

(We may want to make a case that certain things should go into Drupal 7 — specifically the form element support.)

So what do you think? I'd like to submit this core conversation proposal later this week. Of course, the proposal doesn't need much detail. And we can figure out what exactly to present over the next 8 weeks. So let's discuss two things here: 1) is this a good way to go with whatever we are going to do for a core conversation? And 2) details of exactly what to pitch, who wants to present, etc.?

Comments

Presentation vs. roadmap

JohnAlbin's picture

Clearly, there's barely any time in 30 mins.

Agreed. So what we need to focus on is two things:

  1. getting a roadmap together
  2. making a cohesive, persuasive presentation

We don't have to present the entire roadmap during the Core Conversation. The purpose of the presentation should be to persuade people this is a good idea first. And then persuade people that our roadmap will get us to a HTML5-based Drupal.

  - John (JohnAlbin)

I'll love to do the 2nd

ericduran's picture

I'll love to do the 2nd bullet point. I don't quiet agree with the entire bullet point "Do 10 mins on Field API & how Drupal needs to change ASAP to support the HTML5 Form API."

This bullet point is more of a persuade people why is a good idea to get the html5 form stuff in Drupal Core and not so much what needs to change. As most of this can and is has been done in contrib. But this can consist of showing all the benefits and advantages we have if we have support for these new elements in Core.

@jen thanks for the initial writeup. This is a pretty good outline.

:)

jensimmons's picture

Yes, I think Eric should present about Form API. He's presented on it at DrupalCamps already, and has quite a lot of deep knowledge about it / work done on it already!

I agree with @JohnAlbin that

karschsp's picture

I agree with @JohnAlbin that a main topic of the proposal should be to educate people on why HTML5 in Drupal core is so important. It may seem like a no-brainer to hard-core themers, but I think the rest of the development community may need more convincing.

I agree with John. I think

theresaanna's picture

I agree with John. I think the important part is to get people to understand why this is important, since it's not as clear cut as some other improvements. For me personally, I think the most compelling reason is a combination of staying/becoming relevant in the growing mobile/alternative device world and bringing Drupal to a place where it drives innovation instead of simply responding to changes that are happening elsewhere in the digital world.

I think its important to outline the type of work that needs to happen without going into ALL of the specifics. After all, we probably won't have a comprehensive list until more of the work happens. I think there is a bonus to much of the work that will need to be done - that these are changes that might have needed to happen long ago - removing hard coded markup, etc. There is a dual benefit.

Trimmed Down

mfer's picture

I would propose you talk about:

  1. A top level statement to get people to pay attention. Make a fast point to draw people in. Something like "html5 is where the web is going and Drupal makes it very hard to do. Lets fix that."
  2. A roadmap and the top level plan.
  3. Where we are at in the roadmap if it has already started.
  4. An overview of the parts of Drupal it touches and quick suggestions of what needs to change. The low level details of the changes don't need to be hashed out. Touch on the top level architectural ones.

This gives people something to rally around and lays out a plan to get to the html5 promise land.

Should we address what

bleen's picture

Should we address what would/should happen during the next several years as we are forced to support HTML5 & XHTML 1.1/HTML4 concurrently? Or is that getting too specific for this conversation?

If this is a convincing

laura s's picture

If this is a convincing thing, then I'd suggest a quick #1 or #0 on the why: Why HTML5? Some quick points on adoption rates, js error handling, more robust webapp ui possibilities, back-end implications/benefits.

Those of us already sold on HTML5 on one or more of those points might find the other aspects interesting. People just curious will certainly benefit from a quick slide or two of overview, enough for them to say "ah, now that's interesting!" Then when the focused agenda items are discussed, they have something to hang it all on.

Laura Scott
PINGV | Strategy • Design • Drupal Development

meh

jensimmons's picture

re bleen's comment:

Well, I've been talking a lot about HTML5, and that question always comes up — Isn't it too early? But we can't do this because we have to support IE! The spec won't be done until 2012/2023 so why are we talking about this?

Honestly, I find that conversation very disruptive. Those of us who have done research and reading about HTML5 already know the answer — we can do this now, we should do this now. (HTML5 includes most everything from XHTML 1.0 anyway!) Jeremy Keith did an awesome keynote at DrupalCon Copenhagen that answered this issue really well.

With only 30 mins, I don't think we have time to teach people what HTML5 is, explaining the design principles built into it, and explaining how the fallbacks work. Of course we can and should sprinkle this stuff in — for example, mention while talking about forms that older browsers see everything as text and it's fine, so we are covered and our plan will work, etc etc.... but in general, we can either spend all of our time defending HTML5 to the naysayers, OR mostly ignore that conversation and talk about a Drupal 8 core game plan.

I already presented at the core dev summit in Copenhagen on "Why HTML5 is cool and we should put support in core" — many key core contributors were there. And Jeremy Keith's keynote later in the week got people very excited. And I am presenting on HTML5 and Drupal 7 (how to do HTML5 now) at DrupalCon Chicago. I don't really want to miss the chance to get going on a game plan for doing this by having an hour-long debate about IE's lack of support for HTML5 elements. At some point the ball needs to be moved forward.

(Really, the video for Jeremy Keith's keynote should be a prerequisite for this core conversation. Can we require that everyone watches it first!?)

Agreed!

ericduran's picture

We can probably just have a link to one of the many articles about support in unsupported browsers and that's it.

We can do this now, we should

bleen's picture

We can do this now, we should do this now

I completely agree ... I guess I have always been assuming that we would move forward in such a way that we were supporting both XHTML AND HTML5 simultaneously. In my mind this is where most of the pain is centered - this is the most difficult thing to achieve. Am I wrong? Is the goal to convince everyone that the time has come to ditch XHTML support?

While I would LOVE for this to happen, I dont think we'd be able to get support for that. And if we assume that I'm right then I think we need to discuss (as part of our roadmap) how we could rejigger things so that supporting both XHTML & HTML5 is possible.

Does that make sense? Thoughts? Questions? Comments? Concerns? Jokes?

Confusion

sreynen's picture

I guess I have always been assuming that we would move forward in such a way that we were supporting both XHTML AND HTML5 simultaneously.

This suggests some confusion about HTML5. First, HTML5 includes an XHTML variant, commonly referred to as "XHTML5." So it doesn't make much sense to talk about XHTML and HTML5 as if they're two different things. It might make sense to talk about XHTML 1 and (X)HTML5, but even then it would be difficult to not support the functionality of XHTML 1 in HTML5, as HTML5 is designed around existing browser behavior, which includes handling of XHTML 1 documents.

You're correct that I've been

bleen's picture

You're correct that I've been using the terminology wrong, but my question still stands. Lets just take a simple example.

Is the (short term) goal to replace the the standard search box in core with <input type=search ... > or is the goal to support both <input type=search ... > and <input type=textfield ... > in such a way that the site admin can choose (without manually re-theming every form element in core...). Would there be a checkbox somewhere called "Use HTML5 stuff" or will all core markup simply be changed?

I still think we will have a hard time convincing people of the later considering the inconsistant browser support right now...

Good example

sreynen's picture

That's a good example, because it points to precisely the kind of non-issue we're mostly dealing with in HTML5. I suggest you try opening search boxes with <input type="search"> in legacy browsers and see what actually happens. http://www.apple.com/ uses it so if you have IE6 handy, just open that up. You'll find it works just like Drupal's current <input type="text"> search boxes. Inconsistent browser support is only an issue if things don't work well, but HTML5 is specifically designed to work well in older browsers, and designed by people who made those browsers.

The question of how we deal with HTML5 breaking legacy behavior is only relevant when someone can point to legacy behavior it actually breaks, which will be very hard to do. In the few instances where someone can point to such breakage, the solution will be specific to how it breaks. There's no need for a general solution for turning off all of HTML5 when 95% of it works fine in all browsers.

No XHTML5

jensimmons's picture

We are not doing XHTML5.
No.

We are going to do (hopefully) HTML5, written with XHTML code formatting and stuff.

To officially do XHTML5, you use the xml mime-type. Which means that any site where someone enters invalid xhtml (which is easy on a user generated content site / a site with a wysiwyg) — that site will fail. Totally fail. Doesn't even load the page.

We aren't doing that.

We don't use XHTML1.1 right now for this exact reason. Drupal 7.0 is XHTML1.0.

HTML5 does let you format stuff in many different ways. All of these are valid:

type=email
TYPE=EMAIL
type="email"

We are going to do the last one. Period.

There's no debate about this — so I don't think we need to spend any time on it.

Also, when people say things like

we were supporting both XHTML AND HTML5 simultaneously.

They mean XHTML1.0.

Geeks apparently like to get into a good semantic nerdwar debating this, but I hope we can avoid it. Sadly, that kind of nerdwar sucked up a lot of time at the core dev summit in Copenhagen. :(

XHTML by any other name

sreynen's picture

I think you're just using the term "XHTML5" differently, not actually describing anything different.

We are going to do (hopefully) HTML5, written with XHTML

That's exactly what most people mean when they say "XHTML5," certainly what I meant. As you say, Drupal's HTML5 is practically similar to Drupal's XHTML 1: same MIME type, same formatting standard. If you want to stop calling that "XHTML" in HTML5 because the formal definition of that term changed, I wish you luck, but I'm not expecting anyone else to start using the MIME type definition any more than they did with XHTML 1.1. I think that's a semantic nerdwar we lost long ago.

See the docs on Polyglot

Yes and no

jensimmons's picture

Is the goal to convince everyone that the time has come to ditch XHTML support?

Well, for one, everything about XHTML1.0 is in HTML5. (Except for a few yukky tags like <big>). So having a web page with 80% old-school markup and 20% new HTML5 markup is totally cool. Really, that's how it's just going to be as we transition. You are still "doing HTML5."

As for forms — I think we want to simply replace the xhtml1.0 way with html5. Totally. No need to support both, or put a switch into core were people can choose. Back in August, I pitched the idea of such a switch. I assumed that was the only way we could get Drupal core to start doing HTML5, but by the time I left I believed doing such a thing would be way too much work, and totally unnecessary. Forms, for example, have awesome fallbacks. There's no problem in IE6, or even IE3 with HTML5 forms. The old browsers simply assume it's type="text".

In general, I think it's a case by case thing. I don't think we should use parts of HTML5 that are super unfinished or flaky or buggy. (Although by the time Drupal 8 comes out, it's likely there won't be any flaky or buggy parts anymore.)

Figuring out what to implement, and how, is the work.... forms seem easy. I think the doctype should switch as soon as we can do RDFa with HTML5. I think the core tpls should all be rewritten, along with Bartik. Menu API, and some of the other variables... all that HTML we can get our hands on should be brought up to the HTML5 standard! We just have to be care about how the CSS is written if we don't put the shiv into core (or go ahead and put a shiv into core). And the old browsers will be fine.

It would be cool if we can figure out what the February 2011 thinking is about what to do / how it will fallback, etc and present that in March. We must support older browsers, no doubt. We want it all to be as simple as possible. So let's work on this for the next 6 weeks, and present our decisions!

...

Jeff Burnz's picture

Good ideas and comment from John, lets not do anything like #5, its very off topic and will create distraction around an already cloudy issue.

I agree with jen that putting

linclark.research's picture

I agree with jen that putting forth a game plan will be the most convincing argument in favor of the proposal, more convincing than explaining that we should. Enough parts of the spec have been implemented by the browsers already. I think the argument is made stronger by taking for granted that implementing these things provides a benefit without breaking anything (because it is true), rather than explicitly trying to debate that point or debate the merits of the new standard.

RDFa

jensimmons's picture

Lin! Are you going to be at DrupalCon? Will you be sure to come to this conversation? There are so many questions about RDFa1.1 and HTML5 that need some expert knowledge!

I still need to figure out

linclark.research's picture

I still need to figure out some details, but fingers crossed, I will be coming. I will definitely be sure to make it if I'm there. If not, i think Stéphane is definitely going and I'm sure he'd be happy to sit in too.

Core Conversation Proposal EARLY Draft

jensimmons's picture

Ok, here's a super early first draft of a core conversation proposal. I think it reflects what we are talking about.... I'm sure I can write it better later (with more time), but thought I'd go ahead and share:

Title: Let's HTML5-ify Drupal!
30 mins
Drupal Core

Problem to be addressed:

HTML5 is hot. It will change the web. Drupal could get really behind if we don't get HTML5 support into core asap.

Specifically, core needs support for HTML5 Form API so that contrib project maintainers can leverage the power of HTML5 forms.

The markup for menus, scripts, styles, published date, is just too hard to change, and people who want to build a HTML5 site, but aren't Drupal theming experts will be frustrated and might decide not to use Drupal.

It's time to work on the default theme markup for Drupal core — the node, page, block, comment tpls, etc., as well as for Bartik.

Core leads the community. Let's lead everyone into the future.

Why is HTML5 cool?
Better UX for entering content via forms.
Semantic HTML means better findability and accessibility long-term.
Powerful APIs for creating applications.

Proposed Solution:
Let's alter core to support HTML5!

We have a gang of people working on this already — using the HTML5 Tools module and HTML5 Base theme to gather together all the changes we want for core, and make them available for Drupal 7. THese projects are a place for us to think through all the details, and test our plans. We also simply want to get the community behind our ideas, and start working on patches for Drupal 8.

We want to use this core conversation to ignite the community in a direction forward, and wrangle cats to be involved. We plan to have 2-4 people present in the 30 minutes, explaining our vision, and how to get involved.

Links:
groups.drupal.org/html5
drupal.org/project/html5_tools
drupal.org/project/html5_base
http://groups.drupal.org/node/118619

+1 - looks great to me!

laura s's picture

+1 - looks great to me!

Laura Scott
PINGV | Strategy • Design • Drupal Development

Looks really good

ericduran's picture

I would add Better UX for mobile devices in the why is HTML5 Cool section.

Or actually just add Better

ericduran's picture

Or actually just add Better UX for entering content via forms (Especially for mobile devices). Either or.

+1

jensimmons's picture

oh yes! mobile :)

I think we should reference

Jeff Burnz's picture

I think we should reference working Drupal 7 themes and modules as examples of HTML5 working in D7 right now - these can help in the "persuasion" part of the presentation John alludes to in #1.

Themes:
http://drupal.org/project/themes?filters=drupal_core%3A103&solrsort=sis_...

In particular because these have stable D7 code and fast growing user bases. Sky and AT7 are likely to account for over 10 000 Drupal 7 HTML5 sites.

http://drupal.org/project/sky
http://drupal.org/project/adaptivetheme
http://drupal.org/project/boron

Modules:
http://drupal.org/project/modules?filters=drupal_core%3A103&solrsort=sis...

In particular the Video, Elements and Plupload modules.

http://drupal.org/project/video
http://drupal.org/project/elements
http://drupal.org/project/plupload

We need more thought about the road map, so far we have:

RDFa+HTML5
Form API
Core templates and markup-generating functions

What else do we need to include?

+1 Great thread

johnvsc's picture

My first inclination when Jen added me to this thread was "um, duh, yeah we need HTML5" and love the Early Draft.

I would like to work on the "aren't Drupal theming experts" angle as that make up the majority of the world (i think) that touches on UX and "fluid UX".

Often, i find myself working on swappable, modular HTML engines that Drupal could benefit from. I know that this describes the theme layer - however we still have Core markup to deal with (read: override).

I wonder if such an engine could have an an HTML5 plugin and how that would manipulate values that Core would churn out ... even though I already have an idea about how to get that done.

Submitted!

jensimmons's picture

So I submitted the proposal. There's no place to see it.... (but for the record, it's node 3004).

That's just the proposal.... now to do the work of figuring things out, writing code for HTML5 Tools and HTML5 Base... and to putting together the presentation in February (assuming it's selected.) AND getting everyone there to discuss HTML5 and Drupal core!!!

Wooo Hooo!!

Coo, Thanks Jen.

ericduran's picture

Coo, Thanks Jen.

Uh, up above I was arguing

jensimmons's picture

Uh, up above I was arguing that we should try to skip over the HTML5 101 stuff and all the selling and convincing people stuff..... skip it so we can get to the technical details of what we want to do.

Yeah, I was wrong.

We have to really explain to people why it's ok to use HTML5 now. And why we want to — what the yummy benefits are. We can't skip that part. That's important.

I wish you could...

Cliff's picture

but I suspect you are right. It will take a lot of education to get enough people on board to make this happen.

Panels 960gs

bensnyder's picture

Hi all,

Great stuff going on over hear! Please make sure you check out the Panels 960gs theme. I'd love to hear feedback and even some help with the direction of the theme.

Ben

If you're on Drupal.org, you're already on HTML5!

alanburke's picture

The Doctype on Bluecheese, drupal.org's theme uses the HTML5 doctype.
The module used to determine the User's location on Drupal.org uses the HTML5 geolocation api [not strictly HTML5, but the point stands]
http://drupal.org/project/html5_user_geolocation

That should help convince people that we're ready to move core forward.

Selected!

jensimmons's picture

YAY \o/ — our core conversation has been selected! I've been advised to focus more on the implementation plan, and less on the why we should do it...

HTML5 Support

devildogmrk's picture

I think too many people are not educated to the fact that even when a browser does not actually support HTML5 the makers/producers have indeed accounted for it. By this I mean even when they are not prepared to support the functions yet, they have something built into the code that recognizes that you have deemed your document HTML5 and therefore EITHER displays the alternative (which is rare) or simply converts it to the equivalent HTML4 / XHTML 1.1 and does this on its own. That means we do not have to worry about whether the browser does or does not support it. They themselves are already addressing it. And the browsers that do not do this,

1.) simply display the common commands in their default version of html.
2.) are not worth worrying about because they are obviously not one of the more used browsers anyway.

But I digress, plain and simple Drupal must support it to stay current or be left behind...period. Joomla and other CMS systems are working on it or have modules that fully support it. Most major independent development environments (IDE) either have support for it or are working on implementing support for it. Even some of the less popular WYSIWYG tools are going this route. Point blank, it is up or out and that is really the only point that really needs to be stressed about it. That in not doing so we will no longer be competitive and therefore will lose our user base.

Now having said all of that. I will gladly work on any of the points you have listed. All I need you to do tell me which one you would like for me to focus on and I would do it. They are all important points and they all need bodies to support their cause. So really the questions is how many people to do you need on each task and which ones are covered and which ones still need support.

Mark L. Krug
Chairman / CEO
Paladin Pursuit, Inc.
(816) 503-9586

business: mark.krug@paladinpursuit.com
personal: devildogmrk@yahoo.com

Getting Involved

jensimmons's picture

How do you get involved? A great question! Right now there are two projects where you can help work out the code:
HTML5 Tools
http://drupal.org/project/html5_tools
D7 issues: http://drupal.org/project/issues/html5_tools?version=7.x
and
HTML5 Base
http://drupal.org/project/html5_base
D7 issues: http://drupal.org/project/issues/html5_base?version=7.x

These issue queues are lists of specific tasks that need action. Work on any thing you are interested in!

You can also comment on: http://drupal.org/node/675348 or even rewrite the patch there (if you happen to know how).

Also, everyone, if you haven't already, please comment on the main issue about using HTML5 technologies in Drupal 8 at http://drupal.org/node/963832

Good news Jen, well done.

Jeff Burnz's picture

Good news Jen, well done. Glad we dont have to worry so much about the "why".

Do we have a document or thread to discuss implementation plans. Clearly we need to break this down and need to start pulling in core maintainers for input to help put this together.

Writing to Do, yes!

jensimmons's picture

Yeah, we have a lot of writing to do.

  • There's a HTML5 Myths document that's been started, but needs more info. Anyone can contribute: http://groups.drupal.org/node/123909
  • I'm working on a Guiding Principles document that I think will be very helpful down the road.
  • We need a document to write up the overall plan. Some of the best of what we have so far is on the HTML5 Tools and HTML5 Base project pages.

I presented at the NYC Drupal Meetup last night about what we are doing. Slides at: http://jen.cm/h4

OK, lets get this rocking...

Jeff Burnz's picture

OK, how about we start a Google doc and start pulling in the core maintainers to contrib to that. We used Google docs a lot for other big projects such as D.O redesign and it works well. Later we can reprint it as a wiki page.

I can structure the document so each core maintainer can get their blurb down - high level, bullet point lists of the main objectives and possibly how to achieve them, and time frames. Sun's suggestions over on d.o were very good and can be followed.

Dries has pointed several times to D8 having a shorter cycle, so we need to know what is achievable in D8, what seeds can be planted for future harvest, whats critically needed very early in the D8 cycle.

Can we setup some IRC meetups, or Skype meetings - someone can arrange these please, so we can go over this stuff and get some organizational structure to what we are doing.

HTML5

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week