DOCSLIB.ORG

Unobtrusive Javascript 1 Unobtrusive Javascript

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Unobtrusive Javascript 1 Unobtrusive Javascript Unobtrusive JavaScript 1 Unobtrusive JavaScript Part of a series on JavaScript • JavaScript syntax • JavaScript library • Unobtrusive JavaScript Unobtrusive JavaScript is a general approach to the use of JavaScript in web pages. Though the term is not formally defined, its basic principles are generally understood to include: • Separation of functionality (the "behavior layer") from a Web page's structure/content and presentation[1] • Best practices to avoid the problems of traditional JavaScript programming (such as browser inconsistencies and lack of scalability) • Progressive enhancement to support user agents that may not support advanced JavaScript functionality[2] A new paradigm JavaScript historically has had a reputation for being a clumsy, hackish language unsuitable for serious application development.[3][4] This has been largely due to inconsistent implementations of the language itself and the Document Object Model[5] in various browsers, and the widespread use of buggy copy-and-paste code. Runtime errors were so common (and so difficult to debug) that few programmers even tried to fix them, as long as the script behaved more or less the way it was supposed to;[6] scripts often failed completely in some browsers. The recent emergence of standards-compliant browsers, JavaScript frameworks and high-quality debugging tools have made organized, scalable JavaScript code possible, and the emergence of Ajax interfaces has made it desirable. Whereas JavaScript was once reserved for relatively simple and non-critical tasks such as form validation and decorative novelties, it is now being used to write large, complex codebases that are often part of a site's core functionality. Run time errors and unpredictable behavior are no longer minor annoyances; they are fatal flaws. Advocates of unobtrusive JavaScript see it as part of the larger Web standards movement; much as the demand for cross-browser compatibility has driven the increasing emphasis on standardized markup and style, the increasing demand for rich Internet applications is driving the movement toward better practices with the use of JavaScript. The concept of unobtrusiveness in relation to JavaScript programming was coined in 2002 by Stuart Langridge[7] in the article "Unobtrusive DHTML, and the power of unordered lists [8]".[9] In the article Langridge argues for a way to keep all JavaScript code, including event handlers, outside of the HTML. Stuart Langridge has since expanded upon this thought in book[10] and article format.[11] Other authors have tried to refine and define the essential elements of the unobtrusive paradigm. David Flanagan's seminal JavaScript: The Definitive Guide says that while there is no specific formula, there are three main goals: 1. To separate JavaScript from HTML markup, as well as keeping modules of JavaScript independent of other modules. 2. Unobtrusive JavaScript should degrade gracefully - all content should be available without all or any of the JavaScript running successfully. 3. Unobtrusive JavaScript should not degrade the accessibility of the HTML, and ideally should improve it, whether the user has personal disabilities or are using an unusual, or unusually configured, browser.[] The Web Standards Project describes four benefits of unobtrusive DOM scripting in their JavaScript Manifesto. 1. Usability: An unobtrusive DOM script does not draw the attention of the user - visitors use it without thinking about it. Unobtrusive JavaScript 2 2. Graceful degradation: Unobtrusive DOM scripts never generate error messages, in any browser, even when they fail. If features cannot be presented properly, they silently disappear. 3. Accessibility: If any script fails, the page still delivers its core functions and information via the markup, stylesheets and/or server-side scripting. 4. Separation: For the benefit of other and future web developers, all JavaScript code is maintained separately, without impacting other files of script, markup or code.[12] For the Paris Web Conference in 2007, Christian Heilmann identified seven rules of Unobtrusive JavaScript. 1. Do not make any assumptions: Defensive programming techniques should allow for the possibilities that JavaScript may not run, the browser may not support expected methods, the HTML may have changed, unexpected input devices may be in use and other scripts may either not be present or may be encroaching on the global namespace. 2. Find your hooks and relationships, such as IDs and other aspects of the expected HTML. 3. Leave traversing individual DOM objects to the experts, such as to the CSS handler built into the browser where possible. 4. Understand browsers and users, particularly how they fail, what assumptions they make, and unusual configurations or usages. 5. Understand events, including how they 'bubble' and the features of the Event object that is passed to most event handlers. 6. Play well with other scripts by avoiding global function and variable names. 7. Work for the next developer by using self-explanatory variable and function names, creating logical and readable code, making dependencies obvious, and commenting any code that still might confuse.[] Separation of behavior from markup Traditionally, JavaScript was often placed inline together with an HTML document's markup. For example, the following is a typical implementation of JavaScript form validation when written inline: <input type="text" name="date" onchange="validateDate()" /> Adherents to "Unobtrusive Javascript" argue that the purpose of markup is to describe a document's structure, not its programmatic behavior and that combining the two negatively impacts a site's maintainability for similar reasons that combining content and presentation does. They also argue that inline event handlers are harder to use and maintain, when one needs to set handlers for several events on a single element, when one wants to set the same event handler on several elements, or when one is using event delegation. Nor can they be used with custom events. The unobtrusive solution is to register the necessary event handlers programmatically, rather than inline. Rather than adding the onchange attribute explicitly as above, the relevant element(s) are simply identified, for example by class, id or some other means in the markup: <input type="text" name="date" id="date" /> A script that runs when the page is first loaded into the browser can then look for the relevant element(s) and set them up accordingly: window.onload = function() { document.getElementById('date').onchange = validateDate; }; Unobtrusive JavaScript 3 Namespaces Unobtrusive JavaScript should add as little as possible to the global object or global namespace of the environment in which it runs. Other scripts may override any variable or function that is created in the global namespace, and this can lead to unexpected failures that are difficult to debug. JavaScript does not have a built-in explicit namespace mechanism, but the desired effects are easy to produce using the language's facilities. Flanagan suggests the use of the developer's own domain name, dotted segments reversed, as a single global name to publish that is very likely to be unique, in the style developed in the Java language.[13] var org; if (!org) { org = {}; } else if (typeof org != 'object') { throw new Error("org already exists and is not an object."); } if (!org.example) { org.example = {}; } else if (typeof org.example != 'object') { throw new Error("org.example already exists and is not an object."); } While variables, functions and objects of all kinds can be further defined within such namespace objects, it is usually recommended to use closures within the namespace to further isolate what will become private variables and functions, as well as to export what will be the public interface of each module of functionality. The code above could be followed directly by the following:[] org.example.Highlight = function() { // Define private data and functions var highlightId = 'x'; function setHighlight(color) { document.getElementById(highlightId).style.color = color; } // Return public pointers to functions or properties // that are to be public. return { goGreen: function() { setHighlight('green'); }, goBlue: function() { setHighlight('blue'); } } }(); //End closure definition and invoke it. From any other module, these public methods could be invoked in either way as follows org.example.Highlight.goBlue(); var h = org.example.Highlight; h.goGreen(); In this way, each module-writer's code is contained in private or in a unique namespace and cannot interfere with or intrude upon any other code at any time. Unobtrusive JavaScript 4 Degrading gracefully Writing an event listener that detects the loading of the HTML page and then adds relevant listeners to other events on the page, as well as other behaviors as required, can solve the problem of separating JavaScript functionality from HTML markup. The use of client-side JavaScript libraries such as jQuery, MooTools or Prototype can simplify this process and help ensure that individual browser and browser version implementation details are hidden and catered for. Keeping most of the JavaScript out of the default namespace helps ensure that it is as unobtrusive as possible in that sense. A further criterion of unobtrusive Javascript that is often cited is to ensure that added behavior degrades gracefully on those browsers with unexpected configurations, and those on which the user may have disabled JavaScript altogether.[] This requirement
Load more

Recommended publications
  • Interaction Between Web Browsers and Script Engines
    IT 12 058 Examensarbete 45 hp November 2012 Interaction between web browsers and script engines Xiaoyu Zhuang Institutionen för informationsteknologi Department of Information Technology Abstract Interaction between web browser and the script engine Xiaoyu Zhuang Teknisk- naturvetenskaplig fakultet UTH-enheten Web browser plays an important part of internet experience and JavaScript is the most popular programming language as a client side script to build an active and Besöksadress: advance end user experience. The script engine which executes JavaScript needs to Ångströmlaboratoriet Lägerhyddsvägen 1 interact with web browser to get access to its DOM elements and other host objects. Hus 4, Plan 0 Browser from host side needs to initialize the script engine and dispatch script source code to the engine side. Postadress: This thesis studies the interaction between the script engine and its host browser. Box 536 751 21 Uppsala The shell where the engine address to make calls towards outside is called hosting layer. This report mainly discussed what operations could appear in this layer and Telefon: designed testing cases to validate if the browser is robust and reliable regarding 018 – 471 30 03 hosting operations. Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student Handledare: Elena Boris Ämnesgranskare: Justin Pearson Examinator: Lisa Kaati IT 12 058 Tryckt av: Reprocentralen ITC Contents 1. Introduction................................................................................................................................
    [Show full text]
  • RESPONSIVE Elearning DESIGN & DEVELOPMENT Contents
    RESPONSIVE eLEARNING DESIGN & DEVELOPMENT Contents Chapter 1 A Responsive World 1.1: How It All Began 4 1.2: Responsive Design: Understanding the Term 7 Chapter 2 Understanding Responsive eLearning Design 2.1: The Need for Responsive Design in eLearning 10 2.2: Key Features of Responsive Design 12 2.3: Adaptive Vs. Responsive Design 14 2.4: Benefits of Responsive eLearning Design 21 2.5: What Does a Responsive eLearning Design Look Like? 23 Contents Chapter 3 Determining a Responsive eLearning Design Strategy 3.1: When to Use Responsive eLearning Design 28 3.2: Getting Started Responsively 31 3.3: Challenges and Solutions 34 3.3.1: Design 35 3.3.2: Development 52 3.3.3: Testing 57 Chapter 4 Conclusion Share Some Love 65 References 66 Authors 69 A Responsive World 1 1.1: How It All Began From the launch of desktop PCs and laptops to the mass adoption of tablets and smartphones, the world of connected devices has expanded—and how! Today, individuals own multiple devices and shift seamlessly between them depending on task, location and time of day. The primary device that connects them to the World Wide Web is likely to be anything from a smartphone or phablet to a tablet or PC. 4 A Responsive World 1 1.1: How It All Began In 2012, Google released a comprehensive report on the emerging use of multiple devices. This report states that 90% of our daily media interactions are screen based, with our time online primarily spread between four devices—television, desktop PCs/laptops, tablets and finally smartphones.
    [Show full text]
  • Defensive Javascript Building and Verifying Secure Web Components
    Defensive JavaScript Building and Verifying Secure Web Components Karthikeyan Bhargavan1, Antoine Delignat-Lavaud1, and Sergio Maffeis2 1 INRIA Paris-Rocquencourt, France 2 Imperial College London, UK Abstract. Defensive JavaScript (DJS) is a typed subset of JavaScript that guarantees that the functional behavior of a program cannot be tampered with even if it is loaded by and executed within a malicious environment under the control of the attacker. As such, DJS is ideal for writing JavaScript security components, such as bookmarklets, single sign-on widgets, and cryptographic libraries, that may be loaded within untrusted web pages alongside unknown scripts from arbitrary third par- ties. We present a tutorial of the DJS language along with motivations for its design. We show how to program security components in DJS, how to verify their defensiveness using the DJS typechecker, and how to analyze their security properties automatically using ProVerif. 1 Introduction Since the advent of asynchronous web applications, popularly called AJAX or Web 2.0, JavaScript has become the predominant programming language for client-side web applications. JavaScript programs are widely deployed as scripts in web pages, but also as small storable snippets called bookmarklets, as down- loadable web apps,1 and as plugins or extensions to popular browsers.2 Main- stream browsers compete with each other in providing convenient APIs and fast JavaScript execution engines. More recently, Javascript is being used to program smartphone and desktop applications3, and also cloud-based server ap- plications,4 so that now programmers can use the same idioms and libraries to write and deploy a variety of client- and server-side programs.
    [Show full text]
  • Opera Software the Best Browsing Experience on Any Device
    Opera Software The best browsing experience on any device The best Internet experience on any device Web Standards for the Future – Bruce Lawson, Opera.com • Web Evangelist, Opera • Tech lead, Law Society & Solicitors Regulation Authority (2004-8) • Author 2 books on Web Standards, edited 2 • Committee member for British Standards Institution (BSI) for the new standard for accessible websites • Member of Web Standards Project: Accessibility Task Force • Member of W3C Mobile Best Practices Working Group Web Standards for the Future – Bruce Lawson, Opera.com B.A., Honours English Literature and Language with Drama Theresa is blind But she can use the Web if made with standards The big picture WWW The big picture Western Western Web A web (pre)history • 1989 TBL proposes a project • 1992 <img> in Mosaic beta. Now 99.57% (MAMA) • 1994 W3C started at MIT • 1996 The Browser Wars • 1999 WAP, Web Content Accessibility Guidelines (WCAG) • 2000 Flash Modern web history • 2000-ish .com Crash - Time to grow up... • 2002 Opera Mobile with Small Screen Rendering • 2005 WHAT-WG founded, W3C Mobile Web Initiative starts • 2007 W3C adopts WHAT-WG spec as basis for HTML 5 • January 22, 2008 First public working draft of HTML 5 Standards at Opera • 25 employees work on standards • Mostly at W3C - a big player • Working on many standards • Bringing new work to W3C • Implementing Standards properly (us and you!) (Web Standards Curriculum www.opera.com/wsc) Why standards? The Web works everywhere - The Web is the platform • Good standards help developers: validate; separate content and presentation - means specialisation and maintainability.
    [Show full text]
  • Sams Teach Yourself Javascript in 24 Hours
    Phil Ballard Michael Moncur SamsTeachYourself JavaScript™ Fifth Edition in Hours24 800 East 96th Street, Indianapolis, Indiana, 46240 USA Sams Teach Yourself JavaScript™ in 24 Hours, Fifth Edition Editor-in-Chief Mark Taub Copyright © 2013 by Pearson Education, Inc. All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, Acquisitions Editor or transmitted by any means, electronic, mechanical, photocopying, recording, or other- Mark Taber wise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has Managing Editor been taken in the preparation of this book, the publisher and author assume no responsi- Kristy Hart bility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein. Project Editor ISBN-13: 978-0-672-33608-9 Anne Goebel ISBN-10: 0-672-33608-1 Copy Editor Library of Congress Cataloging-in-Publication Data is on file. Geneil Breeze Printed in the United States of America First Printing October 2012 Indexer Erika Millen Trademarks All terms mentioned in this book that are known to be trademarks or service marks have Proofreader been appropriately capitalized. Sams Publishing cannot attest to the accuracy of this Chrissy White, information. Use of a term in this book should not be regarded as affecting the validity of Language Logistics any trademark or service mark. Publishing Coordinator Warning and Disclaimer Vanessa Evans Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied.
    [Show full text]
  • Typescript-Handbook.Pdf
    This copy of the TypeScript handbook was created on Monday, September 27, 2021 against commit 519269 with TypeScript 4.4. Table of Contents The TypeScript Handbook Your first step to learn TypeScript The Basics Step one in learning TypeScript: The basic types. Everyday Types The language primitives. Understand how TypeScript uses JavaScript knowledge Narrowing to reduce the amount of type syntax in your projects. More on Functions Learn about how Functions work in TypeScript. How TypeScript describes the shapes of JavaScript Object Types objects. An overview of the ways in which you can create more Creating Types from Types types from existing types. Generics Types which take parameters Keyof Type Operator Using the keyof operator in type contexts. Typeof Type Operator Using the typeof operator in type contexts. Indexed Access Types Using Type['a'] syntax to access a subset of a type. Create types which act like if statements in the type Conditional Types system. Mapped Types Generating types by re-using an existing type. Generating mapping types which change properties via Template Literal Types template literal strings. Classes How classes work in TypeScript How JavaScript handles communicating across file Modules boundaries. The TypeScript Handbook About this Handbook Over 20 years after its introduction to the programming community, JavaScript is now one of the most widespread cross-platform languages ever created. Starting as a small scripting language for adding trivial interactivity to webpages, JavaScript has grown to be a language of choice for both frontend and backend applications of every size. While the size, scope, and complexity of programs written in JavaScript has grown exponentially, the ability of the JavaScript language to express the relationships between different units of code has not.
    [Show full text]
  • Designing and Implementing the OP and OP2 Web Browsers
    Designing and Implementing the OP and OP2 Web Browsers CHRIS GRIER, SHUO TANG and SAMUEL T. KING, University of Illinois at Urbana-Champaign Current web browsers are plagued with vulnerabilities, providing hackers with easy access to computer systems via browser-based attacks. Browser security efforts that retrofit existing browsers have had lim- ited success because the design of modern browsers is fundamentally flawed. To enable more secure web browsing, we design and implement a new browser, called the OP web browser, that attempts to improve the state-of-the-art in browser security. We combine operating system design principles with formal methods to design a more secure web browser by drawing on the expertise of both communities. Our design philosophy is to partition the browser into smaller subsystems and make all communication between subsystems sim- ple and explicit. At the core of our design is a small browser kernel that manages the browser subsystems and interposes on all communications between them to enforce our new browser security features. To show the utility of our browser architecture, we design and implement three novel security features. First, we develop flexible security policies that allow us to include browser plugins within our security framework. Second, we use formal methods to prove useful security properties including user interface invariants and browser security policy. Third, we design and implement a browser-level information-flow tracking system to enable post-mortem analysis of browser-based attacks. In addition to presenting the OP browser architecture, we discuss the design and implementation of a second version of OP, OP2, that includes features from other secure web browser designs to improve on the overall security and performance of OP.
    [Show full text]
  • Javascript & AJAX
    JavaScript & AJAX JavaScript had to “look like Java” only less so—be Java's dumb kid brother or boy-hostage sidekick. Plus, I had to be done in ten days or something worse than JavaScript would have happened. JavaScript: the Big Picture(ELLS §11.1) © 2012 Armando Fox & David Patterson Licensed under Creative Commons Attribution- Image: Wikimedia. Used under CC-SA license. NonCommercial-ShareAlike 3.0 Unported License The Moving Parts • 1995: Netscape includes LiveScript JavaScript as browser scripting language • Originally, for simple client-side code such as animations and form input validation • Document Object Model (DOM) lets JavaScript inspect & modify document elements • 1997: standardized as ECMAScript • 1998: Microsoft adds XmlHttpRequest to IE5 • 2005: Google Maps, AJAX takes off JavaScript’s privileged position • Because it’s embedded in browser, JavaScript code can: 1. be triggered by user-initiated events (mouse down, mouse hover, keypress, …) 2. make HTTP requests to server without triggering page reload 3. be triggered by network events (e.g. server responds to HTTP request) 4. examine & modify (causing redisplay) current document DOM & JavaScript: Document = tree of objects • DOM is a language-independent, hierarchical representation of HTML or XML document • Browser parses HTML or XML => DOM • JavaScript API (JSAPI) makes DOM data structures accessible from JS code • Inspect DOM element values/attributes • Change values/attributes → redisplay • Implemented incompatibly across browsers …but jQuery framework will help us
    [Show full text]
  • Automated Cross-Browser Compatibility Testing
    Automated Cross-Browser Compatibility Testing ∗ Ali Mesbah Mukul R. Prasad Electrical and Computer Engineering Trusted Systems Innovation Group University of British Columbia Fujitsu Laboratories of America Vancouver, BC, Canada Sunnyvale, CA, USA [email protected] [email protected] ABSTRACT web browsers render web content somewhat differently [18, With the advent of Web 2.0 applications and new browsers, 24, 25, 26]. However, the scope and impact of this problem the cross-browser compatibility issue is becoming increas- has been rapidly growing due to two, fairly recent trends. ingly important. Although the problem is widely recognized First, modern, rich-content web applications have a heavy among web developers, no systematic approach to tackle client-side behavioral footprint, i.e., they are designed to ex- it exists today. None of the current tools, which provide ecute significant elements of their behavior exclusively on the screenshots or emulation environments, specifies any notion client-side, typically within the web browser. Further, tech- of cross-browser compatibility, much less check it automat- nologies such as Ajax [12], Flash, and event-handling for ically. In this paper, we pose the problem of cross-browser dynamic HTML, which support this thick-client behavior, compatibility testing of modern web applications as a `func- are the very aspects in which web browsers differ. tional consistency' check of web application behavior across Second, recent years have seen an explosion in the num- different web browsers and present an automated solution ber of available web browsers. There are nearly 100 different for it. Our approach consists of (1) automatically analyzing web browsers available today [31].
    [Show full text]
  • Web UI Animation
    Web UI Animation Group 5 Rok Kogovšek, Alexei Kruglov, Fernando Pulido Ruiz, and Helmut Zöhrer 706.041 Information Architecture and Web Usability WS 2016 Graz University of Technology A-8010 Graz, Austria 12 Dec 2016 Abstract This survey tries to give insights into the uses of web animations and possible ways of creating them with CSS and JavaScript. Not only, why they should be used on a website, but also when to use CSS or JavaScript, will be covered. We also explore the enhancement of animation through SVG. In addition to the theoretical background, numerous practical code examples will be included and discussed. © Copyright 2016 by the author(s), except as otherwise noted. This work is placed under a Creative Commons Attribution 4.0 International (CC BY 4.0) licence. It uses the LaTex template from "Writing a Survey Paper" by Keith Andrews, used under CC BY 4.0 / Desaturated from original Contents Contents i List of Figures iii List of Listings v 1 Introduction 1 2 Animation 3 2.1 Not Just Motion! . .3 2.2 Why Animation in Web UI? . .3 2.3 Aim For Invisible Animation . .4 2.4 Development of Animation . .4 3 Cascading Style Sheets (CSS)7 3.1 Do Everything You Can With CSS . .7 3.2 CSS Animation Declaration . .8 3.2.1 Animation Property and Keframe Rule . .8 3.2.2 Transition Property and Selector Pattern . 10 3.2.3 Powerful Effect from Single Property . 10 3.3 CSS Examples . 11 3.3.1 Navigation Animation . 11 3.3.2 Loading Animation .
    [Show full text]
  • Aaron Gustafson, Presentation in English
    PROGRESSIVE ENHANCEMENT &MOBILE Aaron Gustafson @aarongustafson slideshare.net/AaronGustafson BROWSERS ARE A PAIN IN THE ASS AND THEN THERE’S MOBILE © Brad Frost © Brad Frost WHAT IS MOBILE? WHAT IS MOBILE? “There is no WebKit on Mobile — Peter-Paul Koch “There is no WebKit on Mobile — Peter-Paul Koch http://www.quirksmode.org/webkit.html “There is no Android — Stephanie Rieger http://yfrog.com/z/ob5kndj http://yfrog.com/z/ob5kndj http://yfrog.com/z/ob5kndj WHAT IS MOBILE? Um… I think I’ll just build an iPhone app. kthxbye. NATIVE vs. WEB CONSISTENT vs. UNPREDICTABLE SPECIFIC vs. UNIVERSAL © Brad Frost © Brad Frost WE DON’T KNOW WE DON’T KNOW EVEN WHEN WE THINK WE KNOW, WE ARE PROBABLY WRONG SO HOW DO WE COPE? PROGRESSIVE ENHANCEMENT TECHNOLOGICAL RESTRICTIONS MCMLXXVII MCMLXXVII (that’s 1977) HTML CSS fault tolerance n. a system’s ability to continue to operate when it encounters and unexpected error. BROWSERS IGNORE WHAT THEY DON’T UNDERSTAND I like an escalator because an escalator can never break, it can only become stairs. — Mitch Hedberg an electric toothbrush can never break, it can only become a toothbrush. a dynamic web page can never break, it can only become a web page. GRACEFUL DEGRADATION MODERN BROWSERS OLDER BROWSERS MODERN BROWSERS OLDER BROWSERS MODERN BROWSERS OLDER BROWSERS PROGRESSIVE ENHANCEMENT CONTENT CONTENT ACCESSIBILITY “SPECIAL NEEDS” “SPECIAL NEEDS” “SPECIAL NEEDS” CAN BE CONTEXTUAL PROGRESSIVE GRACEFUL DEGRADATION ENHANCEMENT OOOH, SHINY! PROGRESSIVE ENHANCEMENT ISN’T ABOUT BROWSERS BROWSERS AND TECHNOLOGIES
    [Show full text]
  • Ch08-Dom.Pdf
    Web Programming Step by Step Chapter 8 The Document Object Model (DOM) Except where otherwise noted, the contents of this presentation are Copyright 2009 Marty Stepp and Jessica Miller. 8.1: Global DOM Objects 8.1: Global DOM Objects 8.2: DOM Element Objects 8.3: The DOM Tree The six global DOM objects Every Javascript program can refer to the following global objects: name description document current HTML page and its content history list of pages the user has visited location URL of the current HTML page navigator info about the web browser you are using screen info about the screen area occupied by the browser window the browser window The window object the entire browser window; the top-level object in DOM hierarchy technically, all global code and variables become part of the window object properties: document , history , location , name methods: alert , confirm , prompt (popup boxes) setInterval , setTimeout clearInterval , clearTimeout (timers) open , close (popping up new browser windows) blur , focus , moveBy , moveTo , print , resizeBy , resizeTo , scrollBy , scrollTo The document object the current web page and the elements inside it properties: anchors , body , cookie , domain , forms , images , links , referrer , title , URL methods: getElementById getElementsByName getElementsByTagName close , open , write , writeln complete list The location object the URL of the current web page properties: host , hostname , href , pathname , port , protocol , search methods: assign , reload , replace complete list The navigator object information about the web browser application properties: appName , appVersion , browserLanguage , cookieEnabled , platform , userAgent complete list Some web programmers examine the navigator object to see what browser is being used, and write browser-specific scripts and hacks: if (navigator.appName === "Microsoft Internet Explorer") { ..
    [Show full text]