Forum OpenACS Development: W3C Standard Support for earlier version of IE

At the moment, the basic 'out-of-the-box' OpenACS renders well on a broad range of browsers. However, increasingly, when OpenACS is used as a toolkit it is 're-skinned'.

When re-styling the basic OpenACS, and when creating pages in xowiki, the best practice is to use W3C standards including CSS. However, this immediately creates a problem with IE5.x, IE6 and IE7, all of which to varying extents either do not fully support the standards, or implement features incorrectly. This road leads to 'coding for individual browser' hell!

Instead, there is a javascript library which confers W3C compliance on these older IE versions, in some cases adding capabilities (i.e. child selector to IE6). The full list of improvements is here:

http://ie7-js.googlecode.com/svn/test/index.html

Whilst this would not always be necessary in all applications, I can certainly see it being useful. It can be added by modifying the openacs templates to source the necessary scripts in the HEAD of every document. The scripts are here:

http://www.charlescooke.me.uk/web/lab_notes/ie7_script.html

Would it be worth adding this as a subsite parameter to acs-subsites and including the scripts in 'resources', so that this retroactive standards compliance behaviour can be activated without having to hack the templates?

Any thoughts?

Regards
Richard

Collapse
Posted by Torben Brosten on

Pages tend to break the more reliance there is on javascript to render and provide services on a page. So, I'm not for adding this as a default, but as an option to anyone that wants to use it is fine.

There are techniques to use CSS that are more restrictive than W3C (and W3C compliant) that tend to allow IE and other browsers to degrade gracefully.

One key technique is to define CSS elements in reverse order with most specific first. for example:

body {
#wrapper #menu-list #header-navigation {
#wrapper #menu-list {
#wrapper #breadcrumbs {
#wrapper #header #system-name a {
#wrapper #header #system-name {
#wrapper #header #tag-line {
#wrapper #header {
#wrapper #content-wrapper #inner-wrapper #main #main-content .main-content-padding #register-login {
#wrapper #content-wrapper #inner-wrapper #main #main-content .main-content-padding .menu-list {
#wrapper #content-wrapper #inner-wrapper #main #main-content .main-content-padding { 
#wrapper #content-wrapper #inner-wrapper #main #main-content { }
#wrapper #content-wrapper #inner-wrapper #main { }
#wrapper #content-wrapper #inner-wrapper { }
#wrapper #content-wrapper {
#wrapper {

This helps stabilize rendering between some of the more obscure rending issues.

It would be nice to see OpenACS use this technique, to help with a consistent look "out of the box".

Of course, another helpful strategy is to use CSS that is compatible between browsers --if that's not already being done.

cheers,
Torben

Collapse
Posted by Richard Hamilton on
Torben,

I agree, your method of organising the CSS is an excellent strategy for avoiding and identifying confusing CSS conflicts.

However, the kind of incompatibilities that I am referring to would not be addressed by this method. As examples here are a few:

1) Alpha channel transparency not supported prior to IE7.
2) No child selector in < IE7
3) Block element width calculations non-standard in IE6
4) Fixed positioning not supported in IE6
5) Background image anomalies in IE6
6) Max-width and Max-height not supported in IE6
7) Box model auto-expansion in IE6 (non-standard)
8) The consequences of the IE only hasLayout property being false (see: http://www.satzansatz.de/cssd/onhavinglayout.html)
9) The 'Float' bugs

etc., more details here: http://www.positioniseverything.net/ie-primer.html

The script I am proposing adding optional support for "...is a JavaScript library to make Microsoft Internet Explorer behave like a standards-compliant browser. It fixes many HTML and CSS issues and makes transparent PNG work correctly under IE5 and IE6."

So this would completely abstract the problem so that *most* standards compliant code served from an OpenACS would then 'just work' in early versions of IE.

In fact the latest version of this library I think actually confers some CSS3 capability into IE that it otherwise would not have.

It just seems like a good idea to provide access to this abstraction layer to enhance backwards compatibility of all standards compliant content delivered from OpenACS including that delivered by xowiki and all other packages.

Richard

Collapse
Posted by Torben Brosten on
Richard,

The strategy isn't so much about avoiding CSS conflicts.

This method helps IE render CSS correctly, due to the order and significance IE uses in applying CSS.

I'm fine with having an *option* to expand the set of compatible CSS by adding javascript.

cheers,

Torben