arkitrave :: log

If, like me, you’re still using some variant of an addEventListener function to add DOM events, you may run into the need to pass parameters into the function that you’re calling. (Just for the record, I use Angus Turnbull’s Add Event Manager, as it lets me use the this keyword in the functions it calls).

My event listeners are set up like this (my addEvent script is in a helper object called EventHelper):

EventHelper.AddEvent(window, 'load', foo, false);

Let’s say you’re using prototype-based JavaScript. In this case, this should refer to the “class” your function is a part of. As soon as you write any event handler call, the scope of this changes to the event itself (click, mouseover, etc) for that line of code.

Let’s say we need to pass parameters to foo in the line of code above. In addition to whatever parameters the function needs, we probably need to pass three additional items: the element the handler is attached to, the correct object scope of this and the event reference itself.

The code looks like this:

var thisReference = this;
EventHelper.AddEvent(elementReference, 'click',
pointer = function(e) {thisReference.foo(this,
thisReference, other, parameters, e); }, false);

thisReference stores the correct this scope to a variable - this is the scope of the prototype object. We’ll lose it otherwise when we write the AddEvent line. elementReference, obviously, is the element that the event handler is being attached to. e is the event, which needs to be passed into the pointer function if it’s going to be available to pass into foo(). The fun part is the pointer function. We are setting up an anonymous function which has the click event as its parameter. This pointer function is only used to call the actual function (foo) you want attached to the event. You can use it to pass whatever parameters you want to foo; just make sure you pass this, thisReference and e if you need the element, the prototype object and the event in the function you’re calling.

The pointer function gets the actual, original event (e). When the event happens and pointer is executed, it calls foo, passing it your parameters.

Enjoy.

Tags:JavaScript, DOM

It’s over. I take off at 6:51 tomorrow morning. This has been a great experience, and I will definitely be back next year.

I was pretty laid back about my approach to the panels today; I didn’t take a lot of notes, and mentally I wasn’t all there after a very late night and four solid days of SXSW…

The Next Generation of Web Apps

The central word of this panel was “iteration.” Mena Trott of SixApart was the most vocal presenter, and in between such statements as “It doesn’t get much smaller than a husband and wife in a bedroom” she actually had a few good things to say. Modern application development needs to iterate more quickly; some apps push a new version every day to every couple weeks. Certainly shorter than the 18-month development cycle of desktop apps.

The panelist from flickr encouraged us to talk to users rather than trying to think like them. They get tons of feedback and they make small, incremental revisions to the product based on that feedback.

Simple apps are also the future - nobody needs all the features of MS Word, and they mostly just get in the way of productivity. This affirmed previous day’s comments by Coudal and Freid. Veen put it this way: boil down something that everyone thinks is already done (like MS Word) - these things are done in an overly complex way. Make them simple. They just did this with Measure Map, and Google just bought it.

There was brief commentary around the idea that user-generated content means that design is becoming “just” a container. One point of view is that this is very exciting; some feel that design being divorced from content in this way is a negative.

Check out chicagocrime.org.

Two additional tidbits to close: Don’t use Greek text for comping, as it divorces the design further from potential content. Use actual content or invented content, but not completely foreign Greeking. Also, be competitive on product quality, not on the lock-in of the user. The user will leave if you suck. They will stay if you’re good. And trying to hold their data hostage or keep them on your site is petty and in the end will bite you.

The Orthley Children and their Computer

Spend a little time at Why’s (Poignant) Guide to Ruby. That’s really all there is to say. The man is pretty much an insane genius, there was a band with a banjo and theremin, and a little bit of Ruby code thrown in for good measure. Some people walked out, not getting the humor, but then they’re probably the same people that don’t get Monty Python.

The State of the World

Bruce Sterling. The state of the world.

Conclusions

This has been a fantastic experience. It’s been amazing to put faces to blogs, and to meet and talk with people who I respect a great deal. Most of the panels were quite good, a few were amazing, and the Microformats talk made me really excited about the web again.

However, I miss my beautiful wife and baby, and I’m looking forward to getting back home. I’m a bit more motivated to clean up my act around this site, finally launch a slightly more up-to-date design, and write a bit more often. And I’m looking forward to getting back to work to continue to improve the Fisher-Price website.

A few brief notes from a few of the panels on Day One:

Beyond Folksonomies: Knitting Tag Clouds for Grandma

Overall, an interesting panel. Admittedly a huge topic, there weren’t many answers provided; rather, it was the kind of experience that provokes more questions and uncertainty. The certain fact is that the rest of the world does not use or see tagging the way that web-people do. The presenters contrasted top-down taxonomy with bottom-up folksonomy, though positing that the two were not polar opposites but rather complementary and mutually necessary. Tagging allows people to invent their own classifications. Right now, it’s still in its infancy. Problems include usability (a lot of classifications are just bad), not enough critical mass, inadequate interfaces, too much information without the foundations being solid, and both differences in the way different people classify information and the way the same person classifies things over time.

People don’t want to do lots of work; the average person isn’t going to tag things just for the good of the community. It needs to be made really easy, and the ROI of tagging things needs to be obvious to people.

Implicit tagging has potential (a tool which, for example, looks at what you click on in a Google search associated with the keywords you used to search…this is automatic, but still human-generated).

Tagging needs to be integrated with things people actually use, instead of another site that people have to visit. It needs to move from the power-user realm to the everyman realm.

We need to look at problems and solve them, not invent technologies and then try to find a user for them.

Ajax: What You Need to Know (pdf)

Introduction (Schiemann): XMLHttpRequest is really a misnomer - it doesn’t have to be XML, it can be any text or HTML content. Microsoft just liked the name years ago when they invented it. Questions to ask: What is our intention? What does “back” mean? Page? State? You don’t want to go back to outdated data. Cross-domain security could be an issue. Progress indicators aren’t supported. Code can execute more quickly than the content it requires to execute without errors. Request limits (2 maximum open at a time per HTTP spec). Debugging is difficult with Ajax.

Getting Started: 1) Determine your requirements - what do you want to do? 2) Find a good toolkit - don’t reinvent the wheel. Use Dojo, MochiKit, Prototype, etc. This frees you to make new mistakes, not repeat old ones. 3) Learn more about JavaScript and HTTP.

Common Objections (Smith): 1) Accessibility and usability (you must make sure you give content to all users!). Plan degradability from the beginning, not as an afterthought. 2) User expectation (what about back button? bookmarking? map permalinks? 3) Cross-browser support - no excuse for ditching any (new) browser or Mac support. 4) Suits and marketing droids show up and try to “help” and sell stuff based on Ajax without learning anything about it. Geeks from the server side of things, who don’t believe JavaScript is a “real” language, show up and try to “help” the poor scripters since they are the “real” programmers. 5) Navigation issues, slow response times (LiveSearch appears to be slow, Spotlight on Mac OS X Tiger appears to be slow). 6) SEO friendliness (do we hide content from search engines by using Ajax?). She encourages us to check out what Yahoo! has been up to; this is good stuff.

In working with backend developers, remember two things: First, it’s JUST HTTP! It’s not really that different than what we are used to. Second, the client can manage it’s own UI - the backend doesn’t need to know that a button has been clicked; it just needs to know that it needs to deliver a piece of content to the client. Actually, in some ways Ajax decouples the model and view more than a traditional web page paradigm.

In designing workflow, know your people and what they want. Is it boxes and arrows? Storyboards? It’s tougher than a page paradigm, because you have to show how the thing works. Perhaps building it is the best way (cross-reference Coudal/Freid’s opening remarks).

Keynote: Jim Coudal and Jason Freid

Coudal

A couple years ago, panels were about tools. Now, they’re about taking the tools and building businesses with them.

When people think of “in-house”, they think of bad email campaigns, Comic Sans, sales videos, cube farms and lots of toys scattered all over the office…maybe signs that say “Creatives on the loose!”

People historically thought that good design happened independently of the client. Now, designers and coders are realizing that they can handle the business side of things, thanks to good technology. Curiosity and quick learning are the hallmarks of the new small businesses.

Good craft (markup, color theory, etc) they learned on behalf of clients when we worked “in-house.” Now, they are trying to control the creative product outside of the work-for-hire model. It’s better to BE the client than work for the client. Apply craft to their own business. Of course, it’s not that easy…

Issues come up - international shipping, tax law, redundant servers…client used to do these things for us. We need to be quick learners. Questions they always ask before accepting any project:

1. Will we have a product we are proud of?
2. Will we make money?
3. Will we learn something valuable through doing the project?

They’ll do a less-than-perfect product for lots of money. They won’t do mediocre work for mediocre pay. They will never take a project they won’t learn something from.

We need to learn how to learn quickly. The meek don’t inherit the earth, the curious inherit the earth.

Freid

So, how do we do this? We need entrepreneurship, not just tools. Starting is intimidating…what to do first? Don’t quit the day job. The old plan of VC, an office, a business plan, is expensive and puts investors before customers.

Make it a side job. Basecamp started as a side project of 10 hours a week. Benefits to this method:

• Obscurity - you will fail more than you succeed, so fail in obscurity.
• Less - this a huge competitive advantage. The age of “more” is very cold war/defensive
  • Less time - can’t waste time if you don’t have much
  • Less money - don’t need a lot of stuff - keep it simple
  • Less software - build simple stuff that people can use

Don’t try to be clever, like MS Word trying to predict what you want. Basically, more constraints are good rather than a hindrance, because they force you to do more with less and you won’t be indebted to any venture capitalists.

Q&A talked about how bad spec documents are - basically, they make final decisions based on information you won’t have until you build the thing. Just start creating rather than trying to build detailed spec documents. They reject any job with an RFP of more than two pages. Spec documents are political illusions of agreement - there are so many levels to how they can be interpreted that there is no guarantee anyone is actually really on the same page.

Also, don’t bullet point job skill requirements when hiring - the important thing is that someone is curious, not that they have x years with Photoshop or a college degree. Several of 37Signals employees don’t have college degrees. These easily quantifiable things are not indicators of how effective an employee will be. As long as they can do the work and are curious, they will be good employees.

Finally, charge for what you make! You will make money, then, and people are willing to pay for something that gives them value. Produce a good product, and people will pay for it.

Online in Offline Spaces

Basically this panel was run by people who build social apps that bring people together in real space - rather than the virtual utopia predicted in the late 90’s, people want to communicate with each other personally, and technology should serve that end. Dodgeball, Socialight, Meetup, and Squidoo were the apps represented by members of the panel.

Steeson talked about buildings that have interfaces. Peter Cook’s paper architecture, the plug-in city. The Pompadou Centre in Paris with the services externalized. Realities Unlimited in Berlin. The Pong game on the building facade, controlled by cell phones.

With my background in architecture, this was interesting, and I appreciated the emphasis on the real physical interaction that is coming to the fore in digital gathering. A dystopian element was presented as well - will we eventually be willing to pay to keep people from finding out where we are and what we are doing, or pay to not know background information on a place or building so that we can enjoy discovering it ourselves?

Later…

After the panels, I met back up with Erik and David, and went to the barcamp meeting at Thistle. I got my picture taken and even a free t-shirt! I bought a tasty Patron margarita, and Zach Inglis bought me a glass of wine. Zach’s a great guy (and not just because he bought me a drink); I enjoyed talking with him and found myself slipping into a really bad Scottish accent occasionally. I also spent some time talking with Patrick Haney, who works at Harvard but grew up in Hamburg and went to RIT. Carl Tashian, who I met briefly at the bar, is an interesting guy who works as a developer at Zipcar and, like me, has a thing for well-designed stuff like the Dyson.

We were invited to another party, but I am too old to stay up all night and get up at 7:30. More tomorrow night.

I’m in Austin for South by Southwest 2006. This is my first year at SXSW, and already I know it won’t be my last. I’m splitting a room with Erik Sagen from Rochester. I’m trying to decide which panels to attend, and I will post thoughts and a few photos from my cell phone throughout the next few days. I’m looking forward to all the great presentations and meeting some of the best people in the world.

The first significant move toward adoption of web standards at Fisher-Price has finally gone live. The main site template consists of a left nav and a legal footer, with a fixed-width content area. The left nav has been a Flash movie for IE users and a load of document.write statements without flyouts for all other browsers.

Along with a crackerjack developer, I recoded the entire site template to (mostly) standards-compliant code. The left nav now uses CSS for flyout menus (with a little JavaScript for IE) and degrades gracefully if images and/or JavaScript are unavailable or turned off. It works as well in Lynx as it works in Firefox. The JavaScript is external and unobtrusive.

The soft launch page with this new template is Toys by Type. If all goes well, this template will be deployed for all new .NET pages in the main Fisher-Price site.

Any feedback is welcome. Here are the things I know are not fully standards-compliant along with a brief rationale:

• If applicable, I’m using a custom track attribute to handle tracking from the left nav. I don’t think this template is using this at all, so it shouldn’t throw any errors.
• There is a tracking control which writes non-compliant code (script language="javascript", unencoded ampersands, an image inside a noscript tag, etc). I’d like to see this control’s HTML modified, but for now, I have no control over it.
• XSLT is being used to write the left nav items from XML, and though it may be possible, we could not figure out how to close self-closing tags XHTML-style with the XSLT factory. Therefore, a couple input and img tags do not have the closing slash required by XHTML.
• There are a couple left nav links which remained as a xhref="javascript:openWin... statements. This is because the applications which they are opening are JavaScript only. I’d rather have a link fail than have a user open a window they can’t use.
• Yes, all this could mean I should have used HTML 4 transitional. However, I made a judgment call that it was worth using a standards-compliant doctype. First, this encourages us to write good code, and second, it is a break with the past and a move forward that psychologically is healthy for us as front-end coders and developers.

The actual download size is more than a 50% reduction. Not to mention that with all the links being inside document.write statements, Google wasn’t seeing any links on the page. Now the entire navigation in search-engine spider-able.

I’m pretty proud of how far we’ve come in a few months. Check out Toys by Type for yourself.

A very common scenario: a CSS background containing an image of text, with an HTML file containing the same text in some sort of standard HTML tag. The HTML is hidden, the background image shows pretty text. This happens every day in post-csszengarden.com-land.

From a philosophical, separation-of-content-presentation-behavior viewpoint, is the CSS background image a piece of content inside a style sheet, which should be presentation only?

I need as many reasons as I can get why the background image is not content lurking in a presentation file. Can anyone help me out? (alternate viewpoints welcome too, if you think background images are indeed content…)

Discuss.

This is a markup question. I’m working on a navigation system in which many of the links are tracked and a friendly name (used for a report given to the client) written to a database when they are followed. The past method of doing this was to write an onclick handler on each link, like so:

<a xhref="link.html" mce_href="link.html" onclick="trackFunction(parameter, parameter, parameter);">

What I thought of doing first was writing a class, assigning it a value, and using that class in an external JavaScript to call the function:

<a xhref="link.html" mce_href="link.html" class="tracking_name">

The problem with this is twofold: First, I’m using a class for something that isn’t really a class. It’s a specific name for a specific link, for the purpose of preparing a tracking report. Second, I have to do some cleaning of the value, because a class can’t have spaces or other characters. Since this is a friendly name, class is rather restrictive, and I’d have to write replace functions to clean up all the values. This is a long-term nightmare, and I’m not going to do it.

Third option: use a custom HTML attribute. All I have to do then is write:

<a xhref="link.html" mce_href="link.html" track="Friendly Tracking Name">

JavaScript will let me at this custom attribute, by using element.track element.getAttribute(’track’), so an external script can easily call the function to write to the tracking database.

The only problem is that it is invalid HTML. We’re not going to go to the extreme of writing a custom DTD for this; we’d just use it and let it be invalid. My developer colleague argues that onclick is valid, and therefore would be better to use, and really, what’s the problem of a little behavior mixed into the HTML?

I’m having a hard time coming up with definitive reasons why the custom attribute is better; it just seems better to me. It’s more semantic, it at least uses markup, even if invalid, and it is cleaner and clearer to write from a front-end point of view.

A couple points in the recent IE Blog IE7 update have gotten me thinking about the tension and interplay between browser makers and web designers. Basically, I believe that browsers for too long have abdicated their responsibility to produce really comprehensive software, giving the entire responsibility for a good user experience to the web designer. There are fundamental flaws in this way of thinking. Let’s start with a bit of history.

HTML essential in the beginning
In the beginning, the browser makers provided all of the “style,” which largely consisted of making (for example) <h1> text large, bold, and Times New Roman. This kind of feature set was necessary for users to make any sense of the HTML markup of the page. Without this “browser style sheet,” web pages would just be endless plain text. This is the brilliance of markup, and it worked for scientific papers and the first company sites. It was necessary to have a reliance on proper markup as a designer, otherwise nobody could make heads or tails of your site.

HTML abandoned
However, it was short-lived. The browsers’ abilities in presentation were sorely lacking in design panache, with bland gray backgrounds, black text, and Berners-Lee/Nielsen link colors. Once the <font> tag was invented and designers figured out how to use shim .gifs and tables for layout, HTML as a markup language went the way of the dodo. Designers soon abandoned HTML altogether, using it as a way to organize and present a page rather than mark up content. The browsers were all too happy to agree, extending HTML until it was virtually meaningless, full of proprietary features that moved HTML away from more than a passing resemblance to a structural language.

HTML returns
After CSS has been around for, what, close to 8 years, we’re seeing a widespread return to the original spirit of HTML. Many designers are beginning to re-grasp what they forgot from 1995, which is that content needs to be marked up properly and then styled. We’re seeing a separation of content, style, and presentation that is great news for the web. We’re at the edge of some really exciting possibilities, and I’d hate for things to get messed up now.

Enter the browser makers
This is a critical point in the interaction between browsers and designers. Let me explain what I mean. One of the things Microsoft is implementing in IE7 is a shrink-to-page feature. This is an example of a browser acting like a piece of software, which is exactly what it should be doing. You could say that this takes control away from the designer, and in a way it does. But, it’s control that we should be willing to relinquish.

Let me use another, probably better example. We’re solving a data problem at work by using an XML file to store data for many similar products, because this particular site doesn’t live on our normal server environment with access to the company-wide content management system. The file consists of images and captions for each product, which for now are displayed on a thumbnail page. To get the captions’ lines to break properly on the sample page I gave her, the developer added <br> tags inside some of the captions.

Of course, this works on the sample page. However, one of the purposes of using the XML file is reuse of the data. I’m probably going to have an order form, and definitely a larger image popup with a caption. So, the <br> tag only works on the thumbnail page. It took quite a bit of convincing to talk her into removing the tags, and the client might still insist on them later.

The problem is that the client isn’t going to like an orphan word on a separate line on the thumbnail page, which could happen without the <br>. But I have no choice. I either formulate my XML for one specific page and font size, which makes it fail when 1) a user resizes text or 2) when the XML is used in another context, or I risk the occasional line break in the wrong place.

What is the solution to this specific problem? A browser which is bright enough to see the orphan, and correct it, wrapping the line one word early. Word processors have done this for years. Why is there no browser that can intelligently end a paragraph?

This is just one example of something a browser could do which in some ways takes control away from the designer, but serves the greater good of clean, structural markup. It isn’t something that we’d want as a part of CSS (I don’t think), because it’s just a standard, accepted way of presenting information. If you’re writing poetry, and the breaks are important, that’s where structural markup like <br> tags come in.

I’d love to hear other examples like this. How else can browsers take that extra step of presenting information in ways that keep us from having to use hacks and additional markup? How can the browser be a partner, rather than the extremes of 1) taking all control away or 2) leaving all control to the designer?

When building pages that utilize JavaScript which will be implemented into a .NET framework, be sure to tell the developer (or if you’re like me, do it yourself) to use <%asp:literal%> tags rather than <%asp:label%> tags for database-driven content. .NET will automatically add <span> tags to anything inside a label, whereas a literal will be implemented as pure data from whatever data source you are using. The problem is that developers are trained to use the label, rather than the literal, so they won’t do this on their own.

The literal preserves the integrity of your HTML, the label does not. If you’re writing a script that, say, swaps out an image caption in a paragraph, dynamically writing that paragraph’s firstChild node value, you will run into problems if an additional span tag, inserted by .NET, appears inside that paragraph. The script will, of course, find the span tag and identify it, rather than the text node you were going for, as the firstChild.

Don’t let .NET write your code. If you’re a front-end web designer, learn enough about the framework your designs will be implemented in to know how to keep them from being messed up by the backend. I’ve learned my lesson, and was able to help a developer better understand the impact of his code choices on the front end. Now I’ll (hopefully) get asp:literals every time.

By popular demand, I finally sat down to do what I should have done months ago: figure out what was causing the problem in my article on A List Apart (which, by the way, has a fantastic new design).

There was a 40 pixel jog in Internet Explorer in the original example, which I attributed at the time, without really looking too closely, to an IE positioning bug. So, I submitted the article and gave everyone who asked the party line of “I have no idea what’s wrong, it’s probably an IE bug.”

Well, after months and several emails about the subject, I took another look. Turns out, the real problem is browser style sheets.

A primer for those who may not be aware: all browsers have a default, built-in style sheet. It’s what causes <h1> tags to be rendered large and bold, and what puts spacing in between paragraphs. If browsers didn’t have a built-in style sheet, non-styled pages would simply be line after line of 12-point Times New Roman on white. Oh wait; even that is a default style.

Browser style sheets are a reality, and a pretty nice one at that. Unfortunately, as much as they aid in clarity when viewing non-styled pages (pages without CSS attached that are simply marked up with HTML tags), they can be a real pain when trying to figure out what’s causing positioning errors.

Turns out, Internet Explorer (and, big surprise, Opera) have a default <ul> style that is different than Gecko browsers like Firefox, and the problem really was that simple. All I had to do was set a zero-pixel margin and padding on the <ul> element, and problem solved.

Typically when I build a site, I begin with a declaration like the following:


* {
margin: 0;
padding: 0;
border: 0;
}


This cancels all browser margins and padding and ensures that I have complete control over everything (well, as much control as we ever have using CSS). I didn’t do this with my ALA example, and that’s where the problem came in.

So, check out the fixed example. This should help anyone trying to implement this menu system, and my apologies for procrastinating the fix for this problem. As it turned out, the entire fix took about 20 minutes.