The DOMBlogger Content Management attempts to produce W3C HTML5 markup using standard compliant W3C CSS 2.1 for page layout.

The result of this attempt is that our product typically produces content that properly renders in most currently supported modern browsers.

Most currently supported browsers support XHTML and advertise their ability to accept the application/xhtml+xml Internet media type to the server when they request content.


Google Chrome, Mozilla FireFox, Opera

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? ;)


Internet Explorer 9

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.


Webkit Gtk Browsers

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.

Some currently supported browsers do not support web pages sent as XML. The well known examples are version of Internet Explorer prior to version 9.

DOMBlogger makes adjustments to the content to compensate for these browsers:


Content Sent as text/html

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.


Adjustment of Tags

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 -->

would be sent to non XML browsers as:

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

SVG Support

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 6

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 and 8

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.


Tablet PC Support

Content to come


Smart Phone Support

Content to come


Accessibility Browsers

Accessibility is important to us. Unfortunately it can sometimes be very difficult to understand what practices result in accessibility issues.

Some Accessibility issues are common sense:

  • Provide text description alternatives for visual elements
  • Avoid using tables for layout, use tables only for tabular data
  • Use semantic markup wherever it is possible to do so.
  • Avoid dependence on JavaScript for web application functionality
  • Links should be recognizable and descriptive.
  • Specify font sizes using relative sizes

Many of those issues are beyond the ability of the Content Management System to adequately enforce. The user providing the content to be managed must think about those things.

What a Content Management System can do is provide an easy means for the user to make their content accessible, and perhaps even provide some tools for pointing potential accessibility issues.

This is an area DOMBlogger is very interested and hopefully we will be able to produce a product that properly handles accessibility issues and encourages content producers to provide content that is properly accessible.


Your Responsibility

As the provider of the content to be managed, it is your responsibility to make sure your content is cross browser compatible. The CMS should make it easy to provide cross browser compatible content, but there is only so much a CMS can do.


Best Coding Practices

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.


Multimedia / Images

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.


Eye Candy

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.