A core conversation in which we discuss the implications for Mobile, WYSIWYG, Render API, Design Patterns, Semantics (HTML5/Aria/Microformats/RDFa), the Basic Page, Responsive Design, and Unstructured Data.

Until recently mobile development meant site builders had to build parallel solutions, either a mobile app or a mobile-only website.

But the past year has seen a fundamental shift in how we think about web sites. Responsive Design means that the front-end of a website can adapt to the varying screen sizes of devices from small cell phones to large 30" LCDs. Using media queries, JavaScript and smart CSS choices means front-end developers can continue to use a single HTML source for all screen sizes.

But this is not enough.

Leading mobile development leaders like Stephanie and Bryan Rieger, Jason Grigsby and Steve Souders know there are competing requirements for our new mobile world:
- "One Web" means serving all devices using a single URL.
- Performance is even more critical than normal, so serving images, CSS and other assets that aren't used by the client is a huge waste.
- There are no such thing as a "mobile friendly CMS".

Drupal handles structured data very well. But what about the "Basic Page" content type? Its usually a dumping ground for unstructured data, content that doesn't conform to a standard model that easily fits the concept of a "field". Brochure-ware sites are actually really good examples of unstructured data.

To truly reach the One Web ideal, we need all our content to be responsive. Literally let the site builder change the way the content displays depending on the context. Which means we need Drupal to understand the semantic structure of our content, even when its all in one textarea.

We should be able to drop an image into a textarea and still know its an image and give it all the features it would have if it was a field.

How do we make Drupal understand the semantics of our content so that our content can be responsive?

Proposed solution:

How do we make Drupal content responsive?

This question is tricky, but its essential that we agree on the direction Drupal needs to go.

Possible solutions:
- Let the theme system convert semantic content into rendered markup
- HTML5, mircrodata, microformats, RDFa, whatever, describing the semantics internally?
- JSON as loose semantic structure?
- Please god, not XSLT
- element info API version 2?
- RDFa, JSON and Aloha editor like: http://www.slideshare.net/bergie/vie-using-rdfa-to-make-content-editable
- Drag and drop design patterns into a WYSIWYG that stores both markup and semantic understanding of content?

Drupal is a registered trademark of Dries Buytaert.