Cross-Browser Compatibility

1. Cross-Browser Compatibility

2. Myth or Reality? • There's a long tradition to be overcome • Sniffers to look for browser and OS combinations • Separate code forks for different browsers • Special HTML "tricks" to overcome browser defaults and bugs • Proprietary DOM and HTML • So can cross-browser compatilibity be real?

3. The Reality • Yes! Cross-browser compatibility lies within your reach! • First, you must do as Yoda says: "Unlearn what you have learned" • Second, adjust your thinking for a new reality • Third, start coding! • Let's look at some common pitfalls and things that must be unlearned

4. Shed the Deadweight • Things to give up: • Invalid HTML • LAYER—it's dead and it's time to move on • Proprietary DOMs • document.layers died with LAYER itself • document.all is still alive, but it's also completely proprietary • Code forking • Most forking is based around incompatible proprietary DOMs, so give them up and forking is unnecessary

5. Shiny New Toys! • Try playing with these: • Valid HTML • Purify your structure and compatibility will follow • W3C DOM • Both IE5.x+ and NS6 support the W3C DOM, so code written once can run in both with NO FORKING! • How can this process be any easier? Let's find out!

6. Validating Your HTML • The fastest way to improve your pages • http://validator.w3.org/ • Any page that triggers an error is invalid and the problem needs to be fixed • If you can get a page to validate with no errors or warnings, you're golden • The results will be different depending on what DOCTYPE you use • There's a CSS validator too • http://jigsaw.w3.org/css-validator/ • Valid CSS is as important to page layout as valid HTML

7. DOCTYPE Issues • Do NOT lie about your DOCTYPE! • If you have HTML 4.0 Transitional markup, then say so; don't claim XHTML 1.1 Strict! • The DOCTYPE you use will trigger one of two layout models in recent browsers • Old, missing, or transitional DOCTYPEs will trigger "legacy" layout mode • XML, XHTML, and strict DOCTYPEs will trigger "standards" layout mode

8. Legacy vs. Standards • What's the difference? • Plenty—too much to list here, in fact! Some highlights: • 'height' and 'width' do not apply to inline elements • 'width' means the content's width, not the aggregate of content + padding + border • 'class' and 'id' values are case-sensitive • units are required on length measures • 'body' and 'html' can be styled separately

9. Common Errors • We see a lot of recurring problems… • Generally poor structure: • TD elements outside of TRs • Unclosed TABLE elements • SPANs wrapped around DIVs • Badly-nested inline elements • FORMs spread across multiple cells, or wrapped around a few rows or cells of a table • Class and ID names treeated as though they're case-insensitive

10. An Example of Bad FORM • Have you ever done this? • <table> <form action="script.cgi" method="put"> <tr>…</tr> </form></table> • That construct is invalid and can cause functionality and layout problems • Similarly, putting the <form> in one cell and </form> in a different cell is a bad idea

11. Even Worse Markup • Here's a popular one: • <span class="someThing"> <div>…</div></span> • Yikes! Wrapping an inline element around a block-level element is no good • The beginning of a block-level element implicitly terminates any unclosed elements, so the 'span' ends right before the 'div' begins • Convert the 'span' to a 'div', adjust your styles and scripts as necessary, and be happy

12. Enjoy the Free DOM • Both IE5+ and NS6 follow the W3C DOM • You can manipulate style, structure, even content in a truly cross-browser fashion • Any other standards-compliant browser will be able to run the same scripts and get the same results

13. The Proof Is In The Showing • A working example: • <http://developer.netscape.com/evangelism/ sidebar/html401qr/attr.html> • The show/hide functionality is all W3C DOM-based and does no browser detection at all • Confession: there's an OS detect to set the proper graphic effect for the icons

14. Picking a Piece of HTML • There are two basic choices • document.getElementById('idname') • Lets you manipulate whatever element in the document has that unique 'id' value • document.getElementsByTagName('tagname') • Lets you manipulate all elements of a given type • There isn't a way to select elements by class name, so we'll just have to build one ourselves

15. getElementsByClassName • The source: • function getElementsWithClassName(elementName,className) { var allElements = document.getElementsByTagName(elementName); var elemColl = new Array(); for (i = 0; i < allElements.length; i++) { if (allElements[i].className == className) { elemColl[elemColl.length] = allElements[i]; } } return elemColl;} • Use notes: • To get all elements with a given class call getElementsWithClassName('*','className'); • Doesn't work with non-standard browsers (including IE4 and NN4.x)

16. Forked Source • The source: • function getElementsWithClassName(elementName,className) { var allElements; = document.getElementsByTagName(elementName); var elemColl = new Array(); if (document.getElementsByTagName) allElements= document.getElementsByTagName(elementName); else if (document.all) { // -=-=- IE4 code fork -=-=- if (elementName=='*') allElements= document.all; else allElements= document.all.tags(elementName); } for (i = 0; i < allElements.length; i++) { if (allElements[i].className == className) { elemColl[elemColl.length] = allElements[i]; } } return elemColl;}

17. 21st Century Forking • The past: • Forking the script for every browser you want to support • Changing the behavior means rescripting in every tine • The present: • One script, many browsers • Changing the behavior is a one-time thing • Caveat: support for older browsers still requires forking • Of course, you probably already have that code available

18. If You Must Detect… • …do it properly! • Detecting on the browser name (navigator.appName) is NOT enough! • Both Netscape 4.x and Netscape 6.x will return "Netscape" • There needs to be some parsing of the user agent string to see who created the browser and what version it is • There are some good practical sniffers on mozilla.org

19. In Summary • Simple steps for simpler authoring • Transition from away from proprietary DOMs and toward the W3C DOM • The only code forks you should need are for old browsers that aren't up to standard • Validate your markup and CSS, and make sure your DOCTYPE is correct • Remember that the DOCTYPE affects which layout mode modern browsers will use