The title and meta tags in the head of the document tell browsers and search engines more about the page. See the following code for an example:

<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
  <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
  <meta name="viewport" content="initial-scale=1, maximum-scale=1,user-scalable=no"/>
  <title>Census Map</title>

Some tags tell search engines how to read and categorize the content of your website. Others, like the meta tags in this file, tell the browser how to display and manipulate the page. In the preceding code the first meta tag, we're establishing the character set used to render text. The second meta tag tells Internet Explorer browsers to load the page using the latest version available. The third meta tag tells mobile browsers that the content is scaled to the correct size, disabling the ability to pinch or spread your fingers on the screen in order to zoom the text in and out. This is different from zooming the map scale in and out, and this tag is required in most mobile browsers to zoom in and out of the map.

The look of a website is determined by the CSS. These style sheets tell the browser how to lay elements on the page, what colors to make each element, how to space them out, and so on. You can see how they are arranged in the current document:

<link rel="stylesheet" href="http://js.arcgis.com/3.13/esri/css/esri.css" />
  <style>
    html, body {
      border: 0;
      margin: 0;
      padding: 0;
      height: 100%;
      width: 100%;
    }
  </style>

Here are three ways to organize and control the styling of elements by using CSS:

The ArcGIS JavaScript library requires its own style sheet to properly position the maps on the screen. Without this file, the map will not render correctly, and thus show the expected results. To load the required style sheet for the library, add a link tag and set the href attribute to point to the esri.css file.

If you're using version 3.2 or later, and your map appears on the page in a checkerboard pattern with the map tiles showing on every other square, the most likely problem is that the esri.css style sheet did not load. Make sure you reference the correct esri.css style sheet for the library version you're using. The following image shows an example of this behavior:

Our JavaScript code adds a variable that tells Dojo how it should load, in the first script tags. From this script, we can tell the browser how to interpret specially defined HTML elements in our document, whether we want the browser to cache all files, and even how to load packages and other libraries into the Dojo build system:

  <script type="text/javascript">
    dojoConfig = {
      parseOnLoad: true, 
      cacheBust: true
    };
  </script>

In this case, we're telling Dojo to parse any specially decorated HTML elements in the body, and replace them with the appropriate Dojo widgets as the page is loaded. Using the cacheBust parameter, we are also asking the browser to use a timestamp when it loads the files, so that the files aren't cached in the browser. Adding timestamps forces the browser to load a fresh copy of the JavaScript file, rather than relying on a cached copy. Cached scripts under active development may not show the most recent changes you made, slowing development and increasing troubleshooting time.

The ArcGIS JavaScript library is the main tool you'll use to render, manipulate, and interact with geographic data from the ArcGIS Server:

<script type="text/javascript" src="http://js.arcgis.com/3.13/" ></script>

This application, as well as other applications in the book, use version 3.13 of the ArcGIS JavaScript API. It was the most current version available at the time the book was written. As you maintain these applications, be aware of version number updates. ESRI often releases new versions to add new features, fix bugs in previous versions, and to keep the API compliant with the latest browsers.

Our client specified that they would like the app to show two panels, a main map panel, and a separate panel that explains what the user is supposed to do. We're going to fulfill the request by blocking off the sections using HTML div elements. The div elements are generic blocks of content in HTML. In the first div, we'll add a styling class of instructions, and fill it with the appropriate instructions. In the second div, we'll apply the specific element id of map, to tell ourselves and the ArcGIS JavaScript API where to put the map:

<body>
  <div class="instructions">
    <h1>U.S. Census for 2000</h1>
    <p>Click on the map to view census data for the state, census tract, and block.</p>
  </div>
  <div id="map"></div>
</body>

We need to add some style to the new elements we added. To do this, we'll modify the original internal style sheet in the head portion of the application. Our client wants the map to take up the whole screen, with a little space in the upper right-hand corner for the map title and the instructions. The client hasn't decided on colors yet, but they have requested the rounded corners that everybody's putting on their websites today.

So, after reviewing the requirements, and looking up how to style the elements, let's add the following within the <style></style> element. The changes have been highlighted to help you see what has changed in the following code snippet:

<style>
  html, body, #map {
 border: 0;
 margin: 0;
 padding: 0;
 width: 100%;
 height: 100%;
  }
  .instructions {
      position: absolute;
      top: 0;
      right: 0;
      width: 25%;
      height: auto;
      z-index: 100;
      border-radius: 0 0 0 8px;
      background: white;
      padding: 0 5px;
  }
  h1 {
      text-align: center;
      margin: 4px 0;
  }
</style>

Here's an explanation of the style we've added. We want the HTML document, the map <div> to have no margin, border, or padding, and take up the full height of the page. We also want the <div> elements with the instructions class to be precisely positioned in the top right corner, taking up twenty-five percent of the page's width, and then its height will be determined automatically. The instructions block will be floating 100 z-index units towards the user (putting it in front of our map), and its bottom-left corner will have an 8 pixel radius curve in the lower left corner. It will have a white background, and a little padding on the right and left side. Finally, the title <h1> will be centered horizontally, with a little padding above and below it.

If we look at our web page now, we won't see much. Just a title and instructions in the upper right-hand corner. We need to turn this plain page into a fully powered map application. To do that, we'll need to instruct the browser, by using JavaScript, on how to transform our map <div> into a map.

Just before the end of our body tag, we'll add a script tag where we'll write our JavaScript code. We put our script near the end of our HTML document because, unlike images and style sheets, browsers load script tags one at a time. While the browser is loading the script, it doesn't load anything else. If you put it at the beginning of the page, the user might notice a bit of latency, or a delay before the page loads. When we put a script at the end, the user is too distracted by the images and other elements on the page to notice when your script loads. This gives it the appearance of loading faster:

  <div id="map"></div>
  <script type="text/javascript"></script>
</body>

So, why didn't we load the ArcGIS JavaScript library at the end of the page? There will be times, especially if you are using other parts of Dojo, when we'll need the library to manipulate the page as it loads in the browser. In that case, we put the library reference at the head of the HTML document.

Now that we have a script tag to write some JavaScript, we can code up an interactive map. But, before we start writing code, we need to understand how to use the ArcGIS JavaScript API and Dojo. We'll start with a quick history lesson.

Back in the good old days of web development, and even continuing today, JavaScript libraries tried to avoid colliding into one another by creating a single global object (such as JQuery's $ or Yahoo's YUI). All of the library's features would be built into that object. If you've used the Google Maps API, you've probably used google.maps.Map() to create a map, and google.maps.LatLng() to load a point on that map. Each subpart of the library is separated by a dot (.).

Older versions of the ArcGIS JavaScript library were no different. All of ESRI's mapping libraries were loaded into the main "esri" object. You could create a map using esri.map, and load it with an esri.layer.FeatureLayer to show some data, for instance. The Dojo framework was similar, using the dojo, dijit, and dojox global objects.

But this tree-like approach to JavaScript library design has its downsides. As the library expands and matures, it builds up a lot of parts that developers didn't always use. We might use a library for one or two specific features, but we may not use every single tool and function the library offers. The parts of the library we don't use waste client bandwidth, bloat the memory, and make our app appear slower to load.