All Posts in The Programming Mechanism

January 25, 2008 - Comments Off on NY Web Standards Meetup—Web Mapping Part One: Google Maps

NY Web Standards Meetup—Web Mapping Part One: Google Maps

Below are links to materials from last night's presentation on the Google Maps API to the New York Web Standards Meetup Group. Thanks to everyone who made it—there were a lot of great questions and input.

Listen to the podcast of the event

[audio:BarKode-Episode1-WebMappingPartOne.mp3]

Subscribe to the podcast of the event

Feedburner podcast link

Rashmi, here's the link I promised: Sasha Maps—A Google Web Toolkit-based library that provides functionality similar to the Google Maps API. I've never used it, because I don't know Java.

Next month will be less of a presentation and more of a roundtable as we continue our web mapping discussion. While the focus will remain on Google Maps, we'll also talk about alternatives, both commercial and open source. Other topics include: best practices, our favorite mashups, and what makes the good ones so good.

Please send the URLs of your favorite mashups, any development questions, and any tutorial requests to Jeffrey prior to part two. Thanks!

Please contact us if you'd like to present at the March or April meetup.

Web Mapping Part Two

Published by: jeffreybarke in The Programming Mechanism

January 23, 2008 - Comments Off on First HTML 5 working draft is now available for comment

First HTML 5 working draft is now available for comment

The first working draft of HTML 5 has been published here and the guide "Differences Between HTML 5 and HTML 4" has been published here.

Comments on the draft should be sent to public-html-comments@w3.org. The Working Group is particularly looking for feedback with regard to the accessibility features. The comments archive is located at http://lists.w3.org/Archives/Public/public-html-comments/.

Published by: jeffreybarke in The Programming Mechanism

January 17, 2008 - 6 comments

Easy charts with Google Chart API and Chartpart

If you're looking for a fast, easy way to generate parameters for the Google Chart API, check out Chartpart: Google Chart API and Chart Generator Tool. It features a form-based interface for setting the chart parameters, a preview of the output chart, and the code necessary to implement the chart on one's own site or blog (background on Chartpart here).

I entered:
stacked bar
320x200
Crime Summary 07
jul,aug,sep,oct,nov,dec
violent crimes,#3e606f, 10, 30, 9, 12, 15, 22
property crimes,#91aa9d, 64, 120, 130,170,175

and received the following preview and output:

Fake crime summary 2007 graph
http://chart.apis.google.com/chart?chs=320x200&cht=bvs&chtt=Crime Summary 07&chd=s:DKDEFI,Wqt79&chco=3e606f,91aa9d&chdl=violent crimes|property crimes&chxl=0:|jul|aug|sep|oct|nov|dec|&chxt=x

While I think this service is very easy two use and I'm grateful Leancode produced it, I do have two small complaints:

  1. The title field in the form limits one to 16 characters. This is not a limitation of the API, so I'm not sure why Leancode is limiting us here.
  2. I wish the ampersands (&) were escaped (&) in the output chart link. This would make it simpler to cut and paste valid code.

Published by: jeffreybarke in The Programming Mechanism

January 12, 2008 - Comments Off on 456 Berea Street: Two on Accessibility

456 Berea Street: Two on Accessibility

Post-holidays, I'm finally getting a chance to catch up with my favorite blogs. Over the next couple of days, I plan to summarize and include links to some of my favorite posts.

Roger Johansson, of 456 Berea St., wrote two interesting posts about accessibility in December of 2007. The first is primarily an exhortation to practice accessibility, while the second examines some bad practices that masquerade as accessible.

On 14 December, in "Accessibility is part of your job, Johansson included this quote (which he agrees with and so do we!) from James Edwards's "Why Accessibility? Because It's Our Job!:"

If we call ourselves professionals, we owe it to our clients, their clients, and ourselves, to do our job properly. A chef must care about health, a builder must care about safety, and we must care about accessibility.

Caring about accessibility, however, means more than mindlessly applying a few HTML attributes to a web page. In "Overdoing accessibility" (17 December), Johansson writes about the mis- and overuse of the accesskey, tabindex, title, and alt attributes. In one egregious example, he mentions a webpage containing 185 spacer GIFs with an alt attribute of "Typographical space"!

Published by: jeffreybarke in The Programming Mechanism, The Thinking Mechanism

January 8, 2008 - 115 comments

Safari CSS hack redux

In March 2007, I wrote about a Safari CSS hack called the "Pound Safari Post Semicolon" hack (coined by Tony at Simian Design). As of Safari 3.0, this hack no longer works. However, there is a way to target Safari 3.0:

@media screen and (-webkit-min-device-pixel-ratio:0) {
/* Safari 3.0 and Chrome rules here */
}

As always, the disclaimer: nobody condones the use of hacks, but we all (well, most of us) have to make use of them at least once in a while. The above code targets both Safari 3.0 and Google's Chrome. Hopefully, it will be a future-proof hack, since the -webkit part of the selector will probably not be adopted by other browsers.

Example: The following code set the background color of the <body> element red in all browsers and then resets it to blue in Safari 3.0 and Chrome.
body { background-color: red; }
@media screen and (-webkit-min-device-pixel-ratio:0) {
    body { background-color: blue; }
}

[demo]

Tested on Mac OS X version 10.5.1 with Safari version 3.0.4 (5523.10.6) and Mozilla Firefox version 2.0.0.11. Tested on Windows XP Professional Version 2002 SP 2 with Mozilla Firefox version 2.0.0.11, Opera 9.10, and Microsoft Internet Explorer 6. Hack from CSS, JavaScript and XHTML Explained.

Update 2008-11-26: Since this hack targets Webkit-based browsers, Chrome is also affected. At the original time of writing, it also affected Opera (9.10); it hasn't since 9.50. The post copy has been updated to reflect these developments.

Published by: jeffreybarke in The Programming Mechanism
Tags:

December 20, 2007 - 6 comments

24 ways… Transparent PNGs in Internet Explorer 6

For the past three years, 24 ways has been the Advent calendar of choice for web developers. This year started off with an excellent article and script by Drew McLellan dealing with PNGs in IE5.5 and 6.

If you work with PNGs or plan to, this is a very concise and informative article. It quickly describes how PNG transparency works, outlines the problem with IE 6 and below, provides a solution, and details the limitations of this solution. I really can't recommend it enough.

SuperSleight

As if this information wasn't enough, Drew then introduces SuperSleight, a JavaScript that automates support for PNG transparency in IE5.5 and 6. Based on sleight by Aaron Boodman and bgsleight by Drew McLellan, "SuperSleight adds a number of new and useful features that have come from the day-to-day needs of working with PNGs:"

  • Works with both inline and background images, replacing the need for both sleight and bgsleight.
  • Will automatically apply position: relative to links and form fields if they don't already have position set. (Can be disabled.)
  • Can be run on the entire document or just a selected part where you know the PNGs are. This is better for performance.
  • Detects background images set to no-repeat and sets the scaleMode to crop rather than scale.
  • Can be re-applied by any other JavaScript in the page—useful if new content has been loaded by an Ajax request.

Since we use PNGs quite a bit at theMechanism, SuperSleight was of great interest to us, particularly in the London office. When I looked at the code, however, there was one thing I didn't like—to change two of SuperSleight's properties required changing values hard-coded in the object. To change the third required a separate call to the limitTo method.

Enter theMechanism

To make SuperSleight easier to implement for my colleagues in London, I added three parameters to the init and run methods of the supersleight object. Our version of SuperSleight (which I'm calling 1.1.0) is available here and partial instructions on how to use it are below. The primary documentation on SuperSleight is still Drew's 24 Ways article. You can see SuperSleight 1.1.0 in action here.

How to Use

  1. Download SuperSleight and unzip. Upload supersleight.js and x.gif to your webserver.
  2. Add the following code to the <head> element of any page that contains PNGs:

<!--[if lte IE 6]>
<script type="text/javascript" src="path/to/supersleight.js"></script>
<![endif]-->

That's it! By default, SuperSleight will run on page load, look for a transparent GIF named x in the same directory as supersleight.js, apply relative positioning to anchor and input elements, and process every PNG on the page. To change any of these default behaviors, open supersleight.js and edit or remove line 17:

supersleight.init();

The init method of the supersleight object takes three optional parameters:

  1. String path to the transparent gif file. Note this path is relative to the actual document, not the JavaScript document.
  2. Boolean value to apply relative positioning to anchor and input elements. Pass false to leave the elements as they are.
  3. String ID of an element to limit SuperSleight's operations to.

To see these parameters in operation, plese view our SuperSleight demo in IE 6 or less.

To call SuperSleight from a script, use the run method of the supersleight object. This method takes the same three optional parameters as the init method.

Download SuperSleight 1.1.0
View SuperSleight Demo

Published by: jeffreybarke in The Programming Mechanism
Tags: , ,

August 29, 2007 - Comments Off on Firefox extensions to avoid

Firefox extensions to avoid

While searching for something completely different, I ran into an interesting article on Firefox extensions to avoid. The article was published by Computerworld on 10 April 2007 and discusses ten add-ons that are “bad” because they waste network resources or don’t provide enough benefits to be worth running. The extensions to avoid:

  • Fasterfox
  • NoScript
  • Adblock and Adblock Plus
  • PDF Download
  • VideoDownloader
  • Greasemonkey
  • ScribeFire (formerly Performancing)
  • TrackMeNot
  • Tabbrowser Preferences
  • Tabbrowser Extensions

To learn why you should avoid these extensions, you’ll have to read it.

This article complements one published 7 March 2007 on 20 must-have Firefox extensions. It’s interesting to note that in March Greasemonkey was a must have, but by April it became one to avoid. And web developers who don’t know about these add-ons will definitely find them worth checking out.

Published by: jeffreybarke in The Programming Mechanism
Tags:

August 26, 2007 - 4 comments

Go Mobile!—The .mobi basics

Recently, theMechanism has become more interested than ever in mobile web development. Dave and I were talking a bit about the possibilities after work the other day, and we got so excited we snapped up our first .mobi domain. Now that we had it, though, what to do with it?

While I’ve made a site “mobile friendly in two minutes,” heard of the .mobi domain, read a little about Flash Lite, and worked with semacode, I haven’t engaged in any serious, professional mobile development. So, as senior developer for theMechanism, it was incumbent upon me to do some research. Dave asked me to share my findings on the blog. So, over the next few weeks, I’ll be writing about mobile development here while working on themechanism.mobi (note—themechanism.mobi must be accessed by a mobile device or else you’ll simply be routed to themechanism.com).

Why mobile development?

Well, there are facts such as “internet-enabled mobile phones outnumber PCs four to one” [1]. Then there’s the dream/nightmare of ubiquitous computing—using semacode we can “build applications that combine aspects of the virtual world into the real world” [2]. Finally, it's (relatively) new (and therefore exciting) and, given the release of the iPhone, sexier than ever.

.mobi Domains

While a mobile site can be located anywhere (a domain, subdomain, or subdirectory) “.mobi is the first—and only—top level domain dedicated to users who access the Internet through their mobile phones. General registration of .mobi names began on 26 September and is now open to everyone.” [3]

mTLD Top Level Domain, Ltd. was appointed by ICANN as the official global registry for the .mobi top level domain [4]. To achieve their goal of a domain dedicated to mobile users, mTLD (known informally as dotMobi) has established three mandatory rules that registrants must agree to comply with when they register a .mobi name. mTLD tests all .mobi domains for conformance to the three mandatory rules once per quarter per domain, though this frequency may be increased for sites that have not been compliant in the past. Non-conformant domains will be suspended [5].

Mandatory rules for a .mobi domain:

  1. You are required to use XHTML Mobile Profile 1.0 markup language for the home page of your site if your web application does not have the means to distinguish between devices, or, if your web application is able to distinguish between devices but does not recognize the current device.
  2. The site must work with or without the “www” in the domain name
  3. Frames are not allowed.

That’s it for now. Next time, I’ll talk about some tools to make mobile web development easier.

References

Published by: jeffreybarke in The Programming Mechanism

July 23, 2007 - Comments Off on The Wonder of Ajax and Forms!

The Wonder of Ajax and Forms!

The New York Web Standards Meetup Group will be meeting at theMechanism on 26 July 2007 at 6:30 pm to discuss Ajax and forms.

Did you miss Ajax and Forms a few months ago? Here is an opportunity to catch up and see what we've been cooking up. Jeffrey Barke will review cool features, scripts and general visual goodness at theMechanism's office.

After the talk, we will open the floor to a monthly design critique. We encourage attendees to bring current or past projects they feel comfortable showing to get collective input from the group, as well as discuss topics and desired presenters for future Web Standards meetings.

There is no fee—and beverages as usual—will be provided. RSVP now!

26 July 2007 . 6:30 pm
theMechanism|eEmerge
440 9th Avenue 8th Floor
New York, NY 10001 [map]

Please contact us if you’d like to present at the August or September meetup.

Published by: jeffreybarke in The Programming Mechanism
Tags: