Recently I was digging around in the Safari Developer Library when I came across one more reason (as if there weren’t enough) to write Unobtrusive JavaScript. In this case, Safari on iOS (all devices) disables preload="" and autoplay="", in case the user may be in a position where they are on a horrid network and are being charged per data unit. So no data is actually loaded until initated by the user; this also implies that the play() and the load()methods are inactive until user initiated playback, unless the play() or load()method is triggered via user action. So in laymens terms, user-initiated Play buttons work, however the onload="play()"eventdoes not. Safari Developer Library provided the solution below:
This works as-is, however the event handler is still mixed in with the markup thus violating the Seven Rules of Unobtrusive JavaScript, specifically number five:
5. Understand Events (Event handling to initiate change)
Event handling is the next step to truly Unobtrusive JavaScript…understand that Event Handling is true separation.
So I rewrote the Safari solution using Web Standards and separated behavior (JavaScript) from structure (html) using Unobtrusive JavaScript. I don’t have any video files available for the demo so I swapped audio in its place, as well as added some updated (read: “proper”) markup, but the principle(s) are not lost. The demo is a media control that will play a media file after user-initiated contact with the play button. You can view the demo here or view the code and markup below:
// javascript
window.onload = function() {
// Get the play button and append the audio play method to on click
var audio = document.getElementById("audiosrc");
var play = document.getElementById('play');
play.addEventListener('click', function(){
audio.play(); }, false);
}
<!-- html -->
<button type="button" id="play">
<audio id="audiosrc">
<source src="http://dev.bowdenweb.com/a/m/a/clipping_link-finds-a-secret-13908.ogg" />
<source src="http://dev.bowdenweb.com/a/m/a/clipping_link-finds-a-secret-13908.mp3" />
<source src="http://dev.bowdenweb.com/a/m/a/clipping_link-finds-a-secret-13908.wav" />
</audio>
</button>
I love css Sprites so I was quite dismayed to read about problems with iPhone 4 Retina Display (High dpi) and problems with accessibility, both of which will stop a standardista dead in their tracks. Retina Display is a user-agent feature and as such should at least be used to progressively enhance the ux, not degrade it! User-Agent Features are seen as bothersome and/or afterthoughts in most circles, however they are vital for creating unique browsing experiences for each applicable unique user-agent setting. The accessibility issue is a no-brainer, it must be resolved; Accessibility should be a part of your work-flows and not an afterthought. One thing about the bad accessibility in particular stood out to me:
In conclusion, the only method that is truly accessible and supported by nearly all browsers is to use inline images instead of background CSS images to display non-decorative content. If sprite maps are required then consider using inline positioned sprite maps.
Responsive Design via css media-queries is a principle of progressive enhancement that is a staple of Front-End Engineering and for the most part solves all cross-browser and cross-platform issues. By applying rwd via media-queries, it occured to me that you could use the sprites still, but apply it to inlineimg‘s via clipproperty. Then to alter the clipproperty style settings via media-queries, swapping bigger images for bigger resolutions. It works like a charm, although I’m not sure how accessible they are. You can view the demo here
Quick follow up to my last post regarding semantic glossaries: dictionary.com uses audio examples to express correct pronunciation. While I don’t think this practice is necessary for most glossaries, I can’t see how it would hurt any of them. If anything, you’d simply be adding accessibility coverage, which should always be a goal for a site, even if it’s in the long-run. Plus, in a very miniscule way, you’re adding more content, so it seemingly should help with seo. So, simple enough, right? Just add audio into the rubyelement and we’re good, right? Not so fast, I quickly found out that cross-browser styling of audio isn’t very well documented, even though I’m positive it’s doable.
For starters, I grabbed the speaker icon via the Noun Project to show users that there is audio content to hear. It is an svg and I had planned on adding cross-browser compatibility for it, however considering the audio roadblock I hit, I decided to just publish this now and I’ll work on that once I get it to play in all browsers. Then I grabbed an audio file, I don’t have a microphone, so I couldn’t create the actual word pronunciation which is lame, but I figured this is just for demonstration purposes only. I used media.io to generate .ogg and .wav files for (what I thought was) cross-browser compatibility. And I thought I was good to go, but clearly this was not the case.
Fallback via button
Once I ran into the audio styling roadblock, I lamely wrapped it up into a buttonelement. I thought for sure this would be the silver bullet. Negative, Ghost Rider. I hooked the button into the audioelement‘s onclickevent handler and provided 3 separate audio formats (.mp3 for Webkit, .ogg for Gecko and .wav for Presto) via sourceelement. Here’s the markup and JavaScript:
window.onload = function() {
var audio = document.getElementById("audiosrc");
var play = document.getElementById("play");
play.addEventListener('click', function(){
audio.play();
}, false);
}
Note: this doesn’t work in Opera 11.5, which is baffling to me. From what I can understand, Opera supports .ogg, but once I saw it not working, I actually created the .wav file specifically for Opera, and still no bueno. After struggling with this for a few hours, I’ve given up at the moment, so I’m quite positive that this won’t work in ie without testing. I’ll be sure to follow up on this as soon as I find more out and/or find a more elegant cross-browser solution. You can check out the Accessible Semantic Glossary demo here.
Image Search is one aspect of Web Development typically overlooked by the vast majority of developers. While it may seem a distant second to the primary goal of Search, it’s actually not that far off. Image naming conventions, when properly applied, can aid in a sites Search, Searchability and Findability.
Typical image naming conventions in Web Development include image-01.png or even worse blargherghdadurpdedoo.png; while they do serve as a unique identifier and therefore conform to their primary purpose, they can be utilized for much more by providing machine-readable text that can be understood by bots when crawling your site(s). Bots have no clue what the below image is:
Bots crawling your site will now index this image with reference to “Jordan Dunking vs. Lakers”, which provides an extremely more relevant and detailed description than “23432asaere”.
Apply the kiss Principle here: don’t overthink your file names, thereby (even if not intentional) spamming keywords via your file names. I like to rely on two or three word names for images.
Image Naming Rules
Separate words with hyphens (-)
Using at most two or three keywords
Use only alphanumeric characters and hyphens in file names, not underscores (_), spaces (, or special characters
Use descriptive Directory Naming Conventions in tandem with Image Naming Conventions
Added Benefits of Precise Image Naming Conventions
Image Naming Conventions also will aid in a sites Information Architecture, organizing files and directories to benefit your development team, as well as users and bots. Your team can also use them to track document versions, like so:
<img src="screenshot-issue-11-04-2009-001" />
Adding Precise Image Naming Conventions to Workflows
Adding image naming conventions to your workflow(s) is extremely easy and should not be overthought. Simply think about what an image is before you name it. If the image is part of a set, think about suffixing a number to the end of all the images in the set, or putting them all into a directory, that aptly names the set. It’s really that simple, and you’ll greatly benefit by making this part of your development process instead of a post development afterthought.
Dublin Core is a set of metadata elements that provide a fundamental group of text elements through which most resources can be described and catalogued. A Dublin Core metadata record is intended to be used for cross-domain information resource description and have become standards in the fields of library science and computer science.
Dublin Core Metadata Initiative (dcmi) was incorporated as in independent entity, providing an open forum for developing interoperablemetadata standards ecompassing a broad range of purposes and business models.
The Dublin Core standard includes two levels: Simple and Qualified. Simple Dublin Core comprises 15 elements, while Qualified Dublin Core includes three additional elements and qualifiers that refine the semantics of the elements so they are useful in resource discovery. The context of this blog post will focuses on the Simple Dublin Core Metadata Element Set in conjunction with a related linkelement.
Utilizing Dublin Core meta elements provides ways for a document to be indexed using several distinct, searchable fields. Thus, the document can be searched by said fields meaning it can be located more specifically than documents not using Dublin Core, therefore increasing findability, searchability and locatability.
Simple Dublin Core Metadata Element Set
The Simple Dublin Core Metadata Element Set (DCMES) consists of 15 metadata elements, listed below:
Title
Markup
Description
Each Dublin Core element is optional and may be repeated. The DCMI has established standard ways to refine elements and encourage the use of encoding and vocabulary schemes. There is no prescribed order in Dublin Core for presenting or using the elements.
Contributor
meta name="DC.Contributor" content="publisher-name" /
An entity responsible for making contributions to the resource. Examples include a person, organization or service. Typically, the name of a Contributor should be used to indicate the entity.
Coverage
meta name="DC.Coverage" content="World" /
Spatial or temporal topic of the resource, spacial applicability of the resource or the jurisdiction under which the resource is relevant. Spatial topic and spatial applicability may be a named place or a location specified by geographic coordinates. Temporal topic may be a name period, date or date range. Jurisdiction may be a named administrative entity or a geographic place to which the resource applies. Best practice here is to used a controlled vocabulary such as the tgn. If appropriate, named places or time periods can be used in preference to numeric identifiers (such as sets of coordinates or date ranges).
Creator
meta name="DC.Creator" content="Administrator" /
An entity primarily responsible for making the resource, like a person, organization or service. Typically, the name of a Creator should be used to indicate the entity.
Date
meta name="DC.Date" scheme="W3CDTF" content="2004-01-01"/
Point or period of time associated with an event in the lifecycle of a resource. May be used to express temporal information at any level of granularity. Best practice is to use an encoding scheme for Date.
Description
meta name="DC.Description" lang="en" content="publisher-name" /
Account of the resource; may include (but not limited to) an abstract, a table of contents, graphical representation, or a free-text account of the resource.
Format
meta name="DC.Format" scheme="IMT" content="text/html" /
File format, physical medium or dimensions of the resource. Examples of dimensions include size and duration. Best practice is to use a controlled vocabulary, as in this example using mime types.
Identifier
meta name="DC.Identifier" scheme="uri" content="http://catalog.loc.gov/67-26020" /
An unambiguous reference to the resource within a given context. Best practice is to identify said resource by means of a string conforming to a formal identification system.
Language
meta name="DC.Language" content="en" /
Language of the resource. Best practice is to use a controlled vocabulary.
Publisher
meta name="DC.Publisher" content="publisher-name" /
Entity responsible for making the resource available, including a person, service or organization. Typically the name of a Publisher should be used to indicate the entity.
Relation
meta name="DC.Relation" content="publisher-name" /
Related resource; best practice is to identify by means of a string conforming to a formal identification system.
Rights
meta name="DC.Rights" content="http://example.org/legal-terms-of-use.html" /
Information about rights held in and over the resource, typically including various property rights (including intellectual property rights) associated with the resource.
Source
meta name="DC.Source" content="/meta-tags/" /
Related resource from which described resource is derived; may be derived from the related resource in whole or in part. Best practice is to identify the related resource by means of a string conforming to a formal identification system.
Subject
meta name="DC.Subject" lang="en" content="Heart Attack" /
Topic of the resource, typically represented by keywords, key phrases or classification codes. Best practice is to use a controlled vocabulary. To describe the spatial or temporal topic of the resource use the Coverage element.
Title
meta name="DC.Title" lang="en" content="Hamlet in Iceland; being the Icelandic romantic Ambales saga" /
Resources given name, typically the name by which a resource is formally known.
Type
meta name="DC.Type" scheme="DCMIType" content="Text" /
Nature or genre of the resource, best practice is to use a controlled vocabulary, this example uses the dcmi Type Vocabulary. To describe file format, physical medium or the resources dimensions, use the Formatelement.
Note: as a general rule, element names may be mixed-case but should always have a lower-case first letter, commonly called camelCased.
Note: the value of the contentattribute is defined to be cdata.
Authors need to use the linkelement to reference the definitions comprised by the element schema, like so:
Authors can express Dublin Core metadata using simple meta and linkelements, which describe how a Dublin Core metadata description set can be encoded in (x)html, which is also an html meta data profile as defined by the html specification. Utilizing Dublin Core is an extremly easy and extensible way for authors to make their content more findable, searchable, and locatable, thus increasing their content’s overall accessibility.
Assistive Technology or Adaptive Technology refers to assistive, adaptive, and rehabilitative devices for people with disabilites, including the process used in selecting, locating, and using them.
Screen Readers - Jaws, VoiceOver, WIndowEyes
Screen Magnifiers
Captions for Audio and/or Video
High Contrast Mode
Voice Recognition and Alternative Input
Screen Readers
Screen Readers are software applications developed to interpret what is sent to standard output (displayed on screen usually) and then to display said interpretations to the user in a format accessible to their situation. Possible display implementations are text-to-speech, sound icons, Braille output device to name a few.
Screen Readers are a form of at mostly for users with vision impairments.
Orca
Orca is a free, open source, flexible, and extensible screen reader that provides access to the graphical desktop via speech, braille, magnification and combinations of the three.
Orca supports the Assistive Technology Service Provider Interface (at-spi), which is the primary assistive technology infrastructure for Solaris and Linux operating environments.
Emacspeak
Emacspeak is a speech interface that enables visually impaired users to interact independently and efficiently with the box(es). Audio formatting and full support for acss allows Emacspeak. to produce rich aural presentations of data. Ecmaspeak speech-enables local and remote information via a consistent and well-integrated user interface.
Linux Screen Reader (lsr
The lsr project is an open source effort to develop an extensibleassistive technology for the gnome desktop environment.
nvda (NonVisual Desktop Access)
nvda is a free, open sourcescreen reader for Windows (written in Python).
jaws (Job Access With Speech)
jaws is a screen reader for Windows. jaws provides users access to screen information via text-to-speech or Braille display. jaws provides users access to the jaws Scripting Language, which effectively gives them the power to make the most of their Web experience. It is also $1,000, which makes me physically ill, but providing a scripting language to let users customize as they see fit almost makes that ok in my world.
Window-Eyes
Window-Eyes is a Windows screen reader which converts components of Windows into synthesized speech allowing for complete and total access to Windows. Windows-Eyes is a ridiculous $895.00, so you have to pay the price for a second box just to be able to use your current box…on top of whatever disability you have to cope with. Personally, I’ll never recommend Windows-Eyes based on that; moreover, I’ll do everything in my power to deter anyone and everyone interested to find another solution.
VoiceOver
VoiceOver is a screen reader built for os x, enabling access to Macintosh and/or iOS devices (via spoken descriptions) and access to the Mac (via keyboard). VoiceOver not only addresses visually impaired users, it address users with dyslexia.
Screen Magnifier
A Screen Magnifier is software that interfaces with a computer’s graphical output to present enlarged screen content. It is a type of assistive technology suitable for visually impaired people with some functional vision; visually impaired people with little or no functional vision use a screen reader.
The simplest form of magnification presents an enlarged portion of the original screen content, the focus, so that it covers some or all of the full screen. This enlarged portion should include the content of interest to the user and the pointer or cursor, also suitably enlarged.
Screen Magnifiers are common in ranges of 1 – 16, the greater the magnification the smaller the proportion of the original screen that can be viewed; so users will tend to use the lowest magnification they can manage.
Common Features in Screen Magnifiers
Color Inversion – Many people with visual impairments prefer to invert the colors, typically turning text from black-on-white to white-on-black. This can reduce screen glare and is useful for those suffering from age-related macular degeneration.
Smoothing – Text can become blocky and harder to recognize when enlarged. Some Screen Magnifiersanti-alias or smooth text to compensate.
Cursor Customization – The mouse and text cursors can often be modifed in several ways, such as circling it to help the user locate it on the screen.
Different Magnification Modes – Screen Magnifiers can alter how they present the enlarged portion: covering the full screen, providing a lens that is moved around the un-magnified screen, or using a fixed magnified portion.
Screen Reader – Some magnifiers come packaged with a basic screen reader, allowing whatever the user is pointing out to be read alout.
Captions for Audio and/or Video
Closed Captioning is the process of displaying text on a television, video screen or other visual display to provide additional or interpretive information to individuals who wish to access it. Closed Captioning typically show a transcription of the audio portion of a program as it occurs (either verbatim or in edited form), sometimes including non-speech elements.
The term “closed” in closed captioning indicates that not all viewers see the captions—only those who choose to decode or activate them. This distinguishes from “open captions” (sometimes called “burned-in” or “hardcoded” captions), which are visible to all viewers.
Subtitles (captioning) are textual versions of the dialog occuring on the television; Subtitles usually appear at the bottom of the screen, displaying audio content as text.
Television teletext subtitles carry additional sound representations for deaf and hard of hearing viewers; Teletext Subtitle Language follows the original audio, except in mult-lingual countries where the broadcaster may provide subtitles in additional languages on other teletext pages.
High Contrast Mode
High Contrast is an accessibility feature designed to address visual impairments. People afflicted with visual impairment can use High Contrast Color Schemes to increase legibility via heightening screen contrast with alternative color combinations (some also enlarge the font size).
High Contrast Mode is an os feature; it is accessible in Windows by pressing Ctrl+Left Shift+PrintScreen.
In High Contrast Mode all images and colors are discarded. A predominant color pair is then used to display the entire os interface (usually white or yellow on black, or vice-versa).
Voice Recognition and Alternative Input
Voice Recognition
Voice Recognition is a software app that allows users to generate text (dictation) and/or operate a computer (command and control) using the sound of their own voice! Speech Recognition uses a neural net to become familiar with a user’s voice. This neural net is constructed from data the app captures and stores regarding pronounciation charicteristics for every single word a user says. Speech Recognition also uses grammatical context and frequency of use to try and predict the word a users wishes to input.
Alternative Inputs
Access/Ability Switches: are alternative input methods that can utilise controlled movement (from blinking one’s eyes, exhaling, a foot, etc.). Switch operation greatly varies according to its make/model and requirements of use. Switch Access is frustrating and time consuming and should be only used as a last resort.
Access/Ability Switches are ideal for users with physical impairments and/or dexterity difficulties.
Braille Keyboards
Braille Keyboards are not the magic bullet they sound like; usually they support a full standard keyboard but only allow the input of Grade 1 Braille.
Braille Keyboards are primarily used for terminal emulation software; their usage is mostly limited to blind or visually impaired users.
Ergonomic Keyboards
Ergonomic Keyboards designed and shaped to reduce pain/effort from typing. Ergonomic Keyboards are touted as Carpal Tunnel Syndrome killers, they reduce strains, movements of the arms, hands, wrists, fingers, etc.
Twiddler
Twiddler input device is strapped to a user’s hand (looks similar to a remote control); Equipped with twelve buttons and a mouse pointer, Twiddler is ideal for users with dexterity difficulties.
BAT Chording Keyboard
BAT Chording Keyboard has only seven keys, however via multiple keystrokes, still offers same functionality as a standard keyboard.
Overlay/Concept Keyboards
Overlay/Concept Keyboards equipped with adaptable interface that is customizable for users needs. Can have large/small keys; keys can have large/small gaps between, etc. Ideal for users with learning disabilites and/or dexterity difficulties.
Universal Subtitles is an easy way to, you guessed it, add subtitles/captions to your videos. With an intuitive interface that guides you through 3 minimal steps, Universal Subtitles is incredibly easy to use. Actually it’s only downfall is that it’s JavaScript based, and there is no fallback if users are running without. Not having a non-JavaScript fallback is a major red flag for any client-side solution, don’t ever forget that. That said, its a great first step to adding Accessibility into your content, while also furthering your content’s reach and possibly getting user/community involvement.
By adding subtitles/captions to your videos, you are adding a layer of Accessibility to your content. In laymens terms, people with hearing disabilities have no clue what your video(s) are trying to get across to them. Congratulations, you have just added the equivalent to a handicapped-accessible entrance to your video’s content. Naysayers dismiss this percentage of web users, the same way they dismiss the non-JavaScript percentage: at such a small number, who cares right? Wrong. This is the World Wide Web people, that’s 6 billion+ and growing. The smallest percentages are actually quite a lot of potential users (read sales), as @slicknetpointed out on the ydn blog last year.
Adding subtitles/captions increases your content’s reach by…making your content more Accessible. These are really deep thoughts, I know; actually, they are so simple, it’s always quite baffling to me when I hear people rail against them. Look, now that you’ve added your layer of Accessibility, you’re also now providing content to people who are interested in what you are saying as well. Furthermore, you’re also providing this content in two more ways than before: text on screen, and (if you choose to), print. You just tripled your content without having to provide new content. get it? An added bonus is that one of the few areas of search that I think are still wide open for someone to gobble up, is video search. Go back and read that sentence about tripling your content again.
Lastly, Universal Subtitles has a widget (that could be more accessible) that you can use to allow users to play around with your video(s)/content. While the old guard will most “protect” their weak-ass “intellectual rights” and fight this to the bitter end, you can chose to embrace this and reap the benefits. For example, the demo I made for this post is a video about Firefox, an open source project that I hold near and dear to my heart. I have added subtitles/captions to it because I wanted to. Mozilla released the video “The Story of Firefox” to the public domain, and just like karma, it came back to them: they get free work, and all the benefits that I’ve listed above, simply by doing what is right.
Note: the demo works lovely in Firefox 4, unfortunately I used an ogv file and the uber lame Chrome is having problems with it. I’ll address this as well as the underlying widget’s JavaScript, css, html, here in another post shortly. So, I’m lame and you need to use Firefox at the moment.
Here’s a template that I use practically every time I need to implement Google Maps: it’s Unobtrusive, adds seo and Microformats to your content and provides a non-JavaScript fallback for Accessibility. Below is the markup and some explanations, you can view the Template here.
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="initial-scale=1.0, user-scalable=no" />
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<title>Google Maps JavaScript API v3 Example: Info Window Simple</title>
<link rel="profile" href="http://microformats.org/profile/hcard" />
<link href="http://code.google.com/apis/maps/documentation/javascript/examples/default.css" rel="stylesheet" type="text/css" />
<style>
html,body,div,span,img,abbr{margin:0; padding:0; border:none}
.vcard{margin:1em auto; width:500px; height:500px; overflow:hidden; text-align:center; position:relative}
.gmaps-body-content{margin:0.5em}
.geo{display:none}
</style>
<script src="http://maps.google.com/maps/api/js?sensor=false"></script>
<script>
function initialize() {
var myLatlng = new google.maps.LatLng(36.91212221138637, -76.10680103302002);
var myOptions = {
zoom: 12,
center: myLatlng,
mapTypeId: google.maps.MapTypeId.ROADMAP
}
var map = new google.maps.Map(document.getElementById("map-canvas"), myOptions);
var contentString = '<div class="gmapscontent">'+
'<h1 class="first-mapped-h">Chesapeake/Chick's Beach</h1>'+
'<div class="gmaps-body-content">'+
'<p><b>Chesapeake Beach</b>, also known as <b>Chics Beach</b> (and <b>Chick's Beach</b> by non-locals),' +
'is a stretch of beaches running about two miles from the Lynnhaven Inlet to just west of the Chesapeake Bay Bridge Tunnel' +
'in Virginia Beach, Virginia, USA. What originated as a lookout post during war, the beaches eventually turned to more ' +
'recreational activities. The area developed in the early 1900s as a beachfront residential community. Chics was a place ' +
'where you could pick up limeade and an ice cream. Eventually, this site became what is now Alexanders on the Bay. The terms ' +
'Chics and Chicks Beach have stuck. It is a diverse area consisting of beach cottages, condominiums, townhouses, duplexes, ' +
'apartments, and single-family homes. The neighborhoods of Baylake Pines and Baylake Beach hug the east side of the community, ' +
'although the popularity of the Chicks Beach area has those in Ocean Park claiming a piece of it as well. The beach community is ' +
'bordered on the south by Shore Drive. Shore Drive is one of the corridors leading to the tourist destination of the Virginia ' +
'Beach oceanfront and is currently undergoing many improvements to the biking and jogging trails. Little Creek Naval Amphibious Base ' +
'caps the west side of this community, merging longer stretches of undeveloped, protected beaches which harbor dolphin and other marine life.' +
'Also famous in this little stretch was the "Pleasure House"...where the partiers of olden days gathered for gossiping, gambling and whatever. ' +
'This is also where the longest bay-bridge connects to the Eastern shore, across the Chesapeake Bay. (The Chesapeake Bay-Bridge Tunnel)' +
'The residents of this community enjoy less public traffic due to restricted parking and a relatively unknown-about neighborhood. ' +
'The favorite activities of these neighborhoods include boating the four lakes winding through the area, jet skiing, kayaking, walking the ' +
'beach and sailing on the Bay, and the kids engage hours of skateboarding, skimboarding and creating sand-castles.</p>'+
'</div>'+
'</div>';
var infowindow = new google.maps.InfoWindow({
content: contentString
});
var marker = new google.maps.Marker({
position: myLatlng,
map: map,
title: 'Chesapeake Beach (Chicks Beach)'
});
google.maps.event.addListener(marker, 'click', function() {
infowindow.open(map,marker);
});
}
function addLoadEvent(func) {
var oldonload = window.onload;
if (typeof window.onload != 'function') {
window.onload = func;
} else {
window.onload = function() {
if (oldonload) {
oldonload();
}
func();
}
}
}
addLoadEvent(function() {
initialize();
})
</script>
</head>
<body>
<div class="vcard">
<div id="map-canvas" style="width:500px; height:500px;"></div>
<img class="photo" src="http://dev.bowdenweb.com/maps/i/google-static-map-chesapeake-beach-virginia-beach-va.png" alt="Chesapeake Beach, Virginia Beach, VA" title="Chesapeake Beach along the North Shore of Virginia Beach, VA" width="500" height="500" />
<span class="geo"><abbr class="latitude" title="36.91212221138637">N 36° 91.212221138637</abbr><abbr class="longitude" title="-76.10680103302002">E -76° 10.680103302002</abbr></span>
</div>
</body>
</html>
The link rel="profile" href="http://microformats.org/profile/hcard" references the hcard Microformat and is required (in some version) when using Microformats.
The styles defined in the headelement are primarily for the example; it’s up to the developer to decide how or if resets are being used, aside from extra styles, and it’s quite probable that they will change often, from project to project. You should notice that .vcard‘s width and height are the same as #map-canvas‘s inline styles. Matching height and width, along with overflow:hidden on the .vcard ensure that the map is equal to the size you require and that none of our added markup is even noticeable to humanoids.
The map is unobtrusive, which is crucial to keeping our behaviors separated and personally to keeping my sanity. This is extremely easy to accomplish, just tack this JavaScript into your Google Maps script:
function addLoadEvent(func) {
var oldonload = window.onload;
if (typeof window.onload != 'function') {
window.onload = func;
} else {
window.onload = function() {
if (oldonload) {
oldonload();
}
func();
}
}
}
addLoadEvent(function() {
initialize();
})
Moving along to our markup, you can see that all of our content is wrapped in the div class="vcard", which is handy in a few ways. Generally, you’re going to have a wrapper around your Google Map, unless it is the only thing on your page. I’ve found that a lot of the time, especially in float-based layouts, I am constantly setting position:relative on the map’s wrapper because the map div is absolutely positioned.
After our map, you can see two imgelements, the first of which is commented out. Let’s touch on functionality here first: Google Maps is 3rd party and ajax dependant, two separate reasons to be on the defensive with your markup. 3rd party, because you cannot always rely on what is out of your control; yes, even Google goes down, albeit not often, but they still do. ajax because you should still be worried about what happens if the user does not have JavaScript enabled. The image comes into play here: if 3rd Party and/or JavaScript is turned off, instead of showing your users nothing, they will see an image of the exact same map that you were going to show them anyways. Obviously there is no functionality here, but we shouldn’t be worried about that; this is a fail safe, not a guaranteed interactive map.
Google Maps offers Static Maps, which create maps based on url Parameters sent through standard http request and returns the map in the form of an image. As in our example:
All I’ve done is take maps parameters and added them to the Static Maps url http://maps.google.com/maps/api/staticmap?. As you can see, the latitude, longitude, zoom level, height and width are identical, just add the ampersands in between them and equal sign after each (except for latitude/longitude and the last one). You can view the image below:
These Static Maps are quite handy, however we are still relying on 3rd Party; to get around this, simply save the image, renaming it by its location name. You can see where I’ve done this in the markup, with one difference, adding a class of photo to it, so it conforms to hCard‘s parameters.
Lastly, we add our latitude and longitude to the content using the Microformat class geo. Since the vcard‘s area is equal to the content we want shown, this will never be visible to humans, but will always be visible to machines. Bonus!
