Drupal HTML5 Guiding Principles

Events happening in the community are now at Drupal community events on www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Here are the principles we will follow when developing HTML5 functionality for Drupal.
These principles are open for discussion here in this wiki.
Please add your feedback below.

10 GUIDING PRINCIPLES
1. Support older browsers.
2. Lean into the diversity of devices.
3. Maintain existing functionality.
4. Perform.
5. Be accessible.
6. Get semantic.
7. Fulfill the common use case, not the edge case.
8. Mimic XHTML. Be HTML.
9. Value findability. Not mythology.
10. Value practicality over purity.
11. Support evolution.

10 GUIDING PRINCIPLES
0. HTML5ify
HTML5 is the future.
It's ready now.
Drupal core should output HTML5 markup and use HTML5 APIs.

1. SUPPORT OLDER BROWSERS
Remain fully compatible with Internet Explorer 6, 7, 8 and other older browsers.

2. LEAN IN TO THE DIVERSITY OF DEVICES
Drupal websites do not have to work or look the same on every device. They already don't.

3. MAINTAIN EXISTING FUNCTIONALITY
To swap-out existing technology with HTML5-powered replacements, polyfills are required.

"POLYFILL"
OPTION 1
Use HTML 4 default and nothing else
OPTION 2
Use javascript to implement the better UX for all browsers. Works if javascript support is on. Falls back to option 1.
OPTION 3
Use HTML5. Older browsers look like regular XHTML search box. Newer browsers get the better thing.
OPTION 4
Use HTML5 plus a "polyfill". Basically Option #3 for modern browsers plus #2 for
older browsers. Falls back to #1 for IE w/o js.
3. MAINTAIN EXISTING FUNCTIONALITY
Use polyfills when replacing existing functionality with an HTML5 implementation.
Consider polyfills for new functionality on a case-by-case basis, leaning towards simplicity.

4. PERFORM
Slow performance is a problem.
HTML5ifying Drupal cannot make Drupal slower.
If fact, there are a lot of things about HTML5 that could make Drupal run faster. Let's do that.

5. BE ACCESSIBLE
If a choice has to be made between the recommendations of HTML5 spec authors and accessibility experts, choose the accessibility experts.

6. GET SEMANTIC
Historically, getting Drupal to output semantic HTML has been a very low priority. To do HTML5 well, content must be marked up semantically. This is a chance to get serious about valuing semantics.

7. FULFILL THE COMMON USE CASE, NOT THE EDGE CASE
If certain markup makes sense for the majority
of usecases, but not all, let's do it. It can be overridden for the rest. Choosing to be super generic instead is not a solution for anyone.

8. MIMIC XHTML.
BE HTML.
Use XML syntax in forming our HTML.
Quote our attributes. Use lowercase.
Everything we are already doing.
*although maybe make an exception for boolean attributes like 'pubdate'
Do not do XHTML5. Period.
Meaning no mime-type of "application/xml"

9. VALUE FINDABILITY. NOT MYTHOLOGY.
Look to web standards leaders,
not the SEO industry,
for information on best practices.

10. VALUE PRACTICALITY OVER PURITY.
Just like the Design Principles of HTML5.
If we have to ‘cheat’ to make it work, oh well.
*We already have hacks to make it work in IE, why is this a time to get purist?

11. SUPPORT EVOLUTION
We will keep changing Drupal's "HTML5y-ness" over time.
It's not all or nothing.
It's a process.

HTML5

Group notifications

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