Some of the patches landing via the HTML5 Initiative should be considered for Drupal 7. Here's why:

  • They don't break anything. These are entirely new elements and properties, with their own brand new theme functions. Very simple and straightforward.
  • We are not proposing any actual forms get updated to use new elements, just that they'll be available for use by contrib.
  • People want it. HTML5 was the most asked for feature in the recent Drupal survey. There is no need for people to wait 2-3 years for all of it.
  • It'd be one less contrib module for people to download (and complain and claim "Drupal doesn't support HTML5," which I think is BS, but could potentially start to hurt Drupal's adoption rate in the near future).

There's been an understanding amongst the HTML5 Initiative team members that the FAPI patches could go into Drupal 7 and that we'd like to try and make that happen. Right now, the patches are specifically being written in a way that makes backporting them possible. Our hope is that our first round of patches for this will be accepted and backported, and then directly afterward we will begin refactoring them in a way that makes more sense for Drupal 8 (such as refactoring and condensing the various input types into way fewer elements and theme functions).

Right now we need to know whether or not we're going to be allowed to do this, officially, so we can proceed accordingly.

Comments

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Completely agreed with the points made - this is why we've been writing the issues they way we have so that they can be easily backported. It would be good to get an official response from Dries and/or Angie. The only module backporting would conflict with is my own (Elements.module) and I have no problem with it.

damien tournoud’s picture

damien tournoud commented
Status: Active » Closed (duplicate)

Most of this discussion already happened in #675348: META: Support HTML5 form input elements. Let's not open several issues for the same thing.

I'm rather -1 on the principle, because:

  • Those elements do not belong within the doctype we are promoting in D7 (XHTML+RDFa 1.0), and changing the doctype is probably to big a change for D7. I know it doesn't matter for browsers, but it does for validators, which has always been the point of having a doctype (remember: be conservative in what you send, lenient in what you receive).
  • Those elements are already provided by an established contrib module
jacine’s picture

jacine
she/her
Location New York
commented
Status: Closed (duplicate) » Active
webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Issue tags: +Needs issue summary update

Well, I'd rather have this conversation separately without creating noise for people trying to solve real issues for Drupal 8 in #675348: META: Support HTML5 form input elements. There were indeed several comments around the backportability of this feature to D7 in that issue, but they were off-topic and only there because we didn't have a D8 branch at the time.

Also, I'm not comfortable making an "official" call on this until I can see how this discussion plays out, and a pros/cons list. Tagging "Issue summary initiative" to hopefully get an issue summary that provides this.

At the moment though, my thinking is along the same lines as Damien. A well-documented workaround with no core hacks required exists for D7, and it doesn't expose elements to module devs/themers that conflict with our DTD.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Also, this approach raises questions with me:

"Our hope is that our first round of patches for this will be accepted and backported, and then directly afterward we will begin refactoring them in a way that makes more sense for Drupal 8 (such as refactoring and condensing the various input types into way fewer elements and theme functions)."

One of the primary reasons for getting this feature into D7 core is that modules and themes could make use of it now, without waiting for D8, and without a requirement on a contributed module. However, if we're knowingly putting elements into D7 that will be incompatible with D8, I kind of fail to see the point. Maintaining that going forward is going to be a hassle, since nothing in core uses these elements and D8 patches fixing bugs on them won't apply. And the Elements module in contrib would have the flexibility of starting a 2.x branch at an arbitrary point during the D8 cycle which could offer theme_element_textfield() or similar functions that conform to the D8 elements, so module / theme developers can take full advantage of them, and have less work required when porting D7 -> D8 to boot. Core doesn't have such flexibility, so you'd be locking your module/theme to a dead API.

jacine’s picture

jacine
she/her
Location New York
commented
Issue tags: +D8H5
Everett Zufelt’s picture

Everett Zufelt commented
Title: Consider allowing new HMTL5 FAPI elements to be backported to D7 » Consider allowing new HTML5 FAPI elements to be backported to D7
Everett Zufelt’s picture

Everett Zufelt commented

Some issues are stalled waiting on a resolution to this question. I would tend to agree with Webchick, that we should be targeting 8.x, and not in a way that requires future refactoring.

idflood’s picture

idflood commented

It seems everybody is thinking the same. Let contrib modules take care of html5 elements for d7 and directly implement them as cleanly as possible in d8. So, "closed (won't fix)"?

Everett Zufelt’s picture

Everett Zufelt commented

+1 on closed / won't fix.

jacine’s picture

jacine
she/her
Location New York
commented
Status: Active » Closed (won't fix)

Ok :)