This is a script I wrote a while back and wanted to share. The idea is to make frequently ask question (faq) pages easier to browse by toggling the visibility of the answers. The solution is unobtrusive and fails quietly if the user doesn’t have javascript enabled.
Example:
- Test 1
- Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
- Test 2
- Lorem excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
- Test 3
- Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Source:
var faq = {
init: function() {
var dt = YAHOO.util.Dom.getElementsBy( function( el ) {
return ( YAHOO.util.Dom.hasClass( el.parentNode, 'fancy-faq' ) );
}, 'dt' );
for(var i = 0; dt.length > i; i++) {
new FancyFaq( dt[i] );
}
}
}
function FancyFaq( el ) {
var sibling = YAHOO.util.Dom.getNextSibling( el );
YAHOO.util.Dom.setStyle( sibling , 'display', 'none' );
YAHOO.util.Event.on( el, 'click', this.toggle );
}
FancyFaq.prototype = {
toggle: function() {
var nextSibiling = YAHOO.util.Dom.getNextSibling( this );
nextSibiling.style.display = (
nextSibiling.style.display == 'block'
) ? 'none' : 'block';
}
}
YAHOO.util.Event.on( window, 'load', faq.init );
Download here Includes fancy_faq,js, yahoo-dom-event.js, demo.html and a ReadMe file. Comments / suggestions welcome.
Posted in Javascript, LinkedIn, yui | 1 Comment »
I just finished a biggish project at work and wanted to get out some thoughts. This is one of my firsts using a new front-end template and my impressions of it are mixed at best. If there is one thing that I took away it is this. I hate css resets. And here is why.
Most people when they tell me why they like resets say things like, “Well it minimizes the browser differences for font sizes and elements like headers (h1, h2, etc) and spacing for things like list items” So lets look at those two complaints one at a time.
1. Font sizes. There is a rational out there that every browser in every platform should look exactly the same. I think this comes from the early days of the web when print designers couldn’t cope with inconsistency. I think that is a terrible goal and has help back our industry. Think about it, most people out of the internet industry don’t even have two browsers let alone use more than one. So who exactly benefits by having each the font sizes of each browser+OS combination pixel perfect? Just the designer and PM. I suggest we embrace the nuances of each browser rather than just trying to minimizes them.
2. Bad Box Model. Another reason I commonly hear is that resets are good for fixing spacing difference between box model implementations. When I hear this I usually wait and listen and a good developer will rattle of all of the problem elements that they know of generally, list items, headers, form elements, etc. At this point I wonder, if you know what elements have the potential to cause problems, isn’t that case closed? I can see where a junior developer not knowing each browsers short comings might benefit from a complete reset, but wouldn’t it be better to teach that person what they are? The concept reminds me a lot of using a javascript library without know what the library is doing. So if you know what the problem areas are, is it really worth applying a complete reset to every markup element, just for a few bad apples?
3. Bad programming. Every programmer knows that less code, more often that not, is better code. Perhaps it is because many of us came from design related paths, but it just plain doesn’t make any sense to me to tear write code to remove all formatting, then re-write it to add much of it back. The redundant processing is a waste of time and cycles.
If you are in love with css resets, have at it. There are loads of ways to built a web site, but using a reset is just a waste of time. And I’m not the only hater out there.
Posted in CSS, LinkedIn | No Comments »
I ran into a problem where I wanted one single array of all of the pages list items’s where the only thing they had in common was that the parent parent node has a class name of ”tabs”. Here is a slimed down version of what I had:
<div main="main">
<div class="tabs">
<ul>
<li>One</li>
</ul>
</div>
<div class="tabs">
<ul>
<li>Two</li>
</ul>
</div>
</div>
One solution would be to find all of class=”tabs” then build an array, for each instance of tabs. Then combine them together. That is completely viable but YUI provides a better way, getElementsBy();
var listItems = YAHOO.util.Dom.getElementsBy( function() {
return el.parentNode.parentNode.className == "tabs";
}, 'li', document.getElementById('main'));
It takes three params, 1) a function for each tested object to pass 2) an optional tag name to search for 3) a scope selector. Both 2 and 3 are optional.
Saves the day.
In my particular case, adding extra markup on the list item wasn’t possible, and YUI really saved me a ton of time. Nice work YUI.
Posted in Javascript, yui | 1 Comment »

Chris has a post on the company blog with more info. Illustration by Dennis Hengeveld.
Posted in LinkedIn | 2 Comments »
At work we have a lot of css files. 79 to be exact. The code itself is organized pretty well and I am very happy with that aspect of it. There is however one thing that I hate. That is just about any use of id’s as a css selector.
Current wisdom suggests you should use class names for elements on the page that are repeated and IDs where an element has only one instance. At first glance and on a small scale that make sense. On a large scale and after a close look problems start to arise.
Here is a sample of what I wanted to write:
.my-class p {}
But I ran into an issue because at a higher level the in that container was already specified as:
#some-class .some-other-class p
The problem is that ID’s have a high level of inheritance and cannot be overridden without the use of !important or the same or higher level of specificity The solution is simple but makes my code look terrible. So now I have:
my-class { }
.my-class a { }
#some-class .some-other-class .my-class p { }
.my-class .date { }
After I figured this out I started to wonder.. “What is the value of using and ID vs a class name?” Does it make your website faster? Better? More valid? What should I even consider? What would happen if I used class names exclusively for css, and ID’s specifically for javascript? Here are two reasons why I think you should:
1. One of the goals for an modern web developer is to completely separate the 3 main aspects of his/her code. Specifically the structure, presentation and behavior. However anyone who does this using a mix of ID an class names has unknowingly created a dependancy between their behavior and their presentation layer. That means that changing an Id or class name in the css has the potential to break javascript or vise versa.
2. If all css selectors are written with class names, no one style has inheritance over any other rule. The style sheet cascades as it was designed
Overkill? Perhaps, but food for thought.
Posted in CSS, Javascript, Markup | 1 Comment »
I went to start up school last weekend and I learns a few things:
1. How old I am? I am only 31, but I really felt like the one of the old guys in the crowd. (this doesn’t include the unix-beard types, who are really old). It was even brought up a couple of times how the average founder age that YCombinator funds is 25 years old. I suppose that they throw that around so young people with great ideas don’t get discouraged, but it just made me feel old.
2. That there are still good people doing good things. Paul Graham, who I have known of gave a great talk on the basis for starting a good company. The premise was that if you act like a non-profit, in that you genuinely try to solve peoples problems, you are well on the way to success. I like this kinda of propaganda, and against the contrast of the other VCs and talk of millions of dollars it was refreshing.
3. What a good speaker Jeff Bezos, CEO of amazon is. He was articulate, direct and polished and never once used a “marketing approved” company line. He was patient with hard questions and in two instances quick to say, “I don’t know.” The more time I spend in business, the more I realize that saying “I don’t know” gets harder and harder, the higher up the corporate ladder you are.
Looking forward to next year.
Videos of the conference here:
http://omnisio.com/startupschool08
Posted in startups | 1 Comment »