I am strongly considering moving to HTML5 for D7, the main thing against me is time (I want at least a really strong RC the day that D7 ships). I have a pretty solid port to D7 underway, but it needs some love to bring it more into line with AT6.x.3.x, which is the new paradigm we'll be running with the for the rest of the D6 life cycle.

I need some help - especially with testing modules etc.

Comments

Jeff Burnz’s picture

My first big question that is still unanswered regards RDFa and how to properly support it, looks like the spec is far from complete and documentation is difficult to interpret. Looks like the Boron theme is trying to solve the same issue.

Jeff Burnz’s picture

I have a test site up and running with Adaptivetheme 7.x using HTML5. Note this won't validate, there is no validator that I know of that can do it, since it runs RDFa + HTML5. Theres a bit of trickery involved in getting this to validate (it won't at all right now, I have some issue with the time element), but I will post a howto on running validation (I can get it to validate HTML5 no problem).

The test site can be seen here: http://bit.ly/9xGxjD

Jeff Burnz’s picture

I got the datetime attribute sorted out for both nodes and comments so the time element will validate now - hooray!

Jeff Burnz’s picture

Title: HTML5 for D7 » Adaptivetheme 7.x will use HTML5
Status: Active » Fixed

After a lot of thought regarding RDFa (my big sticky point) I have made the plunge and decided to bet the house on HTML5.

The code in HEAD at the moment is HTML5. I have made the changes over the past week and also will update Pixture Reloaded D7 version later today (I have been using this as my test subtheme for the entire dev cycle).

As previously mentioned I will document how to validate this theme - it is possible to validate it and I will write it up in a help page.

I am very happy to be running on HTML5 - I hope you enjoy the challenge also.

dcrocks’s picture

You put ID's on all your 'semantic' elements. I don't think you use them for styling but don't understand the purpose.

Jeff Burnz’s picture

We have ID's on some elements to make targeting them easier, for example the page footer:

#page footer - this is going to target all footer elements in the document
#page-footer - this will target only the actual page footer element
article footer - only going to target footers in articles

Also because Drupal can nest elements, such as blocks can contain blocks, node can contain blocks that contain nodes, e.g out seudo DOM "structure" might look something like this:

block -> blocks
node -> block -> nodes

We need ways to target just one block, or one node in that structure without too many inheritance issues. To put it bluntly - I want to write less CSS overrides (neutralizing inheritance issues), but still leverage the cascade where I want to - this is why nearly everything has a class as well - use the classes for cascading styles, use the ID for things that don't/shouldn't necessarily cascade (to far). For example it would be pretty crazy to to add something like:

#page footer {
border: 20px solid black;
}

That is going to be all powerful and hard to override for footers in entities (not impossible but is extra work), whereas using #page-footer is very well targeted. You could do this...

footer {
border: 20px solid black;
}

article footer {
border: 1px solid pink;
}

But in my mind that will still lead to many situations where you have unwanted inheritance and end up writing screeds of CSS just neutralize inherited styles.

dcrocks’s picture

Thanx for the explanation. I guessed that targeting was one of the reasons but the w3c still recommends using divs instead of the semantic elements for layout and style. But that means the same # of divs plus the semantic elements in the dom, which could lead to a dramatic increase in dom elements. I don't know the penalty for that. It does seem that the semantic elements are only there to be consumed by external 'semantic' processors.

Jeff Burnz’s picture

You are miss-reading the specification. In HTML4 DIV has semantic value (a page division or a kind of "section"), but real world usage destroyed and undermined that value. HTML5 working group recognizes this and degrade DIV to a pure styling element, so you can markup like this:

<section>
  <h1>Section title</h1>
   <div class="content">
    Some content goes here...
  </div>
</section>

The section element is the semantic one (creates structure in the document - its adds a new section (see notes on sectioning elements in the HTML5 spec)), the div is there just so we can style the content differently, if we don't need to style it differently then we don't need the div.

This is hugely liberating for web designers - now we can be more liberal with div element without the semantic monkey on our backs we had in HTML4 (oh no, I used a DIV inappropriately...).

Status: Fixed » Closed (fixed)
Issue tags: -html5

Automatically closed -- issue fixed for 2 weeks with no activity.