Jared McAteer’s Blag - jaredmcateer.com

Looking for a solution to Visual Studio 2008’s Intellisense’s poor performance while editing large HTML documents I came across an awesome discovery. You can extend the intellisense to include jQuery (well any framework provided you have it properly documented.) This is awesome because even though I love the new Ajax Control Toolkit in VS.NET 2008 it just doesn’t hold a candle to jQuery and it’s plethora of plugins.

To gain this functionality, first grab the intellisense stub from InfoBasis’ jQuery Intellisense Header Generator, or as I lovingly call it, Ijihg. [Direct Link]

Add it to your project and then the really easy part, drag the file into the javascript file(s) you wish to enable jQuery intellisense on, or you can type in the reference manually

You should get something looking like:

And that’s all there is too it. Once you begin coding intellisense will pick up jQuery and make your life a little bit easier. Here’s a couple screens to give you an idea of what you can expect:

Technorati Tags: Visual Studio 2008, jQuery, intellisense

Popularity: 21% [?]

Now that all major browsers support the Acid2, or at least have announced they have development builds that pass it, Ian “Hixie” Hickson has begun work on the Acid3. The exciting news is that it is going to focus on ECMAScript (aka. Javascript) and the DOM. The first two Acid tests focused mostly on error handling and emerging technologies of CSS. A lot of people tend to assume that if you pass the Acid tests your browser is standards compliant but they fail to realise that CSS is only a portion of Web Standards. They are important, don’t get me wrong, but most browsers are progressing along with support these days and I’m excited the focus is being shifted to an area that is somewhat neglected.

I do a lot of development in ECMAScript and work heavily in the DOM so it’s no end of frustration to support all browser’s quirks. Having the next Acid test focus on this makes me giddy, this will hopefully force Microsoft to support DOM levels 2 and 3, as of right now they only support DOM level 1 and poorly. I’m sure the guys that develop libraries like Prototype.js and jQuery will be equally as excited.

Technorati Tags: Web Standards, Javscript, ECMAScript, Acid Test, Acid 3, Browsers, Firefox, Internet Explorer, Opera, Safari, DOM

Popularity: 80% [?]

I ran into a problem of placing an element I created via javascript, it was a calender for a date picker. I wanted the calender to appear directly under the textbox that would accept the selection from the user. This is a deceptively tricky thing to do on websites. This is because it doesn’t store the Top and Left of the element relative to the Top/Left of the current window, rather it stores the Top and Left relative to it’s offsetParent. What’s an offsetParent? It’s the property of an element whose parent affects it’s positioning, this can be it’s actual parent but it can also be a parent further up the tree depending on if it affects its offsetLeft and offsetTop peroperties. If an element is positioned fixed its offsetParent will be null, so you won’t always have to traverse to the top of the DOM tree to get the actual offset of your element relative to the window.

(more…)

Popularity: 87% [?]

I while ago I posted my code to find out if an element is hidden (with added complexity that if it’s parent is hidden it will also be hidden despite the fact that it’s own display style may not be set.) Originally I came up with the following code:

Right away I knew it was a less than perfect example of finding what I needed, I prefer to avoid recursion as much as possible. Eventually I came to the realization that I was overthinking the problem and I came up with a much more elegant solution to the problem. And here it is:

This I can live with much easier.

Technorati Tags: javascript, dom, style, display, element

Popularity: 50% [?]

I ran into a problem building a webapp today, I needed a way to determine if a specific element is hidden. Most of the time you can just check it’s style display:

… but what happens when it’s parent (or parents parent, or parents parents parent, ad nauseum ad infinitum) is hidden? There is no way (I could tell anyways) to tell if an element is hidden as a result of a parent node somewhere being hidden. Someone had suggested that .offsetParent was set to null in Firefox if the element was hidden, it worked, initially. I found out however this doesn’t work in Internet Explorer and even in Firefox elements such as Select never have an offsetParent. So back to the drawing board, and what I came up with was what I originally had thought would be the solution I’d have to use. The reason I didn’t initially develop it was because it uses recursion, I don’t like recursion, it’s inefficient and looks sloppy but without a better solution I came up with the following:

And there it is in all it’s simplistic glory, if anyone reading has a better solution, I would like to hear it.

Technorati Tags: Javascript, DOM, style, display, code

Popularity: 57% [?]