Pages

Thursday, August 23, 2012

Contributing to the HTML5 Initiative


The HTML5 initiative is still in the early stages of planning, and this page is very much a work in progress. Updated information will be posted in this section as it becomes available.
The process of modifying Drupal core to use HTML5 will happen in Drupal's core issue queue. Tasks will be broken into small, manageable, task-oriented issues. Each issue/task will be discussed, prioritized and ultimately implemented in these issues. We'll need help in the form of: feedback on issues, patches, patch reviews, testing, documentation and project management help to help organize and distribute the work.
The issues relevant to this initiative will be tagged HTML5, and they can be found here:
General HTML5 discussion can also be found in the HTML5 group.

Meetings

We hold an open meeting in IRC every two weeks to discuss priorities, progress and issues. The meeting announcements are posted in the HTML5 group, which sends e-mail notifications for new posts/events. Please join the group if you are interested in helping with this effort.
You can subscribe to the Google Calendar for this and future meetings via the iCal or XMLfeeds.

IRC

Connect with team members and Drupal contributors working on HTML5 on IRC:
  1. #drupal-html5 is smaller crowd, dedicated to discussions about HTML5 and Drupal.
  2. #drupal-contribute is the place to go to discuss general issues about contributing to Drupal, whether it be core or contrib.

Making changes to Drupal core (participating in the issue queue)

In a nutshell, this steps below describe the life cycle of a typical Drupal core issue. These steps have been tailored slightly to fit the HTML5 initiative and are meant to give you a "quick start" overview of how the process works, so you can jump and help. For complete documentation on contributing to core and general advice, visit the Drupal core contributions section of the handbook.
  1. A single task, problem or solution that needs to be addressed is identified.
  2. search of existing issues is performed to prevent posting a duplicate issue.
  3. An issue describing the bug report, feature request, or a task is created and taggedHTML5. Adding this tag is very important to ensure it stays on the HTML5 initiative team's radar.
  4. Others in the community read the issue and discuss its merit and possible solutions the comments.
  5. Once the general direction is agreed upon (and sometimes beforehand), one or more of the participants post a patch which makes the proposed changes to the codebase.
  6. The participants then test and review the patch to ensure its quality, and provide feedback. There are many things to check for during this process:
    • Does the patch solve the problems outlined in the issue?
    • Is the solution aligned with the initiative goals?
    • Does the code conform to Drupal coding standards?
    • Has the patch successfully been tested with existing core themes?
    • Has the patch successfully been cross-browser tested?
    • Is the documentation sufficient?
    • Does the patch have unit tests (usually for more advanced patches)?
    • Does the patch pass the testbot?
  7. If the issue is long and has changed direction more than once, issue summaries (which are extremely helpful for those joining a long discussion) should be created.
  8. Once all of the above has been satisfied, the code will be marked "Reviewed and tested by the community" or RTBC.
  9. Then the initiative leader will do a final review before committing to the initiative branch, and will return to report the issue as "fixed" or "needs work" if additional documentation is needed.
  10. Eventually, the Drupal 8 maintainer or Dries will merge the initiative branch code into the the main branch.

Implement Form API support for new HTML5 elements


Overview

HTML5 forms are one of the areas where major changes and improvements have been made. There are 13 new element types and a number of new attributes that aim to improve both the user and developer experience of HTML forms. As part of the Drupal 8 HTML 5 Initiative, one of our goals is to add support for all of these elements and attributes. For detailed browser support information and demonstrations, visit http://wufoo.com/html5/.

Proposed plan

  1. Create an issue for the implementation of each element.
  2. Implement the elements in core, starting with the basic ones first.
  3. Look for legitimate uses for the elements in core and implement them.
  4. When issue is fixed, add issue to the HTML5 FAPI change set.

Point Person(s)

Related Issues/Discussions

HTML5 Field Widgets

NameIssue(s)
color#1740438: Add a new color field type
email#1668332: Move E-mail field type into core
number#1519852: Use the new number FAPI element for the number field textfield widget
range
tel#1740470: Add a new phone number field type
url#501434: Move Link/URL field type into core

HTML5 Input Types

NameSpecificationIssue(s)
colorWHATWG | W3C#1445224: Add new HTML5 FAPI element: color
#1675000: Allow selecting an alpha channel for the color FAPI element
#1651344: Use color input type in the color.module
dateWHATWG | W3C#1496632: Add new HTML5 FAPI Element : date
datetimeWHATWG | W3C#1496644: Add new HTML5 FAPI Element : datetime
datetime-localWHATWG | W3C#1496652: Add new HTML5 FAPI Element : datetime-local
monthWHATWG | W3C#1496682: Add new HTML5 FAPI Element : month
weekWHATWG | W3C#1496686: Add new HTML5 FAPI Element : week
timeWHATWG | W3C#1496708: Add new HTML5 FAPI Element : time
emailWHATWG | W3C#1174620: Add new HTML5 FAPI element: email
numberWHATWG | W3C#1174640: Add new HTML5 FAPI element: number
#1519720: Remove element_validate_integer() and element_validate_integer_positive() replace with number element type
#1527988: Missing or legacy number validation
#1540174: Some attributes not allowed for the new HTML5 input elements
rangeWHATWG | W3C#1174646: Add new HTML5 FAPI element: range
#1540174: Some attributes not allowed for the new HTML5 input elements
#1539820: Browser stylesheet of some webkit based browsers hides range element
searchWHATWG | W3C#1174628: Add new HTML5 FAPI element: search
telWHATWG | W3C#1174634: Add new HTML5 FAPI element: telephone
urlWHATWG | W3C#1174630: Add new HTML5 FAPI element: url
NOTE: Here's a simple module JR wrote to test the new input types.http://drupal.org/node/1496644

HTML5 Input Attributes

NameSpecificationIssue(s)
acceptWHATWG | W3C
autocompleteWHATWG | W3C#1275764: Allow FAPI usage of the autocomplete attribute
autofocusWHATWG | W3C#1174936: Allow FAPI usage of the autofocus attribute
dirnameWHATWG | W3C
list (datalist)WHATWG | W3C
formactionWHATWG | W3C
formenctypeWHATWG | W3C
formmethodWHATWG | W3C
formnovalidateWHATWG | W3C
formtargetWHATWG | W3C
maxWHATWG | W3C
minWHATWG | W3C
multipleWHATWG | W3C#625958: Support Uploading Multiple Files for HTML5 Browsers via #multiple attribute
novalidateWHATWG | W3C
patternWHATWG | W3C#1174766: Support the #pattern FAPI property for native HTML5 pattern attribute
placeholderWHATWG | W3C#1174694: Allow FAPI usage of the placeholder attribute
#1241938: Add support for #placeholder to relevant Field API widgets
requiredWHATWG | W3C#1174938: Natively support the HTML5 #required FAPI property
spellcheckWHATWG | W3C
stepWHATWG | W3C#1174640: Add new HTML5 FAPI element: number

New HTML5 Form Elements

NameSpecificationIssues(s)
keygenWHATWG | W3C
meterWHATWG | W3C
outputWHATWG | W3C
progressWHATWG | W3C#1477550: Bring progressbar to the postmodern era

JavaScript fallback for HTML5 elements in non-supported browsers


Overview

Most browsers support the new HTML5 elements already. However, Internet Explorer versions 8 and below do not recognize the new elements, such as <section> and <article>, and don’t allow them to be styled with CSS by default. This could have been a major blocker for HTML5 adoption. Luckily, back in 2008, Sjoerd Visscher, commented that there is an easy solution for this problem:
Btw, if you want CSS rules to apply to unknown elements in IE, you just have to do document.createElement(elementName). This somehow lets the CSS engine know that elements with that name exist.
Afterward, John Resig wrote a blog post about it in which he named the technique HTML5 Shiv. Remy Sharp then created the HTML5 Shiv script using that technique, along with additional fixes for printing in IE by Jonathan Neal. The HTML5 Shiv has since become the De-facto standard among developers for overcoming this problem.
Although Drupal 8 will not be released for a couple of years, IE 8 will be with us for a while. IE 9 requires the Vista operating system, and IE10 will require Windows 7. According to Wikipedia, ~40% of Windows users are using Windows XP, which Microsoft intends to offer extended support for until 2014.
There is one caveat to using this technique: it only works when JavaScript is enabled. However, this is not of great concern given recent studies on how many users actually browse the web with JavaScript disabled. Below are details of 2 studies completed recently:
These studies (which are not limited to any specific browser) indicate that no more than 1-3% of users have JavaScript disabled. When we take into account that the HTML5 element issue only applies to Internet Explorer 8 and below, those numbers get even smaller.

Proposed Solution

Include the HTML5 Shiv script to solve the problem out of the box with Drupal core. Consider the use case of Internet Explorer 8 and below with JavaScript disabled an edge case that we don’t need to worry about in Drupal core.
Of course we cannot dictate the requirements of those using Drupal in the wild. If the need arises for this edge case to be supported, the Legacy theme will exist in contrib to solve this problem.
The following links refer to issues where discussion and actual changes related to this topic are being held. Feel free to get involved by commenting on them: