The ocPortal development team is pleased to announce that ocPortal 7.1 has now entered beta.
ocPortal 7.1 brings full support for HTML5 and for the schema.org meta-data initiative that Google/Yahoo/Bing jointly announced on Thursday 2nd June. This article explains how we have received schema.org, and how we have implemented it into ocPortal.
We feel that schema.org is a very important project, and is perfectly aligned with the goals and nature of ocPortal, so we have scrambled to release a solid implementation (achieved within 3 days).
Not only should schema.org support enhance the Search Engine Optimization of ocPortal websites, it really opens up new interoperability possibilities. For example, look at how Microsoft have been using 'tiles' in Windows Phone, and the recent Windows 8 demo. This is a great example of how semantic markup can be used to create rich interfaces from website data. Because ocPortal now provides this data automatically, in the standardized schema.org microdata format, ocPortal webmasters need not do anything to enable these kinds of interoperabilities.
Specifically, we have implemented the following into ocPortal from HTML5:
- Use of the XHTML5 doctype
- Use of HTML5 semantics tags: header, footer, aside, nav, article, time, output
- upgraded/changed HTML4 functionality that is no longer valid HTML5
- workarounds to make Internet Explorer display pages reliably when HTML5 tags are present
- (We already supported, and continue to support, HTML5 video)
- (We already supported, and continue to support, HTML5 drag and drop upload)
And the following from schema.org:
- WebPage (the default, and we properly support marking up elements such as breadcrumbs, and what the prominent navigation links are)
- ProfilePage (authors, member profiles)
- ContactPage (various contact blocks, support tickets)
- ItemPage (catalog entries)
- Table (catalog tabular views)
- Offer (eCommerce product entries)
- ItemPage (download entries)
- ImageObject (gallery images, images of the day)
- VideoObject (gallery videos)
- ImageGallery (galleries)
- NewsArticle (news entries)
- BlogPosting (blog entries)
- SearchResultsPage (search results)
- CheckoutPage (shopping checkout)
- Review (comment posts)
- Rating (comment posts with reviews)
- AggregateRating (ratings)
- WPHeader and WPFooter [which interestingly, seem redundant given that HTML5 also implements these semantics natively, and schema.org requires HTML5]
One thing we have consciously avoided implementing is WPAdBlock ("An advertising section of the page"). As developers of ocPortal, we are ultimately in the service of website owners, and implementing this part of schema.org would make it very easily for browser plugins to strip adverts from sites, eroding the business model of some websites. This is of course controversial, and webmasters could easily add WPAdBlock into the templates on their site -- it would be fascinating to see a discussion on this matter.
Interestingly, schema.org does not currently implement any microdata standards for encoding social data. It would be great to see a lightweight equivalent to sioc as we feel this would open up many more opportunities for innovative interactions with social websites.
Overall, we really like the microdata design. Initially we were skeptical of microdata, given it reinvents the wheel of what is already covered by RDF and microformats. However, given that microformats are a kludge, and RDF is seen as complex and bloated, we find that schema.org shows just how well microdata can work.
We have to stress that we are not actively promoting the use of the ocPortal HTML5 support yet...
- The standard-to-be has not exited the 'Last calls' stage yet, so is subject to flux (it is expected to be fully stable at some point in 2012). We've made considerable effort to make the support work via an option, so that people aren't forced into anything that is not yet officially (on a number of levels) ready.
- No browsers fully support HTML5 yet, and a lot of the potential (such as linking the 'time' elements through to calendar software) are not yet realized. Browsers that don't support HTML5 will not malfunction, it's just they won't receive the benefits.
The big reason we had to implement HTML5 was for implementing the schema.org support properly (i.e. without making everyone's websites invalid, a rule that we expect less-careful developers may not adhere to). In due course, it makes a lot of sense for people to get the advantages of this -- so if you have an ocPortal site you might want to consider making the switch in the coming months.