Random/Framing Notes

• Introduction to HTML 5 book is a primary reference during this conversation
• Is it a good ideal to add a bunch more options, fields, and decisions for what to HTML5ize or not throughout Drupal? This might create some big UI/UX problems.
• Might be better to have all Semantic HTML5 settings on one big page, rather than have the configuration distributed throughout Drupal
• Doing all the config in one place will also give us a really easy way to set all the defaults more manageable.
• However, having all the config in one place AWAY from the creation/edit pages for these entities could be cumbersome
• Can we have the same settings in two places? The Semantic HTML5 module settings page AND the individual settings pages for menus, blocks, etc?
• We’re going to start out in Drupal 6, it’ll be difficult and messy, but we’ll learn as we go and then know how to tackle this in Drupal 7
• If we build an API for this and collaborate with creators of Semantic Views, Semantic CCK, Mothership, etc, might be a great way to go for Drupal 7
• Might never be an API because in Drupal 7 this is going to be done by drupal_render
• We’ll need to include JavaScript to include semantic tags on non-HTML5 compliant browsers
• Our goal is to make Drupal work for HTML5, not to make HTML5 work in all web browsers

Forms and Fields

• Form API gives us a big advantage and many abilities to make changes to any form field
• right now we can primarily work with core and CCK fields
• we can provide support moving forward, but we can’t completely anticipate what other fields will be used for; we can’t inspect backwards
• we can also work with modules like Date, Email
• use the Elements allows module developers to use Form API to get HTML5 form elements into their modules; a separate module would be used to transform core and CCK fields to HTML5 elements
• want to be able to switch fields from “text” field to “email” field; Elements module lets you do some of that already
• we’d need a different module that does what Elements does to core fields
• other things to support with the other module - search (core)
• these modules will override the markup for CCK widgets
• we need to figure out how to override markup for all the fields with HTML5 elements; then we need to figure out how to implement that within the module, allow people to specify which fields they want to override, etc.
• Could also consider getting this stuff into modules (CCK, Date, etc) themselves anyhow to avoid having to develop an entirely separate module

$header and DOCTYPE

• DOCTYPE has to be changed but that’s relatively easy
• Header elements are also done differently in HTML5
• In Drupal, $header is spit out by Drupal
• In Drupal 6, $header is populated by both core and by the drupal_set_html_head function - anything can be put into the $header using that function
• We can tackle this on the module level, but would then need to ensure that the module gets executed last (and other modules are already jockeying for that position)
• In Drupal 7 what you’re adding to headers is much more structure
• Other option - handle it at the theme level using a preprocess function - wind up with an amorphous blob of text that we could regex to replace tags with HTML5, but it’s not foolproof
• A module seems like a headache; a starting point in a base theme might be a better way to go
• If an edge case uses the old HTML ways, the page/site will still work
• If this is done with a module, anyone can do their own HTML5 theme, $header is still printed normally, instead what you get out of $header is now HTML5 instead of the old way to do it
• drupal_add_http_header and drupal_add_html_head are used in Drupal 7, so getting stuff into $header will be much more structured
• We could backport that from Drupal 7, but contrib modules might not work with that backport
• We could implement the backport and append on whatever else was set in the header that isn’t handled by the backport at the end, though that could result in double info
• Are there concerns about the order of tags in the header? Probably tags that have to come after everything else will be appended on the theme layer anyway, and if not it would work if we appended things at the end of the D7-backported $header
• Agreement is coming in this discussion that this should be done in the module level; create a wrapper function that overrides drupal_set_html_head and is a backport of what’s in Drupal 7; modules can use our function if they provide needed information that they want in the header; and if any modules are not using our function to set header tags those are just appended at the end of the $header
• possible module names: HTML5 API, HTML5 tools
• might have implications for limitations on script and styles tags (e.g. IE limitation of number of CSS files)
• The syntax has only been simplified in HTML5, but how do we get in there and alter those variables?

Document Layout Tags

• The new HTML5 document layout tags include article, header, footer, nav
• Much of this is a theming layer issue
• A group needs to get together, figure out best practices, and rewrite node.tpl.php and page.tpl.php for a base D6 theme
• However, some tags come out of core, CCK, and Views
• Some of the HTML that core spits out has theme functions, some doesn’t (e.g. comments)
• We can create a theme function that rewrites and fixes core HTML that doesn’t already have a theme function
• Mothership theme might be a good place to look for existing fixes or a list of possible problems to look at
• Views and CCK - do we fix Views and CCK, or do we tell people to use Semantic Views and Semantic CCK instead?
• Can we wrap our solutions up as Features, perhaps including Semantic Views and Semantic CCK
• One possibility - require Semantic Views and Semantic CCK modules as part of this feature, add a lot of HTML5 documentation to the top of the Semantic CCK form (and Semantic Views too?). We should also prepopulate as many predictable HTML5 settings in Semantic CCK and Views as possible, just like what happens in Semantic Views and Semantic CCK already; in both we’ll be using HTML5 markup.

Menus and other Drupal entities

• there’s a nav tag in HTML5
• Not every menu is a nav, but there are some we know are navs, e.g. primary links and secondary links
• Stuff that only shows up for administrators are second-tier issues for us
• there is some debate about what menus might qualify as navs and what might not
• consider creating a Semantic Menus module
• Though we’re not sure of the way we’ll do it, we do have a goal of altering the menu creation form so that a user can choose to make a menu HTML5 or not
• Other Drupal entities that we need to tackle similarly: blocks, comments
• Config page for the module(s) we create could turn HTML5ing on for particular entities; turning HTML5 on for those entities will turn on

Presented by Theresa Summa (theresaanna) and Seth Cohn (sethcohn)

• Looked at a non-Drupal site, cnn.com - cramming as much information on one page as possible - they throw as much on the page as possible to appeal to as many different people as possible
• observer.com - a Drupal site that does something very similar
• How do you standardize the display of each piece of content on your site (e.g. pictures in proper sizes, providing all essential data, formatting it)
• economist.com and globalpost.com - more content-rich sites built in Drupal

Imagefield

• let users upload images in a CCK node
• lets users upload multiple images, sort the list to select which is going to be featured on the front page, the others get inserted into the content appropriately and in a consistent way by Drupal
• bulk uploader available

Imagecache

• resizes/crops images on the fly according to your preset dimensions
• helps standardize image sizes across the site
• Imagecache is included in Drupal 7 core, hurrah!
• Imagecache presets stop large images from breaking your layout

Quicktabs

• allows you to combine multiple items into one Quicktabs block with tabs on the top
• Nice jQuery action to allow users to switch from one section to the next, loaded all at once, or via Ajax on the fly
• Plays nicely with Views, individual Nodes, and multiple Blocks

Views Slideshow

• the recommended solution (”best of the breed” according to Seth) for rotating carousel type things

Panels

• Provides a drag and drop interface for units of content on the site to be added, deleted, and arranged in a layout on the fly
• “is all sorts of insane magic”
• pros for Panels - great Views integration, user friendly for non-techie users
• Negative - spans between modules and theme layer, so it’s slower, performance hit on your site, takes a lot of liberties
• If you’re a themer, you might be able to do without panels

Composite Layout

• could be called Panels Light
• gives you the Panels approach but does it on a node by node basis - you can choose predesigned layouts on a node by node basis, e.g. a different layout for each individual blog entry, on the fly.
• Display Suite is another alternative

Vertical Tabs

• for the content adding and editing side of the site - much easier
• divide your node add/edit forms into sections with vertical tabs on the side, collapsed along with a summary of the collapsed settings.
• Makes large content types easier for content producers to maintain
• Drupal 7 includes this in core, Drupal 6 module mostly works well

Arrange Fields

• http://drupal.org/project/arrange_fields
• First commit was 5 weeks ago as of 7/24/10 so is early on, but lots of potential
• “This module lets you drag-and-drop the fields of any CCK content type, Webform, or almost any other form in Drupal into the positions you would like for editing. This makes it super simple to have forms with inline fields, which you can change at any point. Tab indexing is also updated, so no matter how you arrange the fields, the users can still tab through them easily. And, you can now add arbitrary bits of HTML markup– labels, images, HR’s, etc.”

CCK Fieldgroup Tabs

• separate CCK fields onto a completely separate tab to break down long node creation forms

Random Notes

• check out Nodequeue again for arbitrary lists of nodes, drag and drop
• you can feed Nodequeues through views
• Imagefield Insert module
• get good at Views theming - so much can be done!
• My question: what’s the best practices approach to fine-grain tuning of everything via node-whatever.tpl.php files vs doing as much as possible within the CSS. Answer: there are a lot of different philosophies; have to consider how custom and how specific this content type needs to be displayed. If it can be done through CSS fairly easily, go for it; there’s a performance hit to loading bunches of node-whatever.tpl.php vs using already loaded & cached CSS. Theresa says her philosophy is to keep the number of files down as much as possible.
• Omega theme (Theresa: “If Zen and 960gs had a baby, it would be Omega”

Jen Simmons on the Bartik theme

• Garland - been around since D5 as the core/standard theme
• D6 - use a good base theme to override crappy HTML in core
• D7 - folks focusing on making core tpl’s non-crappy
• Stark theme - “Zen Lite” - see the HTML that comes straight out of the core tpls - better theme to adapt than Garland (don’t do it!)
• Seven - the new core admin/back end theme
• Bartik!
  • new core theme, but it’s not actually in core yet because it’s not done
  • Check it out at http://bartik.milkweedmediadesign.com
  • Named after Jean Bartik, one of the original ENIAC computer
  • New featured region - hide all the blocks in the content and sidebar regions, but it doesn’t work yet because of a D7 bug
  • $content is now a block in D7! Should be hideable/disableable… but it’s not quite yet.
  • “If you let people hide content everywhere, then unicorns will die…”
  • triptych regions (first middle last) with three boxes in a row
  • footer-columns regions (first second third fourth) and footer region and header region all make menus look different when dropped in (see the demo site)
  • Bartik rounded corners are CSS3, woohoo. Also, gradients, text shadow, etc
  • Imagecache is in core in D7 (woohoo!) so it’s utilized in Bartik
  • Color module - was written for garland, but it can be shoehorned to work with other themes
  • Get the source: http://github.com/jensimmons/Bartik
  • Check it out on Drupal.org: http://drupal.org/project/bartik
  • Most likely the Bartik issue queue will be on drupal.org but code development will be on github for the foreseeable future
  • Jen doesn’t have plans to backport it to D6, but there is interest and would make sense once the D7 version is tight

Orbgasm (Can Alptuna) (and audience) on Freelancing

• Notes from Can’s talk, so I won’t be taking notes in deep detail. (Note, this link is not an endorsement of certain elements of the PDF, e.g. that “don’t be a pussy” comment!)
• in your proposals, break things down into phases that are well defined so that the client knows exactly what you’re planning/committing to, no surprises for anyone down the road
• don’t sign any contracts until those details are hammered out
• be up front about who you are so that you know you’re a good match with your client, their image/politics/style
• idea on copy: bill .20/word to “copy and paste” content into the site (since it’s usually not in an easy format to copy and paste in); bill .50/word to actually write content
• let clients know that Drupal is under GPL, so they’re clear on licensing
• be clear about who owns the code you write - good idea to explicitly GPL it so client’s don’t think they own the code