Posts in Category: Site Design

Issues and Strategies for Moving to Html 5

Primer on Html 5

There has been a lot of buzz in the blogosphere about HTML 5 lately, from google endorsing it as the future to the W3c dropping efforts on XHTML 2 to focus on HTML 5. The consensus seems to be that HTML 5 is the future and we should start planning on using it in the future and can even use it now. It should be noted however that HTML 5 is not a standard yet, but only a draft and is subject to change before it becomes a standard and current browser support is a mixed bag.

Some useful links:

23 Essential Resources for Html 5

Misunderstanding Markup - comic that explains HTML 5 vs XHTML.

Real World Issues for a Content Management Systems To Switch to Html 5

So from reading the above linked articles and others it seems like we can easily change to the HTML 5 DocType and things will be pretty much compatible at least as long as we don't use any of the new HTML 5 elements that might not be supported in all browsers yet. In mojoPortal the doctype is declared in the layout.master file of a skin so it can be a personal choice wheether to change to the Html 5 doctype now or not. Currently the doctype in our skins is XHTML 1.0 Transitional, so to switch to HTML 5 we would just change this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="" >

to this:

<!DOCTYPE html>

In fact I've done that here on, though I'm running a newer build than the current release (dogfooding for the coming release), so you should probably wait for the next release to do this if you want to. One of the things I've added is an option on our validator link to configure it for HTML 5 instead of XHTML like this in layout.master:

<portal:XhtmlValidatorLink id="lnkw3cValidator" runat="server" UseImage="false" Html5="true" />

This Html5=true merely changes the label and/or image on the validator link to HTML 5. I've also added a property IncludeHtml5Script to our IEStyleIncludes control

<portal:IEStyleIncludes id="IEStyleIncludes1" runat="server" IncludeHtml5Script="true" />

if set to true we inject the javscript as mentioned in this article inside IE browser comments to make it possible to use some of the new HTML 5 elements in IE 8 (though I'm not actually using them yet to avoid compatibility issues you could use them in custom features). So it renders in the page like this:

<!--[if IE]>
<script type="text/javascript">


Ok But Aren't There Any Gotchas?

I got kind of excited about changing the doctype to Html 5 just in preparation for the future even though we can't use the new Html 5 elements yet without breaking some browser compatibility, especially for IE 6. I'm sick of caring about IE 6 myself and admittedly some of our skins are a little funky in IE 6 today and I don't care enough to fix them though some of them work pretty well too. Its long overdue for users of IE 6 to upgrade. But its still in wide enough use that many web site owners do care and you can make skins that work well in IE 6 using mojoPortal its just more work tweaking the IESpecific.css file and testing in IE 6. Anyway after changing to HTML 5 doctype on and testing in IE 6 and not seeing any major problems I thought I would change the included skins to HTML 5 for the next release. I did this yesterday but reverted it today. I had been testing using the wc3 validator using the direct input method, viewing the source of the page and pasting it into the validator and was happy because it was reporting it as valid HTML 5. However after testing some pages on using the validator link or using the url input method I got different results. It seems there is a bug in the w3c validator where if you use direct input it passes things that should not pass but when you use the url it finds problems on the same page it validated as direct input.

Specifically what I ran into was border is not a valid attribute on img and frameborder and scrolling are not valid attributes on iframe, however the presence of these attributes does not seem to be detected correctly with the direct input validation but it is detected using url validation. I reported this bug to the w3c public mailing list tis morning. Fixing the border on img was fairly easy so I did that, you can easily set the border on img using css so its really not needed to use border="0" to remove a border for example. However the iframe issue is a lot more of a problem. If you remove frameborder="0" from an iframe there is no way to remove the 3d border that is rendered in current browsers using CSS. I don't think there is a working CSS alternative to scrolling="no" either. So for the moment I choose to just live with it that a few pages on won't validate but for the skins included in mojoPortal I decided it was pre-mature for me to change the doctype to HTML 5 and changed it back and leave it up to users if they want to do that. 

As previously mentioned, HTML 5 is currently just a draft so I don't want to get too concerned with validation against it while its still draft. Who knows since current browsers don't work well look right with iframes that don't use frameborder=0 and scrolling=no, maybe they will change their minds about dropping these attributes or give us an HTML 5 Transitional to validate against that will allow these for backward compatibility.

So where does that leave us?

Well I think we have to proceed cautiously and very slowly toward HTML 5 but we are very limited in what we can do in mojoPortal without breaking compatibility especially for public facing features. If I were to start using new elements and attributes of HTML 5 it will break validation for those who choose to continue using the XHTML 1.0 Transitional doctype in their skins and it would probably break functionaility and visual layout in some browsers. Potentially we could move forward in the admin pages and other non public facing pages but the benefits would be minimal. The real value of HTML 5 will be when we can use it for public facing pages, the improved semantics available using the new elements like header, footer, section, nav, article, aside etc will be of most value in public facing pages, but we really can't move there yet because of the mixed browser support. Once HTML 5 graduates to a Standard instead of a draft and browser support for the new elements is more widespread it will be tempting but we will still be faced with that fact that many people use old browsers, perhaps even we will be waiting for the end of life of the current crop of browsers anxiously like we are waiting for IE 6 to go away today. The benefits of changing to HTML 5 doctype today are minimal and there is the minor downside of losing validation on some pages where we are using iframes and maybe other issues that I have not bumped into yet. HTML 5 does indeed look like the future but the future is not here yet unless you are willing to give up support for IE 6 and possibly even IE 7 as I'm not sure if the javascript trick for lighting up the new elements in IE works in IE 7 as it does in IE 8. (update it does work) I for one don't see the merit in building browser specific applications, the huge benefit of the web has been the ability to write apps that work in all browsers though of course there have been bumps along the way like supporting Netscape 4 was back in the day and like supporting IE 6 is today, it takes some extra work. I don't want to try and move forward too fast and find myself battling to get things working in all browsers. I'm tempted to change my doctype on this site back to Xhtml 1.0 Transitional since I'm not really getting any benefit from changing to HTML 5 doctype though I have not had any major problems other than some validation issues everything seems to work the same and nothing is visually different in any of the browsers I tested.

UPDATE 2009-08-03

I actually tried this javascript create element technique with IE 6 and it seems to work! So even though the article says IE 8, it seems it should also work for IE 6 and 7. So maybe it is possible to switch to Html 5 and use the new elements. So the remaining issues would be that there will be some things that don't validate like framborder=0 and scrolling=no that we would still need to use. And the problem still remains that if I were to start using the new html5 elements that would mean that all users of mojoPortal would need to change to the Html 5 doctype because the new html 5 elements are not valid for Xhtml.


Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

mojoPortal used in the We Are Microsoft Charities Challenge Weekend

Over the weekend, Jan 16-18 2009, Microsoft held a great event, "We are Microsoft Charity Chellenge Weekend" to help charities. The event paired teams of developers with charity organizations to produce web solutions to better meet the needs of the charity organizations. The challenge was that the time available to produce the solution was limited to the weekend, everything from gathering requirements to final delivery had to be completed in that time frame.

I was very honored when one of the teams chose to use mojoPortal.

paxUnited Team - Microsoft Charity Challenge Weekend

Todd Stone, Tim Mitchell, Nathan Woodward, Jay Smith, Andrew Dalgleish

You can read the full details and see before an after screenshots in this blog post by Microsoft MVP Jay Smith "We Are Microsoft: Developers Rally Around Charities"

"After checking out Telerick’s SiteFinity and Telligent’s Graffiti CMS, both very powerful and capable Content Management Systems, we elected to go with mojoPortal."

These guys really did an impressive job accomplishing so much in a very limited time frame. I congratulate them and thank them for their good work for a good cause and for giving mojoPortal the oportunity to participate in this exciting event.

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

A Few New Tutorials

Just a quick post to mention a few new tutorials for mojoPortal.

How To Filter Out Un-Wanted Content From Feed Manager

by Walter Ferrari of Abertech. Big thanks to Walter! He not only helped with major improvements to the Feed Manager recently but also is willing to help with documentation which is much appreciated.

CSS - Its All About Understanding Selectors

an article I wrote today to demystify CSS a little for those trying to learn how to skin mojoPortal. Once you master CSS Selectors it becomes much easier.


Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

Tip/Trick Creating tabs in the mojoPortal Html Content Module

In the mojoPortal release announcement, I mentioned that we changed from ExtJs tabs to YUI tabs in mojoPortal. One side benefit of this is that its now possible to create tabs in your content using the editor.

In the past this wasn't possible. I had written a .NET wrapper control around the ExtJs tabs, but only developers could use that, there was no simple way to create tabs right in your content. The integration with YUI tabs is a little looser, I have not implemented a .NET control for it yet though I may do so in the future. But the main scripts for YUI tabs are included by default, so you can paste a simple chunk of markup into the source view of the editor to get the start of your tabs, and then you can edit it from there to add more tabs or change the labels and contents of the tab.

Now you won't see the tabs in the editor, but when you save it you will see the tabs.

To try it out, add an Html Content instance to a page in your mojoPortal site or on our demo site. Click the edit link to edit the content, then click the source button to see the raw markup view. Now paste in this:

<script type="text/javascript">
var myTabs = new YAHOO.widget.TabView("demo");
<div class="yui-skin-sam">
<div id="demo" class="yui-navset">
<ul class="yui-nav">
<li class="selected"><a href="#tab1"><em>Tab One Label</em></a></li>
<li><a href="#tab2"><em>Tab Two Label</em></a></li>
<li><a href="#tab3"><em>Tab Three Label</em></a></li>
<div class="yui-content">
<div><p>Tab One Content</p></div>
<div><p>Tab Two Content</p></div>
<div><p>Tab Three Content</p></div>

Save, and you will see something like this:

screen shot of YUI tabs

At some point when I implement content templates I will make it easy to do this by selecting a content template, but thought I would mention it for the more html savvy users.

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

mojoPortal is Catching on at Universities!

Universites need a lot of web sites. They have many departments, divisions, research projects, events, etc., and they need web sites for all these things to disseminate information and to enable collaboration and communication between members of these various communities. With so many sites to manage, Webmasters at Universities need a good web infrastructure that allows them to easily deploy new sites and extend them as needed. Its only natural that Universites need content management systems and several Universites have selected mojoPortal for their content management needs.

Shaun Geisert, Webmaster, Division of Student Affairs, Colorado State University, recently let me know about a number of their sites already using mojoPortal as well as plans to use mojoPortal in another 20+ sites going forward.

Quoting Shaun: "Before discovering Mojo (I used CMS Matrix, btw), I had researched and/or used a number of other open source .NET CMSs in order to find one whose core framework best meets the needs of our numerous departments.  Since then, I’ve found it to be above and beyond anything else I’ve seen in the open source .NET realm."

When I look at all these sites I'm very impressed with the design work Shaun and his team did with all the different skins, they all look really great and it makes me proud to point them out as mojoPortal sites. They also produced a nice user guide document for their users that looks very professional and helpful and they've offered this document back to us as a contribution to the project. I probably need to de-brand it before sharing it so I'm not making it available right away, but will use it as a basis for producing a more generic user guide. To me, willingness to share is a clear sign that these guys "get" open source, and I'm really glad to have them in the mojoPortal community.

Another example of mojoPortal in use at Universities is the School of Health and Social Care at University of West England, Bristol.
They supported our efforts last year to implement multiple sites on a single installation using folder names, so anyone using that feature today can thank them for their good participation in the community. Quoting Matt Cownie: "we've had a tremendous amount of utility from mojo and its saved us an awful lot of donkey work." Matt is a great guy, I really enjoyed working with him on the multi sites feature last year.

A third example is the site for the Glasgow Clinical Trials Unit.

Its really great to see mojoPortal catching on in Universities and other large organizations. We've got a lot of plans for continued improvements in mojoPortal and we hope to see more and more adoption.

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.