Need help with clientWidth/Height issue

[oakleymk]

Hi All,
This is the parent issue that led to the post Need help with getDOCTYPE() function (http://www.daniweb.com/forums/thread196837.html)

USING THE BODY METHOD: The following code will properly get the viewable window area if no DOCTYPE is specified. document.getElementsByTagName("body")[0].clientWidth//Height OR document.body.clientWidth//Height If DOCTYPE is XHTML ANY* the above code reports only the defined page area as if it was a wraper**.

USING THE HTML METHOD: The following code will properly get the viewable window area when DOCTYPE XHTML ANY* is used. document.getElementsByTagName("html")[0].clientWidth//Height OR document.documentElement.clientWidth//Height If no DOCTYPE is used the above code reports only the defined page area as if it was a wrapper**, EXCEPT IE6+ (not tested in older browsers) reports 0.

-----

So the problem here is how to create a cross-doctype compatible function for getting the width & height of the window/frame. I have played with several methods but each produced problems. The best solution I can think of is to detect the doctype by using the following code:

FireFox3, Safari and Chrome*** work according to the W3C standard document.doctype using .publicId & .systemId , but this causes IE to get a hard error. IE will however allow reference to the DOCTYPE through node objects. Both document.body.parentNode.parentNode.firstChild.nodeValue and document.getElementsByTagName("!")[0].nodeValue work in IE but not other browsers. So I came up with a function to tackle this issue:

function getDOCTYPE(){
  var pid,sid,val,lng,ver,typ;
  try{
    pid=String(document.doctype.publicId);
    sid=String(document.doctype.systemId);
  }
  catch(err){
    val=String(document.body.parentNode.parentNode.firstChild.nodeValue)
    pid=val.replace(/^[^\"]*\"([^\"]+)\".*/,"$1");
    sid=((/http/).test(val))?val.replace(/^.*\"\s\"(http.*)/,"$1"):null
  }

  lng=((/xhtml/i).test(pid+sid))?"XHTML":"HTML";
  typ=((/strict/i).test(pid+sid))?"Strict":((/trans|loose/i).test(pid+sid))?"Transitional":((/frame/i).test(pid+sid))?"Frameset":((/basic/i).test(pid+sid))?"Basic":((/mobile/i).test(pid+sid))?"Mobile":null;
  ver=((/html\s*\d+\.?\d*/i).test(pid))?pid.replace(/^.*html\s*(\d+\.?\d*)\D*/i,"$1"):null;

  return {publicId:pid,systemId:sid,language:lng,type:typ,version:ver,set:lng+" "+typ+" "+ver}
}

As the page must be fully rendered before the function can be implemented be sure to call the function through an event such as:

window.onload=function(){
  var dtd=getDOCTYPE();

  //as noted in the function, the following variables can be called: publicId, systemId, language, type, version and set
  alert(dtd.set)
}

THE PROBLEM!: I am attempting to provide support for the Opera browser and neither method from above will provide info on the DOCTYPE. So I either need a solution to the original clientWidth/Height issue or find a way to get the DOCTYPE info in Opera.

Thank you in advance on any assistance provided! :)
~MikeO

FOOT NOTES:
*Strict, Transitional, etc.

**if a <div style="width:300px;height:100;"></div> is used (and no positioning is set) as the only object in the body then body reports 300px/100px reguardless of how large the browser window is sized to. if positioning is set then the body area becomes 0px/0px (as the object <div></div> has been moved out of the wrapper). This can be restored by setting the position of the body to relative.

***Google Chrome only works if <meta name="content-type" content="application/xhtml+xml; charset=iso-8859-1" /> is used instead of the more commonly used <meta name="content-type" content="text/html; charset=iso-8859-1" /> . However, this enforces a very strict code policy and will typically cause older or improperly formatted pages to be rendered with undesired results. Personally, I prefer to design all pages with this meta.

[MidiMagic]

It really can't be done in a way that works on all browsers. The web was designed so that you do not know what size the browser window is, and with no way to fit something exactly to the browser window. The page is supposed to flow to fit the existing space.

For width, you can simply use the width function with the appropriate percentages for what you want. You can use percent to change the sizes of images too. Use relative sizes, so all of the parts expand and contract at the same proportions.

Adjustments for the height of the browser window are not provided in a way that works on all browsers and computers. The best way to do it is to treat the web page as a scroll, not a sheet of paper. The Internet is not designed to treat information as sheets of paper.

Or use Adobe Acrobat to play the page. It can do this, because you can resize to fit..

Because most people open their browsers maximized, design the page to work on a standard browser aspect ratio. Make sure the background color is compatible, so if any background shows below the content, it is not obtrusive. If the page renders taller than the browser window, scrolling is a fact of life.

Remember that the new 16x9 monitors are throwing monkey wrenches into this.

If this is an assignment from a superior, you have the dubious task of convincing him that it can't be done in a way that works on all computers. The functionality to di it is not in place. Someday this might be possible, but it is not possible now.

[oakleymk]

Thank you for your comments they are much appreciated.

With respect to your viewpoint with treating the page as a scroll, I agree that this is how most development is done. I have been designing web pages since the late 90’s and have watched the evolution of browsers. Browsers have slowly become a portal of how we interact in our society. This evolution has only been possible because of standards that have been implemented to allow for greater control of its environment. In my professional observation, the limitations often occur only when the standards are not followed.

As the use of browsers have advanced beyond simple webpages and more toward web based applications, a greater level of precision is required to deliver dynamic content. If we all had succumbed to the idea of “oh… it was never designed for that” we would never of had the advent of AJAX, .NET, and many other recent web based technologies. As I have demonstrated in my post, most browsers adhere to some level of the W3C standards these days, though as my post clearly shows, some browsers do have shortcomings.

Contrary to your statement, I have a library of functions that do exactly what you state browsers weren’t designed to do, and I have been doing it for many years. My efforts recently have migrated toward updating these functions to be more cross-browser/cross-doctype compactable by taking advantage of XHTML. I have nearly completed the new set of functions and as demonstrated most all browsers do work with the getDOCTYPE() function.

What I am hoping for is to find is someone who has experience working with the Opera browser or has done work with JavaScript DOCTYPE references and are able to provide some insight on how to get Opera to pull the DOCTYPE value.

[bretthacker]

Thank you for your comments they are much appreciated.

With respect to your viewpoint with treating the page as a scroll, I agree that this is how most development is done. I have been designing web pages since the late 90’s and have watched the evolution of browsers. Browsers have slowly become a portal of how we interact in our society. This evolution has only been possible because of standards that have been implemented to allow for greater control of its environment. In my professional observation, the limitations often occur only when the standards are not followed.

As the use of browsers have advanced beyond simple webpages and more toward web based applications, a greater level of precision is required to deliver dynamic content. If we all had succumbed to the idea of “oh… it was never designed for that” we would never of had the advent of AJAX, .NET, and many other recent web based technologies. As I have demonstrated in my post, most browsers adhere to some level of the W3C standards these days, though as my post clearly shows, some browsers do have shortcomings.

Contrary to your statement, I have a library of functions that do exactly what you state browsers weren’t designed to do, and I have been doing it for many years. My efforts recently have migrated toward updating these functions to be more cross-browser/cross-doctype compactable by taking advantage of XHTML. I have nearly completed the new set of functions and as demonstrated most all browsers do work with the getDOCTYPE() function.

Just a thought: once you arrive at the place in your code where you realize you're in Opera, can you parse body.outerHTML and look for the doctype string with some regex? Cheesy hack if it works, but better than waiting for someone to fix it.