Chrome, FireFox and Opera are the browser we primarily use while testing the CMS and thus they are very well supported.

We rarely test on Safari but it should properly render in Safari. Anyone have a spare Macintosh? ;)

No testing has yet been done with Internet Explorer 9. Allegedly IE 9 is better at supporting web standards than previous versions of IE so in theory (famous last words) content produced by the CMS should properly display in IE 9.

When Apple open sourced Webkit, a port of Webkit to the Gtk platform was made. Many fast lightweight browsers (such as Midori) now exist that use the Webkit Gtk backend. Technically Google Chrome uses Webkit Gtk, though they use a customized version of the Webkit Gtk backend.

How well these browsers work with DOMBlogger depends upon the version and build options used for the Webkit Gtk backend. If an older version of WebKit Gtk is used, for example, HTML5 media may not properly work. Web font support also appears to be spotty.

If you use a Webkit Gtk based browser, please make sure you have a current version of Webkit Gtk installed.

When these browsers request a web page, the content is sent using the older text/html Internet media type. The DOM is dumped server side as proper HTML instead of XML. That is one of beauties of using the DOMDocument class for content generation.

The older versions of browsers that do not accept XML also often do not properly associate style to the semantic HTML5 tags. DOMBlogger will use div in place of most semantic markup tags for these browsers, increasing the odds of proper rendering.

For example:

<aside id="margin">
 <!-- margin content here -->
</aside>

would be sent to non XML browsers as:

<div id="margin">
 <!-- margin content here -->
</div>

Non XML browsers usually do not support the SVG image type. When you upload an SVG image, DOMBlogger automatically makes a PNG version of the image. When a Non XML browser requests an SVG image, DOMBlogger will send the PNG version of the image.

Internet Explorer Version 6 is not supported by DOMBlogger. It is a really odd browser that often requires special care when crafting CSS style sheets and at this point, its market share is so low that it just is not worth the time and money required to develop for it.

We simply will not respond to rendering issues that involve Internet Explorer 6.

Internet Explorer 7 will be supported by DOMBlogger at least until Windows XP reaches end of life and possibly longer. Internet Explorer 8 will likely be supported beyond support for IE 7.

This means if there is a rendering problem in those browsers caused by the DOMBlogger engine, we will try to fix it.

Try to conform to the W3C specification for HTML5. If your content conforms to the standard it far more likely to properly display across a variety of browsers and it is easier for the CMS to compensate for browsers that need special consideration.

Make use of semantic tags, such as strong instead of b and em instead of i. Make use of the new HTML5 semantic tags including article, section, details and figure.

Avoid using tables for non tabular data. When you do use tables, use the th node with the scope attribute so that the tables are easier to understand from a non visual perspective. Avoid using iframe if at all possible.

If you use CSS features from CSS3 (opposed to CSS 2.1) make sure display of the web page does not depend upon the browser understanding CSS3.

Provide any video content in both H.264/AVC and Ogg Theora. Always make sure there are controls to multimedia so the user can start and stop it. When coding your own control interface via JavaScript you will not want the default controls, but they should initially be there. Use JavaScript to remove the default control interface before adding yours so that users without JavaScript enabled can still use the default control interface.

Do not autostart multimedia. Let the user start the multimedia when the user wants it to start. There is nothing more annoying than using a search engine to find pages of interest, opening several in new tabs, and then have one (or more) of them start multimedia when the person is not even looking at the page yet.

Make sure you provide the necessary metadata for DOMBlogger to provide proper alt tags for images.

When integrating JavaScript into a web page, try to use a library such as jQuery that properly detects browser capabilities and compensates for different browsers. Test your web page with JavaScript completely disabled to make sure it is still functional without JavaScript. Avoid taking the attitude that users should enable JavaScript to view your content, there are situations where JavaScript either is not allowed for security reasons or just simply is not possible, such as some browsers for people with disabilities.

Avoid un-necessary eye candy that looks cool but detracts from functionality. This seems to be a growing trend among web developers, and it is annoying.

Test your web pages in a browser without using a mouse, using the tab key to navigate the page. If you find that you can not perform certain actions that you can with a mouse, you have an accessibility problem.

When these functions are JavaScript actions, you can often fix these Accessibility problems by having your JavaScript insert a standard button node and attach the JavaScript action to the button click event.