Many of the new HTML5 input types degrade nicely in older browsers. Thus, we could support them now.

A nice example of some of these input types here: http://diveintohtml5.org/forms.html

As this would probably require API changes, I am assigning this to 8.x-dev.

EDIT: The current summary and progress of HTML5 and Form API changes can be found at http://drupal.org/node/1183606.

CommentFileSizeAuthor
#18 elements.patch9.32 KBericduran
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

These would be really nice, but yeah, D8. We could possibly add them to the Elements module for D7 experimentation!

strider72’s picture

In terms of the way HTML forms work anyway, Drupal's drupal_get_form() should work the same way: accept any "#type" and if it is unrecognized, just make an input element with a type attribute of whatever the developer put in.

That will future proof the function somewhat. Don't just add the HTML5 types as new accepted types; make it so drupal_get_form will appropriately accept *any* type and just use it. (If that had been done previously, we could be using the HTML5 types right now in Drupal 6.)

strider72’s picture

Just for the record and for people reading this later: New HTML5 input types:

website
phone
email

for URLs, phone #s, and email addresses, respectively. Usage example:

<input type="phone">
Damien Tournoud’s picture

@strider72: the Form API has been extensible from the start. What you describe is possible since Drupal 5.

strider72’s picture

@Damien -- Via module I assume you mean? I'll check into that -- thanks. :-)

In the meantime, I think my suggestion still stands. The full flexibility of the HTML standard can and should be built in.

ericduran’s picture

FYI: for anyone that lands on this thread, the elements modules already provide form api elements for the new elements, in 6.x and there's a patch for 7.x.

But yes this should probably make it to 8.x in core.

Also linking to a related issue. #963832: Decide how to use HTML5 in Drupal 8

Everett Zufelt’s picture

Issue tags: +Accessibility

Tagging with accessibility since any change in form markup effects all user agents, including some assistive technology.

bowersox’s picture

+1 for HTML5 form input elements

mgifford’s picture

+1

mattyoung’s picture

~

mgifford’s picture

Issue tags: +html5

tagging

Dave Reid’s picture

Assigned: Unassigned » Dave Reid

I'm willing to lead this for D8.

nfreear’s picture

This is a great issue to raise.

Note, other useful types introduced in HTML5 include 'date', datetime etc. If there is any work on fallback solutions for these, ie. jQuery widgets, care needs to be taken that the fallback is keyboard accessible etc.

Unfortunately, many Javascript date-pickers are not particularly accessible - I think this one from frequency-decoder was the best I found (of course there may be better).

I'll check out the Elements module.
Cheers, Nick

mgifford’s picture

I'm not exactly sure how to approach this problem. Ideally we'd probably want to start with HTML5 forms. If the browser doesn't support HTML5 then we'd want the forms to flip back to HTML4 in the DOM using javascript and then optionally apply a javascript date-picker? Or would the javascript date-picker just present a format that the old browser can understand? I do hope that we use a Progressive Enhancement approach when implementing this, however most of this is just making it backwards compatible.

ericduran’s picture

@mgifford & @nfreear There really isn't any issues with progressive enhancement. Most of this has been discuss extensively at #963832: Decide how to use HTML5 in Drupal 8

Regarding the date and datetime element. Those are odd cases which I don't think will be proposed for inclusion. Most of the elements proposed for inclusion will be what we already have working properly in the Elements module (http://drupal.org/project/elements).

Dave Reid’s picture

Honestly we'll probably focus on the basic elements first (url, email, search, number, range), and then focus on the harder onces that don't easily degrade to browsers without HTML5 support.

jensimmons’s picture

Category: feature » bug

I think we should consider putting support for HTML5 Elements in Drupal 7.

I've been discussing this extensively with Eric Duran and Dave Reid. We are not talking about changing the form fields to print out in HTML5 — we can change that in Drupal 8. We want to *add* support for HTML5 Elements, so that any contrib module that wants to can create HTML5 forms through the Drupal Form API.

Right now, for example, HTML5 Tools module creates HTML5 forms. But it does so by relying on the Elements module to provide support for the needed Elements. Without Elements module in core (or this part of it), we don't have a unified way to do HTML5 Forms. Contributed modules of all kinds are unable to work together to do HTML5 Forms.

Perhaps Eric or Dave can say it better. But it seems there would be no harm in adding this to Drupal 7 now. It would not break backwards compatibility. It would add something new that would do nothing unless a module intentionally used it.

ericduran’s picture

Version: 8.x-dev » 7.x-dev
Category: feature » bug
FileSize
9.32 KB

A nice small patch that gives module developers the most basic and most supported new elements as field types. Email, Search, Number, URL, and Telephone.

/me Didn't replace any of drupal forms to actually use the new elements. Just for other modules.

casey’s picture

Damien Tournoud’s picture

Version: 7.x-dev » 8.x-dev
Category: bug » feature

There is nothing that remotely looks like a bug here. As already stated repetitively in this issue, the Elements module already provides support for those HTML5 elements. Having API-type modules likes this outside of Core is not a first, and is not a bug (think CTools, Entity, Token, etc.).

Moreover, Drupal 7 outputs XHTML+RDFa 1.0 by default, which is not compatible (as far as I know) with those new input types. Changing this is opening a can of worms we cannot takle in a stable version of core (compatibility between HTML5 and RDFa? HTML5 vs XHTML5? etc.).

jensimmons’s picture

Version: 8.x-dev » 7.x-dev

Ok, it's not a bug. I was trying to cheat. Busted. It is a feature request. Sorry, I take it back.

But I still want to think about the possibility of putting this into Drupal 7. I know it is not in line with the typical "what's allowed in a point release". But I think we have some serious thinking to do here... when will D8 come out? Will it be the quick and small release some people are talking about? Or will it be 2-3 years before it comes out? Can Drupal core really wait that long to get support for HTML5 Elements into core?

I'd like to have a bit of a discussion about the merits of this before jumping to the "we don't do it that way" conclusion. Just a bit. I'm not some random person who doesn't understand how the Drupal release cycle works. I've actually thought about this a lot and had some pretty in-depth conversations about it with people before proposing this here.

And Damien, you are right, we do NOT want to open any cans of worms! But adding HTML5 Form Elements *support* into core doesn't do that. This is a very conservative proposal. NONE of the core form elements would get rewritten to use the HTML5 format by this patch. (That should wait until D8, absolutely). Everything about core output would stay exactly the same as D7.0. This patch just provides people with the ability to use HTML5 forms in their contrib modules, if they wish, however they wish (with a switch/widget choice? or as the default?) Without this patch, every module that wants to support HTML5 forms would either require the Elements module as a dependency (which many module developers hate to do, and that's assuming they know about Elements module), or re-implement Elements module themselves, or not do HTML5 forms at all. By putting this patch into D7, we'd be saying, yes we know HTML5 is coming. We want to support your work to begin implementing it. We aren't going to wait until 2013 before we allow you to try out HTML5 forms in what you are doing. Core itself will (likely) implement HTML5 forms later, but we will let you mess with it now if you want to.

In regards to your doctype question, if a person uses HTML5 input types on a site with the XHTML1.0 + RDFa1.0 doctype, nothing will explode. Nothing will break. Browsers actually ignore the doctype at this point (they only look to see if it exists, and if it's at least 13 characters long, and if so, it does not interpret CSS in quirks mode). Each modern browser will take as little or as much HTML5 markup that you throw at it, and implement what's there. You can mix and match all HTML5 and XHTML you want without a problem. The browser itself is what actually "switches", and most already have. The website is not "switched" by the doctype. If you are reading this page with the current version of Safari, FF, Chrome, Opera, or a mobile webkit browser, you are reading an HTML5-spec-rendered web page, no matter what the doctype is. So put an HTML5 form on a XHTML1.0 doctype, and the form will be rendered as HTML5 just fine in browsers that understand HTML5 forms. And it will be rendered as type='text' automatically by IE 5–8.

(Of course, using the XHTML1.0 + RDFa1.0 doctype, while putting HTML5 forms on your site means your site won't validate as XHTML1.0 + RDFa1.0. But if you know enough about web standards to check for validation, and you care about passing validation 100%, then you probably know enough to not do any HTML5. Or to switch doctypes. Drupal core's ability to pass XHTML1.0 + RDFa1.0 validation out of the box will not be affected what-so-ever by this patch. This patch does not alter Drupal's forms. It just allows people to reformat the forms if they want to using contrib.)

Getting this into core now allows contrib to evolve on top of one Form API elements solution. Not having this in core means contrib will spend the next 1-3 years handling HTML5 form element support in potentially different ways, with duplication of effort for something that's quite far down in the stack. I'd rather see consensus on the deep API stuff, and experimentation and innovation regarding the implementation of these elements.

jensimmons’s picture

Having API-type modules likes this outside of Core is not a first, and is not a bug (think CTools, Entity, Token, etc.).

Actually this is different than the case of CTools, Token, etc. This is not a new API for Drupal. Drupal's Form API has been around for a long time, and nothing about this patch overhauls the way that Drupal API works.

This is not an introduction of a new Drupal API.

This is adding support for an HTML API.

And it's not a new HTML API. The HTML5 Forms API began in 2003 as "XForms Basic". That became Web Forms 2, which was worked on in draft after draft after draft from 2004-2009. Two years ago, Web Forms 2 was officially incorporated into the WHATWGs HTML5 spec, where work on it continued.

The above patch implements support for the HTML Form API types Email, Search, Number, URL, and Telephone. At this point, all of the browser manufactures have agreed to implement all those form types — and they agree on how to implement them. That includes Microsoft. There isn't any more debate about these elements. They've been worked on for 8 years, and there's total agreement.

There is still a chance that the rest of the HTML5 Form API could change slightly — range, color, etc... and since those elements have not been fully implemented in browsers yet, we are conservatively *not* proposing to add support for those in core just yet. We can do so later, once there's 100% agreement by the browser makers. There are over a dozen types total; right now, we want to add five of those.

(And again for those of you wondering about IE 6,7 and 8: a) this patch does not make Drupal core implement the form types yet, it just allows contrib modules to do so; and b) IE 5–8 all degrade these form types without any error or trouble. IE 5–8 simply interprets the new form types as text. http://diveintohtml5.org/forms.html)

Dave Reid’s picture

Also, the patch needs to be re-rolled from the current elements code, which simplified a lot of things.

ericduran’s picture

@dave, I was being very conservative :) didn't want to add the helper functions

Dave Reid’s picture

+100 for getting in the basic new elements first.

eaton’s picture

Category: bug » feature

The above patch implements support for the HTML Form API types Email, Search, Number, URL, and Telephone. At this point, all of the browser manufactures have agreed to implement all those form types — and they agree on how to implement them. That includes Microsoft. There isn't any more debate about these elements. They've been worked on for 8 years, and there's total agreement.

Agreed that adding support for these HTML5 elements isn't the same as deep API changes. It does expand the elements that are available, but it doesn't modify the operation of previously built forms. Modules that rely on those HTML5 form elements would be able to list the point-release of Drupal 7 that includes them as a dependency (rather than just 7.x).

A couple caveats:

  1. Are there existing contrib modules that implement those form element types as CUSTOM elements that work in HTML4? This patch might have the effect of 'blocking' the upgrades of those modules without making a fully HTML5 transition.
  2. There isn't any good way that I know of to ensure that the current theme is outputting an HTML5 compatible page in other respects. If inexperienced users like an XHTML theme, and combine it with a module that outputs HTLM5 element types, they'd get an invalid document. We need to determine if that's acceptable (for Drupal, not for the markup.)

The real kicker is that this is the kind of change that absolutely would not have made it into point releases of the 6.x branch. It seems like a good test case for the much-talked-about "Drupal 7 might include additions in future point releases" idea that has been floated around a lot over the past year or two. Whether this patch should go into D7 is just a matter of resolving that question. If webchick and Dries are actually open to the principle, additional HTML5 element types are good candidates.

jensimmons’s picture

If inexperienced users like an XHTML theme, and combine it with a module that outputs HTLM5 element types, they'd get an invalid document. We need to determine if that's acceptable (for Drupal, not for the markup.)

Correct. Invalid. But completely functional — the page still works, and the forms still work (just to be re-redundantly clear).

There are a lot of modules that do this already — provide tools to help people output invalid XHTML. Any module that puts an <embed> tag into the HTML, for example, will invalidate a page. WYSIWYGs are notorious for creating invalid HTML. So we already allow the situation where modules to create invalid pages.

I am all for efforts to help Drupal sites create better standards-based HTML! But to me, holding back on the implementation of HTML5 in the name of XHTML validation is a misunderstanding of the purpose of validation. I have yet to meet a web standards evangelist who cares about failed validation caused by adding HTML5 elements to a page with the XHTML doctype.

ericduran’s picture

Regarding @eaton 1st point.

There aren't any elements that declare those same elements with the same exact name. We ran into this problem when working on the elements module in the 6.x branch. For example the email module declares a new email elements type but we used emailfield to avoid collisions same goes with cck number elements we decided to use numberfield in order to avoid naming collision.

[edit] - Added below
Regarding @eaton 2nd point.

This is a good point, also one we run into this with the html5_tools module. We were talking about overwriting the html.tpl.php file but at the same time we don't want to change the doctype on an inexperienced users which isn't aware of what's actually going on. As you mention this really is a question of whether drupal is ok with this or not.

One good point is that Drupal by default will not invalidate the markup with this patch but the contributed module that uses the new elements will invalidate the markup but as @jensimmons mention there are already modules that invalidate the markup. I would think this is the responsibility of the module and/or the user to implement the features correctly.

jensimmons’s picture

Status: Active » Needs work
ericduran’s picture

Status: Needs work » Needs review

switching status to at least check that the patch applies cleanly

apaderno’s picture

Isn't adding new function considered an API change?

ericduran’s picture

@kiamlaluno technically its not an api change as the Form api which is the underline API isn't change at all. It can be consider an API addition but its really not.

eaton’s picture

Isn't adding new function considered an API change?

Yes, but as mentioned earlier there are a number of changes in Drupal 7 -- the ability for a module to specify "Drupal 7.2 or higher" in its core requirement line, and the existence of a large body of automated tests for the existing codebase -- that could make this more palatable in this release cycle.

It's not something that has been committed to, but both Dries and webchick have mentioned the possibility that non-breaking additive functionality and API additions could go into future point versions of Drupal. Whether they will is another question, but I think that these element types are good potential candidates.

apaderno’s picture

New theme functions are being added, and the patch changes what the array returned from a form builder can contain. Developers could have created already a custom module for these elements and this patch would make those modules not compatible with Drupal.

It is true that modules can report with which Drupal version they are compatible, but it is not possible to write something like core < 7.1.

Clearly Dries or webchick will decide if the API change can be done. I am not sure they meant to introduce API changes still in Drupal 7, or starting from Drupal 8.

ericduran’s picture

@kiamlaluno good points but your concerns are discuss in comment #28. Also the maintainers (Dave Reid, Jen Simmons, and myself) of the Modules which do create these exact elements (elements, and html5_tools) have already commented on these issue and are actually 100% with this patch getting in.

I guess we'll just have to wait and see if these types of changes are going to be allowed in a point release or not :)

Everett Zufelt’s picture

@ericduran

Although I am in support of this API addition, I will say that even though the contributed modules that create this functionality do not cause collisions, it is possible that a custom module on some site may. This is unlikely, but is worth mentioning as one of the factors to be considered.

jensimmons’s picture

Status: Needs work » Needs review

I really like the way Eaton defines this issue:

The real kicker is that this is the kind of change that absolutely would not have made it into point releases of the 6.x branch. It seems like a good test case for the much-talked-about "Drupal 7 might include additions in future point releases" idea that has been floated around a lot over the past year or two. Whether this patch should go into D7 is just a matter of resolving that question. If webchick and Dries are actually open to the principle, additional HTML5 element types are good candidates.

and

Yes, [this is an API change], but as mentioned earlier there are a number of changes in Drupal 7 -- the ability for a module to specify "Drupal 7.2 or higher" in its core requirement line, and the existence of a large body of automated tests for the existing codebase -- that could make this more palatable in this release cycle.

It's not something that has been committed to, but both Dries and webchick have mentioned the possibility that non-breaking additive functionality and API additions could go into future point versions of Drupal. Whether they will is another question, but I think that these element types are good potential candidates.

To me this is a high-level vision question about how the evolution of Drupal is going to work for D7... and a good one. Not really a "will this work technically" issue, because I believe the answer to that is yes.

-------------------------------------------------------------------------------------------------------------

A number of people have raised concerns that this could break existing modules. Can anyone name any such existing modules? As Eric Duran said in Comment 36, the maintainers of the known modules that alter Drupal forms to be HTML5 are the people who want this patch to go in. Can anyone name any other modules that implement HTML5 forms? The idea with doing this now is that we could get the deepest, underlying support framework into core before we get a mess of seventeen different versions of how to solve this problem. I'd rather hunt down and help migrate the one or two obscure modules that might exist now, and unify us all, asap, then allow a situation where we get too many different versions and have a very hard time doing this later.

Extend HTML was a Google summer of code project that addressed HTML5 Forms in Drupal. It hasn't been worked on in four months. Maintenance status: Unknown. There is no release. And we've already been in touch with both the creator of the project, and his GSOC mentor about combining efforts, offering help, etc.

Sun's been slowly working on a patch to his Compact Forms module. Looks like he hasn't implemented anything yet: http://drupal.org/node/669878

Drag and Drop files is a Drupal 6 module created last summer to enable HTML5 Drag and Drop API on D6 upload module and CCK file fields. Maintenance status: Unknown. Development status: Unknown. Hasn't been updated since the first day code was posted, 29 weeks ago. 38 sites using it.

SignatureField allows you to collect HTML5 canvas based signatures in webform, cck and in your custom modules via fapi. 5 sites using it. It doesn't look like it would be affected by what we are proposing.

Almost everything I could find on drupal.org about HTML5 Forms is in the HTML5 Tools or Elements module issue queues.

jensimmons’s picture

Status: Needs review » Needs work

Meanwhile, the patch in Comment 18 passed the tests. Let's get a reroll of it, as requested in Comment 23.

ericduran’s picture

As per #24 The patch was written to be as minimalist as possible.

ericduran’s picture

Status: Needs review » Needs work

Just talked to Dave Reid, this indeeds needs rerolled, I was confused about what was needed to be changed.

alanburke’s picture

Subscribe.

Damien Tournoud’s picture

Version: 7.x-dev » 8.x-dev
eaton’s picture

Version: 8.x-dev » 7.x-dev

Damz, I believe the issue of 7.x or 8.x is an outstanding question -- it's the key question, in fact. We've all got opinions on it but I don't think the version of the issue should be changed until there's some weigh-in from Webchick or Dries on whether this sort of feature can be realistically anticipated for future d7 point releases.

Dave Reid’s picture

I have started a sandbox fork of Drupal for HTML5 initiatives at http://drupal.org/sandbox/davereid/1086890. A 'html5-fapi-elements' branch has been created and the types from the Elements module merged in.

Jeff Burnz’s picture

I've dug up an old sandbox module of suns we were using for theming form elements in D7, and added the input types so we can test these for accessibility, theming etc http://drupal.org/sandbox/jmburnz/1096432 I haven't added the file field stuff as yet, if someone wants to do that I'll add commit access. You need Dave Reids sandbox fork linked to in #45.

Edit: Jacine just told me suns markup_test module was merged into http://drupal.org/project/design, so I'll see about getting a patch for that to add these input types.

mfer’s picture

@eaton & @damien Doesn't a change like this need to go into D8 first. Then be back ported as a feature addition to D7? (As opposed to going into D7 and being forward ported to D8)

Damien Tournoud’s picture

Version: 7.x-dev » 8.x-dev

When eaton posted #44, 8.x was not open. Now it is, and the backport policy applies.

Let's get a patch together :)

kika’s picture

For reference: http://wufoo.com/html5/ (Current State of HTML5 Forms)

Dave Reid’s picture

I will roll my most current page from my sandbox's branch today. We need the additional validation and converting core elements to use the new types. We have a *loooooot* of 'number' elements.

Dave Reid’s picture

Title: Support HTML5 form input elements » META: Support HTML5 form input elements
sun’s picture

Please remove those "field" suffixes from all #type names. "textfield" is a bogus name in itself, should have been fixed long ago, was attempted again for D7, but too late, so hopefully it'll make it for D8: #431812: Rename FAPI type 'textfield' to 'text' globally -- Anyway, as far as Form API element #types are concerned that directly refer to HTML elements, they should use the same name. They are also not fields in the sense of Field API fields.

Dave Reid’s picture

Assigned: Dave Reid » Unassigned
Dave Reid’s picture

Renaming the fields limits our ability to backport these new elements to D7 because likely there would be conflicts with email.module, date.module, phone.module, etc.

mattyoung’s picture

what a bout the 'autofocus' attribute for text input? Can it be part of this?

EDIT: nevermind, you just added it.

fago’s picture

I second sun's comment in #53 that we should not add that "field" suffix.

>Renaming the fields limits our ability to backport these new elements to D7 because likely there would be conflicts with email.module, date.module, phone.module, etc.

Backport-considerations should not negatively affect our future-element-names. If necessary, we can *namespace* them for D7 only. Not ideal, but at least it is limited to D7. Suffixing, generally is a really bad way to prevent name conflicts.

Imho at least contribs should properly namespace their elements, to avoid conflicts. Ideally, core would follow that too, but that's not very practical. As core is first anyway, keeping core-element-names fluent is ok I guess.

Dave Reid’s picture

Status: Needs work » Active

Well the problem is we have modules whose namespaces would be the element names themselves. I agree though and we're already doing the fields without the 'field' suffix in the separate issues. Backporting will happen when we get to it.

Moving this issue to active since it is a meta-issue now.

RobLoach’s picture

Dave Reid @ #58

Moving this issue to active since it is a meta-issue now.

Mind updating your post at #1 to be the current status of all the sub-issues, like you have in #51? Then when people visit the issue, they'll know the status right off the bat! Yay to actionable issues rather then meaningless debate!

This post was actually meant as a subscribe comment, but I'm not that much of a sell out.

Dave Reid’s picture

Much better summary is now at http://drupal.org/node/1183606.

webchick’s picture

For discussing the backportability of this feature to D7, please see #1268826: Consider allowing new HTML5 FAPI elements to be backported to D7 so that important work here is not derailed.

grendzy’s picture

mgifford’s picture

So can we close this now? What's left to add?

webchick’s picture

Comparing http://www.w3.org/TR/html5/forms.html#attr-input-type-keywords to system_element_info() in D8, we see...

hidden
text (called 'textfield' for some reason)
search
tel
url
email
password
date
number
range
color
checkbox
radio
file
submit
button

function datetime_element_info() has:

datetime

That means we're still missing:

month
week
time
datetime-local
image
reset

mgifford’s picture

Can we still get those into D8?

Is it worth adding month, week, time & datetime-local? I'm not certain what additional functionality it's going to give us.

Image & reset buttons are nice I guess, but not sure how we would incorporate them.

I just did a quick search in the issue queue, but didn't see anything related to those 6 outstanding items in:
https://drupal.org/project/issues/search/drupal?status[]=Open&version[]=...

webchick’s picture

We can. They'd be new features that would be held up on thresholds.

mgifford’s picture

I've added this issue for the date. There are other related issues I've found and tagged there for the date elements.
#1972660: Add tests for the new HTML5 date elements 'date', 'datetime', 'datetime-local' and 'time'

I'm having problems finding information for the image & reset elements though. This is as close as I've gotten:
http://dev.w3.org/html5/markup/button.reset.html#button.reset

But I'm not an HTML5 expert by any means.

moonray’s picture

One noticeable side effect of using (for instance) the HTML 5 email field is that you can't enter a token, since it will not validate as an email address on the browser end. Related to #1070878: Allow tokens to be used in the default value of a field

This is already an issue when using html5_tools module and field_default_token module. Setting the default value for an email field will not work due to browser validation. Is there any way around this? I'm not sure. But it's an FYI at least.

bowersox’s picture

Well, that really is unfortunate. I believe the only solution will be to switch back to a input type="text" field.

mgifford’s picture

Issue summary: View changes

@webchick, your list in #64 doesn't line up with https://drupal.org/node/1193054 or https://drupal.org/node/1183606

We should also check with http://caniuse.com/#cats=HTML5 or similar...

mgifford’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Active » Postponed

I'm assuming this should get bumped to 8.1.x.

mgifford’s picture

Status: Postponed » Active

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mgifford’s picture

Issue tags: +keyboard focus

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mgifford’s picture

Issue tags: -keyboard focus +wcag412

Tagging for better semantics.