Decide how to use HTML5 in Drupal 8

Yes! And thanks for setting up an issue on this so we can make a decision early in the D8 development cycle.

I really don't see why Drupal itself should stick to XHTMl doctype. Doctypes do not control if a document is interpreted as XHTML. Also, XHTML web-standard practices are valid in HTML5. I do not see this as a stumbling block for Drupal itself. It is likely that some specific usecases for Drupal might stil want to use the polyglot version.

I definitely support this, and clearly lots of work has already started in contrib, getting ready to do this. It's a no-brainer, as is Including support for ARIA roles, given it that it will become a recommendation.

What I don't know is how RDFa will be affected. I think that preserving the work done for RDFa is very important, and I'm really dying to know what the deal is already.

Short answer +1 to using html5 in Drupal 8.

Long answer:

1. html5 has richer semantics than xhtml
2. ARIA validates in html5.
3. html5 is backward compatible with xhtml, any valid xhtml document is a valid html5 document.*

But,

4. I question how browsers like IE will render / display html5 pages. It is possible that when switching the doctype to html5 that there will be cleanup that needs to be done to fix buggy UA implementations.

* I believe that the img element's @longdesc attribute (not used in core, or any contrib modules I know of) does not validate in html5.

Yes absolutely! There's growing momentum in the Drupal community too.. There's http://groups.drupal.org/HTML5 , and viable HTML5 themes are already being released (see Boron and HTML5 Base). We won't have to choose between validation and WAI-ARIA. HTML5+RDFa is supposedly in the works, though I can't seem to find actual examples of what it will look like. But HTML5 is our future.

whoops, in-flight collision

The only concern I have with this is HTML5+RDFa. That's a blocker. Otherwise, I'm all for this.

Hmm… actually, I take back the "That's a blocker." If it comes down to RDFa and XHTML vs. accessibility and HTML5, the real concerns about real people (accessibility) outweigh the requirements of a bleeding-edge, not-globally-implemented technology (RDFa).

Once we decide on whether Drupal 8 defaults to HTML5, we should implement it (even at the cost of breaking RDFa) and then figure out how to get RDFa working with HTML5 (if needed).

Spam, can someone delete the comment #11. Where's mollom when you need it.

@Jen

When talking about html5 I assumed that we were all talking about xhtml5. I am not in support of D8 using html5, but am fully in support of xhtml5.

For those unaware, html5 has two variants, the html version and the xhtml version:

XHTML 5 is the XML serialisation of HTML 5 and, as you’d imagine, it has all the stricter parsing rules that you’d expect (and are used to if, like me, you grew up with XHTML DOCTYPES).

(http://html5doctor.com/html-5-xml-xhtml-5/)

HTML5 doctype (not XHTML5) would be a great improvement as far as I'm concerned. According to Opera's research, less than 50% of the pages that they tested which included a "valid XHTML" icon actually validated. For CMS's such as WordPress, Joomla, and Typo, the rate was significantly lower.

I am sure that is true of Drupal sites as well, even if the theme layer itself produces valid markup (which is, sadly, not always the case with contributed modules). Even if we could be assured that all Drupal modules would produce valid markup under all circumstances, and site users would write valid XHTML themselves, sites can still easily become invalid due to ingesting aggregated content (from RSS feeds, etc.)

We are just fortunate that mainstream web browsers don't produce the "yellow screen of death" when they hit upon a page with invalid markup according to the declared doctype. If they did, the Web would essentially be broken.

I would argue that we should move to straight HTML5 doctype, and stop lying to ourselves about the importance of XHTML strict validation.

That said, I believe Drupal's core modules and themes should stick to the best practices for markup which Jen Simmons has mentioned, and contrib modules should be urged to follow in their footsteps. But, to my mind, continuing to enforce XHTML doctype by setting in the core tpl.php is like saying that PHP should fail to parse code that doesn't follow the Drupal coding standards.

I can't think of any blocker when it comes to HTML5+RDFa, RDFa 1.1 has been designed for HTML5 and XHTML5 and will definitely be published by the time Drupal 8 is out: http://dev.w3.org/html5/rdfa/

It'll be very similar to RDFa 1.0 which we use in Drupal 7, just a few minor changes in the syntax.

HTML5 isn't supposed to hit the Last Call Working Draft stage until mid 2011, and Candidate Recommendation stage until at least 2012. After reaching Candidate Recommendation, it'll take 2 complete, fully-interoperable implementations of the spec as it is then for it to reach Recommendation stage.

From the spec itself:

Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.

With a large project like Drupal that affects tens of thousands of sites, and W3C specs as they are being open to very subtle interpretations, we shouldn't be so cavalier in adopting a spec that won't even be complete by the time Drupal 8 enters code freeze.

That is, if Drupal 8 is going to be released before 2013, I think jumping on board with HTML5 is a recipe for disaster. Contrib seems to be taking the HTML5 ball and running with it in the meantime: why isn't that enough?

The calender estimates are a bit of a red herring. The last-call deadline, Oct 2009, has already passed. There is no magic date at which HTML5 will be "ready" in it's entirety. Instead, we would likely evaluate features individually for browser support and stability before adopting them in core. For example, we might decide the <footer> element is acceptable in core, but the draggable attribute isn't.

To put things in perspective, CSS 2.1 just became a candidate recommendation in April 2009. That didn't stop us from using it successfully, however. Even Drupal 5.0 contains CSS 2.1 values.

A few points of clarification:

1. The WHATWG declared last call in October 2009, but the W3C just started compiling issues for the Last Call document, to be released in May 2011; at that time HTML5 will enter Last Call Working Draft stage. One of the issues with HTML5 is that of control between WHATWG and the W3C.

2. CSS 2.1 first entered Candidate Recommendation stage in 2004, not 2009. Last Call was in 2003, and it went through several more revisions as vendors raised issues. Microsoft did not attempt to be mostly compatible with the spec until Internet Explorer 8, released in 2009.

"One of the issues with HTML5 is that of control between WHATWG and the W3C."

There really is no issue of control. Each group has its own document, and they are very similar to one another. There are clearly some exceptions, but again, I don't see any problem with us adopting xhtml5 for D8. We will simply look at what has been implemented from the W3C (HTML WG) draft and use those components.

I suppose that we could extend this discussion to decide if we will adopt the WHATWG or HTML WG draft, but I believe the result will be almost certainly HTML WG (W3C).

I confirm this opinion, as long as some browser like ie6 (yes and it´s a shame)/7/8 exist with more like 5%-10% usage there should be something like a fallback-solution.

@Jen

I like your suggestion. We should use the html5 doctype, but all markup in core should be valid xhtml5. I believe that this forces core to be well formed markup, while providing flexibility for imperfections by themes / modules / content authors.

When people talk about the benefits of HTML5 (such as the semantic markup mentioned in this issue), they mainly talk about the parts that older UAs (like Internet Explorer 6, 7, and 8) can't handle without kludges like the HTML5 shiv.

Sticking with the parts of HTML5 that are backwards-compatible with UAs that don't support the entire spec leads me to wonder what's the point? In that scenario, Drupal would be HTML5 only in the sense that it uses <!DOCTYPE html>. It'd leave open the door to misinterpretation: if Drupal 8 is HTML5, why can't all parts of the spec be used?

Instead, we should avoid trying to ride the trendiness of HTML5 now and think about supporting what actually makes sense and can easily be explained in a coding standard. I think dumping XHTML is smart for all the reasons everyone's already mentioned, but if we're not going to use any of the new stuff that HTML5 provides, let's use HTML 4.

Glad that I was understanding you correctly, @jensimmons :) That is precisely what I think we should do: write/generate valid XHTML markup but use the regular HTML5 doctype.

@Mark Trapp, I don't think that we need to hold off on using the HTML5 doctype. It'll be probably at least 2 years until Drupal 8 comes out, realistically, if the release cycle is anything like this one was. The spec should be pretty stable - it looks like it's gaining adoption faster than CSS2 did (perhaps Microsoft is finally starting to come in line?). Core probably won't have occasion to use most of the new features of HTML5, but using the new DOCTYPE will be an advantage in itself, since the goal of W3C now, I think, is to create a flavor of HTML that reflects actual usage.

In the handbook, we could advise module developers to alert users to potential browser incompatibility issues if they chose to use things like the <video tag in their module's code, but at least this way they wouldn't have to worry about making users switch to an HTML5 theme.

@EvanDonovan That makes sense.

I think my issues have been addressed: as long as the switch to HTML5 means we aren't dropping support for UAs that don't support it entirely, we avoid the use of shivs/enabling scripts in core, and it's made absolutely clear that the switch to HTML5 isn't free license to use everything in it or as a means to make an ideological stance against those who stick with older or non-compliant UAs, I think the DOCTYPE switch is good. And I am 200% on board with dropping the XHTML requirement and using standard HTML.

So is the main stumbling block RDFa and similar features in core.
I'm having trouble seeing why we shouldn't move forward with HTML5.
Surely the markup and all attributes should be themable and it should be up to the theme to decide which version of HTML to use. If the theme decides to use HTML5 and support IE6 then it can add the shiv or whatever.

@taslett - in #15 @scor says:

I can't think of any blocker when it comes to HTML5+RDFa, RDFa 1.1 has been designed for HTML5 and XHTML5 and will definitely be published by the time Drupal 8 is out: http://dev.w3.org/html5/rdfa/

It'll be very similar to RDFa 1.0 which we use in Drupal 7, just a few minor changes in the syntax.

So, RDFa is not a stumbling block. We just don't know exactly what the syntax will be (yet).

I don't think anyone here is saying we shouldn't move forward with HTML5. I think we're all just making sure we are on the same page with goals, and with what switching to HTML5 actually means. :)

@taslett: to be clear: dropping support for non-compliant browsers (IE6-8) in core or requiring a shiv to support them is exactly the thing we should be avoiding, at least until HTML5 hits Candidate Recommendation. But I don't believe that's what people in this issue are suggesting.

Using <!DOCTYPE html> doesn't require that; using HTML5-only features does. Core should be sticking to features that are already implemented in HTML4, but switching to <!DOCTYPE html> will allow contrib to "opt-in" to the HTML5-only stuff. It shouldn't be up to the theme to "opt-out".

@Mark Trapp: I'm not suggesting we stop supporting IE6-8.

Many of the HTML5 new features are backwards compatible, as far as browsers are concerned. It really shouldn't matter if we use features of HTML5 that were not valid in the HTML4 standard, as long as those features are rendered correctly by the browsers, or degrade to a fall back element or in the case of attributes etc ignored.
The HTML5 shiv only adds DOM support for new elements, (section, aside..) without it IE just ignores the new tags, the content inside is still rendered just without default browser styling or styling through CSS.

I think this is and should be a theme choice.

@Mark Trapp: "Core should be sticking to features that are already implemented in HTML4, but switching to <!DOCTYPE html> will allow contrib to "opt-in" to the HTML5-only stuff." That sounds like a good compromise.

One thing I was thinking about would be to add a $doctype variable to the Drupal theme layer that would be set to <!DOCTYPE html> by default, but which could be overridden in preprocess. That would allow for the most flexibility.

Subscribe

I can't see any hard blockers at the moment, the RDFa stuff is being worked on and afaik will be ready. The big question is which bits to use and whether we should support IE6/7/8 with the shiv - to not to seems rather out of whack with the broader community and knee caps Drupal from using the powerful new sectioning capabilities of HTML5.

Yes to HTML5. Not XHTML5, I agree with @jensimmons and @Everett in #22 and #23.

@EvanDonovan: It seems like the theme layer should control the $doctype. The majority of the HTML output is determined by the theme. Core should output HTML5 that is also valid XHTML. Because if a themer changes to using an XHTML 1.1 doctype, we would want the code that core and FAPI spits out to be valid in that stricter doctype.

@34 - thats going to kneecap HTML5 uptake - think of FAPI where we can start using all the new input types that come with HTML5 which will be invalid XHTML, so I can't really see how that can work. What I think we're driving at here with the dicussion regarding xhtml is syntax - use a single well defined syntax because HTML5 is free and easy with the syntax which would lead to a plethora of coding styles in Drupal, whereas we want one coding style, and since we're so versed in xhtml syntax we can use that.

@35 - Jeff, I see what you mean and I think you've convinced me. Once core and FAPI start outputting HTML5 we can follow syntax and coding standards, but we cannot easily validate as XHTML.

If FAPI in core starts using new HTML5 input types, will IE6/7/8 gracefully degrade?

@brandonojc: IE, and all browsers that don't understand the new HTML5 input types, degrade any type they don't recognize to <input type="text">. For certain input types (like email or number) that isn't too much of a problem, for others (like color, range, or date) it's not the user experience one would hope to get. In any case, all the benefits of switching to them (UA validation, semantically relevant native controls) would be lost on browsers that don't recognize them.

This doesn't affect <input> elements, but allowing HTML5 in core presents other problems for IE (and certain older versions of Firefox): they don't style elements they don't know about at all (IE) or correctly (old Firefox), and require a JavaScript shiv in order to do so. There is no non-JavaScript fallback (well, there is, but it requires HTC and doesn't work all that great). See How to get HTML5 working in IE and Firefox 2 for an overview of the standard means to get HTML5 elements working properly in IE.

I don't see how core not using those elements "kneecaps" anything. Contrib would still have full license to use them, just like the Elements module does now. Core can enable that type of development by defaulting to a lax DOCTYPE, so if a person wants to use a module that takes advantage of HTML5-only stuff, they only need to enable it (instead of having to modify their theme as well, like they do now).

@Mark Trapp, that sounds like the way forward.
The form elements that don't degrade as text fields (color, range, date), aren't supported by many of the browsers with good HTML5 support. So we would still be using jQuery UI etc to get around those. I don't see that as a problem.

Yes move to HTML5 . Why we want to wait ?

Lets jump into it . If you are looking to implement HTML5 now then http://html5boilerplate.com/ this will help you ;) .

Linking to a related issue #675348: META: Support HTML5 form input elements, also subscribing :-)

Oh and I might as well chime in. :)

I don't think the html 5 form api elements should be discuss in this issue as there's already an issue for that. But I'll comment on here anyways. Drupal 8.x should suport the html5 form elements out of the box, at least the most common ones, and we really don't need to worry about ie 6.x not recognizing an email field or worry about having to use any shiv, mainly because we do most of our styling with classes not with input type. So the email input type with the class "email-field" will get styled the same in ie6 vs Chrome.

The big issue really is having the default Drupal theme doctype be html by default. Which I really think we should. :-D

I think the question here is to use HTML5 doctype. HTML5 doctype triggers the standards mode in ALL MAJOR browsers: IE, Firefox, Safari, Chrome & Opera. There are wider questions to consider:

1. Should XHTML be used - means stricter use of syntax, and if sent with the right content type, yellow screen of death.
2. Should themes use HTML5 elements?
3. Should the forms use HTML5 elements?

So here's an actual Proposal:

Mark Up:
- Have the default theme use the html5 doctype.
- All markup should still confront to the strict syntax is defined by the Drupal Coding Standards.
- Avoid the new mark-up elements such as section and such in core. (Read through the whole thing before judging this decision :-p )

Elements:
- Declare these new elements in Drupal Form API
- email
- search
- url
- number
- Leave the other elements to declare by the Elements module because of lack of support, and there's no use case for them in core.
- Switch all Drupal Standard forms to use the new elements where appropriate. Same thing the html5_tools module does.
- In other words switch the search form to use the search element instead of the textfield, etc....
- Make sure all the css is targeting the elements class.
- So by default the css for the new elements such as form-email, form-search, form-url, form-number should be the same as form-text.
- Leave it up to the theme to change the implementation.
- This allows the elements to be fallback to a textfield in unsupported browsers without us having to worry about anything.

If we follow this approach we'll be using the new html5 elements in core with the added functionality for new browsers and yet we loose 0 functionality for old browsers. This also minimized the amount of hacks we have to do (0). As we start implementing only the bare minimum.

Some obvious things I left out is the used of the sections and such tags. I think contrib themes should definitely start using it but core should wait a bit. The reason for this is to minimize the amount of work we have to do to support older browsers and also a lot of that is still up in the air to be decided. If we start small with the most common stuff in, we're better off than trying to get an entire unfinished spec in. Also this would allow us to not worry about hacks and stuff. Contrib can handle this better than core.

I think for now this is a good starting point. The reason why the specification is so loose is so we can start to move in the right direction at our own pace. :-)

The first two things are the main point:

- Have the default theme use the html5 doctype.
- All markup should still confront to the strict syntax is defined by the Drupal Coding Standards.

However the rest I think its too early and probably the wrong place to be discussing these things. With the first two points I think we have a good recommendation to the Drupal 8 maintainers to move forward with HTML5. We have, and it will likely take, the next two years to work out the finer details.

Note: I assume by default "theme" it is meant "Drupal cores default templates, namely html.tpl.php".

@jeff_Burns : I'll take what I can get. :-)

Agreed with Jeff Burnz in #43. The other details in #42 sound good to me, but I think that Jeff is right about more discussion being needed when we start working on D8.

Thanks for the redirect, @jensimmons :)

I think that we should use the doctype, definitely, but not sure on the rest.

Form fields would be a possibility, but in probably the "second-tier" of core modules, so that users of Drupal would not be forced to use them if that would cause issues with compatibility with legacy browsers, etc.

Markup should continue to follow XHTML coding standards, though I don't think we should use the XHTML serialization of HTML5.

Not sure entirely what you mean by head info formatting.

APIs I think is a definite no, since there is no "opt-out" provided then.

There are some APIs that could be used as progressive enhancement, such as local storage. I'm not sure if there are any good use cases for this in core, but provided that there are it could be tested for and used to enhance some UIs.

One potential use for local storage would be to save partially completed form data, to prevent its loss if context is changed.

Oh, I see what you mean now - the HTML5 APIs. Sorry, I had forgotten about those. I thought you meant adding HTML5 markup to Drupal API functions.

I agree that some of the HTML5 JS APIs might be beneficial, but am not particularly familiar with them.

IMO we should use the new markup, unabated, and use the shiv. Simple reason is this - if we don't do it now - then when? When IE6/7/8 are dead and IE9+ dominate IE usage? IE6/7/8 are not suddenly going to start supporting HTML5 elements, nor are they all going to die out any time soon. For the raw sectioning grunt and killer elements like <hgroup> IMO this is just a no brainer, and the current best practice (use the shiv). Again, to you peeps against this - if not now, then when? 2022?

@Jeff Burnz: now or 2022 is a false dichotomy. Some time after Drupal 9 development opens up, HTML5 will be a candidate recommendation and we'll likely only need to worry about IE 8+ support. If Drupal 9 isn't slated for release until 2022, I think Drupal has a bigger problem than fully embracing HTML5.

Using a shiv is a mistake for so many reasons it shouldn't even be considered, not least of which they don't actually solve the problem and allow us to use the entirety of HTML5. The shivs as they are now allow one to style elements that are completely unrecognizable to older browsers. They don't provide any of the new APIs and the elements are still semantically meaningless to the UA.

My recommendation is similar to ericduran and EvanDonovan's recommendations:

• Use <!DOCTYPE html>,
• Continue to use the XML serialization in the Drupal coding standards,
• Provide the HTML5 form elements as options in the Form API so they are available to contrib, but avoid gratuitous use of them in core, and
• Avoid the use of anything that's HTML5 that doesn't have a first-class fallback and requires us to maintain a "legacy" version of the functionality (i.e. only use progressive enhancements). Things like cache manifests, offline storage for saving forms, etc would be okay; the new HTML5 elements, WebWorkers, WebSockets, the new File API, etc. would not. The things not available to core can still, of course, be easily implemented and proven in contrib.

One thing I'd definitely like the see us incorporate into Drupal 8's caching system is the use of offline storage, specifically the use of cache manifests. It's pretty easy to implement, is purely a progressive enhancement, and would help to solve a range of caching concerns.

OK, to answer Jens questings in #53.

I took a bit of a gamble and wrote the D7 version of Adaptivetheme in HTML5, new elements and all. The upshot is that as of now I have around 150 sites running this theme (mostly the D7 version of Pixture Reloaded which is an Adaptivetheme subtheme in D7). At a guess within one year this theme will probably have around 3000 users, within 2 years more than double that. I mention this because this is a grand opportunity to see HTML5 in real sites, now and over the next 2 years, in a large number of sites.

The outlining and sectioning is awesome - however its a reasonably complicated theme and many of the templates have conditional elements. So the templates for HTML5 are likely to be more complex - there are more things to think about when using sectioning elements. There is more power, but also more complexity.

RDFa at the moment is a problem, but this will be resolved. What I have done is to make the doctype, html element attributes and other header stuff conditional on the RDF module being enabled. This is so you can validate the theme by turning off the RDF module. Later when the HTML5/RDFa spec is more developed and the doctype issues sorted out hopefully this won't be a problem we have to worry about in D8.

ARIA roles, while not being part of HTML5 are worth a mention because they are valid in HTML5 - so we'll need to be thinking about how they are included, probably via attributes arrays, so maybe all or at least more wrappers will get an attributes variable.

We'll also need to be looking at Assistive Technologies such as Jaws, NVDA, Windows Eyes, Voice Over etc and how they are handling HTML5 and ARIA.

Those are some of the issues I have faced, and to sum up I would say, in my experience so far:

1. Sectioning is too powerful and useful to ignore, all the new generation browsers (FF4, Safari5, IE9 etc), and all Apple mobile devices support HTML5 elements right now.

2. Use of the shiv to support older browsers is a non-issue (its 1kb of JS). We could even consider going further and incorporating new technologies like modernizr as these are becoming the current best practice. I can see UA capability detection being incredibly useful for many modules.

3. Templates tend to get more complex (even more like PHP scripts, less like real templates).

4. RDFa is an issue that needs resolution. Need to work with RDFa peeps and keep an eye on microdata and how that whole deal plays out.

5. Think about attributes variables more and how to incorporate ARIA roles.

6. Accessibility review and testing needs to be an intrinsic part of the process.

7. Think more broadly than just HTML5, but to all the modern technologies and how they intertwine in modern web development (HTML5, ARIA, CSS3, UA capability detection, responsive web design, mobile web devices); we're entering a time of very different rules wrt building modern websites and we need to think broadly, don't bog down in HTML5 yes/no mentalities.

Any reason why this is for Drupal 8 and not Drupal 7? By the time Drupal 8 comes out, HTML5 will be old. Seems like a major oversight for Drupal 7.

HTML5 requires at least RDFa 1.1. Is this something to be done with the RDF Module in contrib? Seeing how its hardcoded into html.tpl.php, it makes this seem unlikely. Do we really want to be stuck with RDFa 1.0 throughout the Drupal 7 lifecycle?

I must agree. This almost feels like a critical D7 issue since we effectively closed doors for HTML5 in D7 by using RDFa 1.0.

Currently "Drupal 7 + HTML 5 = no go".

Drupal 7 is feature frozen, and in rc. I doubt that we can do anything except in contrib space for D7. You can use HTML5 in Drupal 7; just don't use the core RDF module without overriding in html.tpl.php.

Sorry guys. I like HTML5, but really it's still in draft, right? http://www.w3.org/TR/html5/

@Jeff Burnz has been good enough to put out a HTML5 version for D7 http://drupal.org/project/adaptivetheme and I expect there will be others.

Moving the core form elements over to HTML5 is a shit load of work. Not that it isn't work that will need to be done, but let's wait till the standard is standardized first.

If Drupal 7 is released in the next ten days it'll probably still be before HTML5 is finalized. We can't wait another 6 months to get Drupal 7 out the door, or tie our release schedule till when an international standard gets finalized.

we effectively closed doors for HTML5 in D7 by using RDFa 1.0

Not at all. Most of the RDFa 1.0 specific markup is built in the core tpl files, which you can overrride in your theme (you will need to override them for the doctype at least anyways). I can only think of one RDFa attribute coded in the RDF module which is no longer necessary in RDFa 1.1, but the markup is still valid and leads to the same RDF output. There is not that many changes from RDFa 1.0 to RDF 1.1 (at least for the way we add RDFa in core).

Here's a good example of HTML5 and RDFa 1.1 that I ran across: http://www.3kbo.com/examples/rdfa/simple.html

It uses the following code at the top:

<!DOCTYPE html> 
<html version="HTML+RDFa 1.1" lang="en"
	xmlns="http://www.w3.org/1999/xhtml"
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
	xmlns:cc="http://creativecommons.org/ns#"
        xmlns:dcterms="http://purl.org/dc/terms/" 
	xmlns:foaf="http://xmlns.com/foaf/0.1/"> 
<head profile="http://www.w3.org/1999/xhtml/vocab"> 

As Elements module maintainer, subscribing

Currently the Bartik theme uses the wrong MIME type. If you have the XHTML doctype and XHTML syntax, then you have to use the application/xhtml+xml MIME type. Or else there is no point in using the XHTML doctype.

Why would you send an XML document in the text/html MIME type? I don't understand it. Similarly, if you have a webM video, you have to use the video/webm MIME, not video/mp4, that is obvious.

Why does Bartik use the wrong MIME? Either change everything to HTML 4.01 and use the text/html MIME, or use XHTML with RDFa and the application/xhtml+xml, or use HTML5 with RDFa and text/html.

#1000308: Use the HTML5 doctype

@Bence: I've replied to your question at #1000308-4: Use the HTML5 doctype, we should focus on Drupal 8 now...

My suggestion is the following:

First, we have to do the basics before we can continue:
- Use the (X)HTML5 DOCTYPE (to put browsers into standards compliance mode)
- Require the strict XHTML5 syntax. (trailing slashes required and no attribute minimisation.)
- Serve it with the html(5) mime-type (preventing unreachable sites when there is an error on the page.)
- Include a shiv in core. (Sadly, IE9 won't be compatible with Windows XP.)
- Update other areas of core to conform to this (RDFa Update etc., No New FAPI Elements etc.)

The result of this is a polyglot HTML5 & XHTML5 document, that can be properly read by any browser, and can be serialized by an XML interpreter, the best of both worlds. These are the things that I consider critical to use HTML5 in D8

After the foundation is done, we can move more to actual HTML5 usage, like the new elements etc.

There is good reading in the following:

http://wiki.whatwg.org/wiki/FAQ
http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Differences_Between_HTML_and_...
http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-gui...

For the people advocating putting a shiv in core: how do you expect to provide a no-JavaScript fallback? Or is the implication that Drupal 8 and later should be JavaScript-required?

I don't think there's any need for the shiv as most of drupals css doesn't really target elements directly.

@alexanderpas: If this is a silly question, pardon me: but would serving with the html5 mime type + the other things you outlined mean that invalid XML would cause the page not to render at all? If so, I think that would be unacceptable, since we can't really control the output of contrib modules, WYSIWYG editors, ingested RSS feeds, etc. If Drupal pages started not rendering because they were semantically invalid, then it would get blamed on Drupal even if it wasn't our fault.

On the other hand, if pages would still render, then I am fine with whatever. That is my main concern.

-1

XHTML1+RDFa is superior (X)HTML5, both in semantics, backward compatibility and formatting.

it's only a problem with no-JavaScript on IE 6, 7 and 8. I think most people who use the shiv figure that's a rare-enough use case...

That is my view and essentially what I have gone with in my themes, I think we should see how this plays out in the real world before concluding no-js is actually a problem. I understand the fear because if you use elements like header, footer, section and so on as styling hooks indeed the page blows to pieces in IE6/7/8 if that shiv doesn't load.

What we could do is keep those new elements out of the default templates and the default D8 theme, but include a new theme in D8 that is fully HTML5 and uses the shiv. We have options.

@72 - what makes you think we can't have HTML+RDFa 1.1 in D8?

1. It's still under dev and isn't going to be released soon.
2. It's based on HTML5, not XHTML1 or that family.

@JimmyAx: 1. this issue is about Drupal 8, which does not have a release date planned yet, but I don't see it being release before maybe 2 years. I would expect both HTML5 and RDFa 1.1 to be long ready and published by then.
2. I'm assuming you're following up on what you said in #72: "XHTML1+RDFa is superior (X)HTML5, both in semantics, backward compatibility and formatting." I don't agree with you here, RDFa 1.1 in HTML does not cut down on the semantics you can express wrt to RDF, and the RDFa WG is working hard to keep RDFa 1.1 backward compatible with RDFa 1.0 (it's part of their charter). In other words you should be able to embed the same RDF data whether you're using XHTML or HTML5. Please expand if I misunderstood you comment.

I can repeat what I have said in Coppenhagen, on gdo, on IRC and will repeat as a parrot until someone proves me wrong.

1. It should be possible to create a HTML5 theme for Drupal 7 in contrib. If not, that's a bug needs to be fixed.
2. There is no HTML 5 standard yet.
3. Even what exists is not supported in the majority of the browsers used by people.

jensimmons tell me that I am wrong and by 2012 there will be a candidate recommendation and browsers actually degrade nicely.

Well go for it. However, make a decision and do not try to create code that emits this or that tag, per tag as that'd kill performance. Rasmus himself warned us about per-function-per-HTML-tag. Second, make sure you only do usable things and not pie-in-the sky. I feel like we have a real lot to do UI without chasing HTML5 but I might be antiquated, the two might be parallel and so on.

I again wish for an unsubscribe feature.

@chx re "do not try to create code that emits this or that tag", are you talking about something like what views does, such as <?php print $field->inline_html;?> or perhaps placing conditions, for example print this or that tag depending on some other output?

I think that we have to go in this direction: HTML5+ARIA. It'll improve accessibility in Drupal core and contrib, and we'll create a good base to build not only advanced web applications but modern+accessible+advanced web application.

+1 for me

Finally someone -- amateescu -- took the effort (took seven minutes or a bit less, mind you -- I am not that daft) to explain what is going on with these newfangled tags. Apparently, even IE6 allows you to CSS anything that looks like a tag (just needs a little JavaScript help). So, <nav> will look much like a <div> because it will be styled so. You can see the CSS at http://html5boilerplate.com/. Easy! Go ahead. I was afraid you will do some sort of magick where you will emit <div> for IE6 and <nav> for newer browsers but if you don't -- go ahead.

Edit: jensimmons tells me that without that JS, we still can address these elements by id and classes -- the JS is only needed to use the element names as CSS selectors.
Edit2: http://ejohn.org/blog/html5-shiv/
Edit3: The shiv builds on an IE6 bug but who cares? The world is CSS'd already based on IE6 bugs so what. Or it might not even be a bug more like an unspecified behaviour: the default SGML behaviour is to ignore unknown tags and apparently after a createElement it's not unknown any more. One might argue that createElement should not create anything that is not in the DTD -- on the other hand remember the first HTML DTD and you will see why that did not happen. The only thing that matters is that it works.

80 comments and I've not seen one good argument why we shouldn't do this - and plenty of good ones, plus suggestions for how, on why we should.

HTML5 doctype++

It's not just a few new tags in themes, form API will need updating etc - it's all been spelt out well above - if we don't embrace this at the start of Drupal-8 dev it will be Drupal-9 before we can.

Lets continue to embrace the future.

Subscribing.

I support this as well.

However, as mentioned elsewhere already, we need to come up with an actual "battle plan" for introducing and switching to HTML5 in Drupal core. This means we need to create a new "HTML5 in core battle plan" issue that starts with something along the lines of @ericduran's proposal in #42:

1. listing the rough/top priority action items and tasks (bird-level view), including a short summary of what is being meant for each (and what is not meant).
2. listing and summarizing the top FUD items, including a short explanation/clarification for each, optionally linking to a more elaborate explanation elsewhere.
3. listing the currently known major problem spaces, pain points, and debatable discussion items with the transition, including a short summary for each, linking to spin-off issues that have the goal to draw a conclusion and community agreement.
4. containing priorities and rough estimates (in months) for each discussion item and each action item
5. a failover plan in case we do not manage to complete all items within the release cycle. (what must be done, what can be deferred, etc)
6. no personal opinions, only objective and factual statements. Everything that contains "...I [don't] think..." is not objective and requires discussion.

[Note: Ideally use an empty OP and post the plan as first comment instead, so you can update the comment later on.]

Waiting with this in any way (e.g., for the next DrupalCon) would be wrong.

How is this a feature request?

@jensimmons: Thanks for the information. I think it's easy for lots of people to miss things that happen on g.d.o, so sun's comment is understandable. (My knowledge of what was going on didn't really extend past this issue either.)

I do want to thank @jensimmons for her work on educating the community about HTML5. I just joined the HTML5 group on GDO, so am hoping to learn more there. It certainly seems to be rich with information.

We're looking to deploy HTML5 & WAI-ARIA on our new Drupal 7 site (not launched yet, but probably built on AdaptiveTheme) and I know lots of other folks will have implementations of this in both Drupal 6 & 7 before Drupal 8 is anywhere near to a RC state. This will be better tested and the implications/challenges will be better known in live environments well before D8 is released.

Already, "every new Apple mobile device and every new Mac — along with the latest version of Apple’s Safari web browser — supports web standards including HTML5, CSS3, and JavaScript" - http://www.apple.com/html5/

IE still remains a problem (surprise), but heck, seems like IE9 will be coming onboard will big support for HTML5.

And really, since we're probably looking at a 2013 release of D8, let's not judge it on what users are doing now. The vast majority will have moved to a system that has reasonable support for HTML5. Also, liked this site here and had to share it http://html5test.com

Since it seems like there's a broad consensus in this issue, should we mark it as "fixed" and continue the discussion on g.d.o. until there are actionable items for D8?

Just been looking over the jQuery Mobile framework, its based around HTML5.
http://jquerymobile.com/demos/1.0a2/#docs/about/features.html

@jeff Burnz -- I just recent wrote a horrible theme on jquery_mobile. Its pretty hacked up but a nice proof of concept :) -- https://github.com/ericduran/jam

Anyways don't want to sidetrack the actual conversation. :)

You can use all the HTML5 elements with any doctype anyway, and all the modern browsers support it. So the doctype is just a cosmetic thing.

All you need is to trigger standards mode. So as long as you have the standards mode, the doctype can be anything.

So what is the conclusion? Use the HTML5 doctype, because 1) it triggers standards mode, 2) it is the shortest doctype possible. In fact, this is the exact reason why the HTML5 doctype looks like this. The HTML5 authors looked for a doctype which triggers standards mode, and is the shortest in bytes.

subscribing

@ericduran, you should really keep working on that, its very cool but needs some work, great effort dude, really impressive work.

Today I stumbled on http://csswizardry.com/2011/01/the-real-html5-boilerplate/ and thought it worths sharing.

This one could be good when considering accessibility - http://html5accessibility.com/

The WHATWG just published a plain-English guide to HTML5 geared to web authors which might prove useful for background information.

When deciding which parts of html5 to implement we should not only look at browser implementation, but browser accessibility implementation for the component. E.g. if a browser supports video, but does not expose this to assistive technology it should not be supported in Core.

Obviously video is just an example, as this will never be used in Core.

Never have <video> in core! Thats what peeps used to say about image support in core... he he, oh how times are changing... you're bang on though Everett, the link in #95 has a pretty good run down and I've been looking at that for a while, but I'm not sure how up to date it is.

@Jeff

I think that the link in #95 is pretty up to date. Steve Faulkner, I believe, keeps on top of that list, perhaps with the help of some others.

The more experience the Drupal community has with HTML5 the smaller a hurdle it will be to include it as part of core. The more spaces that the community can experiment with HTML5 in D7, the fewer problems issues there will be to include it in D8 core.

I'm excited to work with folks like @Jeff & @Jen who have been working to make it easier for the community to play with & understand this new standard.

OK, in response to suns comment in #83 we now have #1077356: HTML5 in core battle plan, shortly I will post the first draft of the this plan with along with a collection of specific issues posted against various facets of Drupal, not least of which will be FAPI, RDFa and a hard look at Drupals current approaches to markup.

+

Thanks Jeff! Let's close this issue. It's better to have actual action items than endless debate. I really do love the resources posted in this issue though. Let's move those links over to the HTML5 Drupal Group.... #1077356: HTML5 in core battle plan

some reading,
HTML5 vs XHTML5
HTML vs XHTML

i grew up on HTML4.x but then quickly changed to XHTML1.x ;)