I’m running some tests tonight on my JavaScript tabber code… yeah, I would say it handles nested tabs.
Archive for the ‘JavaScript’ Category
Nesting instict
Monday, March 20th, 2006Oh what tangled webs we weave…
Wednesday, March 15th, 2006Because I didn’t want to foul up the namespace in my JavaScript tabber, I attached the tabber object directly to the DOM element it was controlling, then I had to add several “pointers” back and forth between the object and various DOM elements so they could get to each other without relying on any variables. When you look at it like this, it seems rather complicated:
I wonder if there are any issues with “memory leaks” due to IE’s faulty garbage collection… let me know if you notice anything.
Update: Hold the presses, I found a few more links. Some of these pointers are not used except when creating new elements to add into the DOM, so I can probably just switch those to use local variables. It shouldn’t matter, but with IE’s faulty garbage collection, who knows if it might cause problems.
Update 
h good god, the squiggly lines have taken over!
JavaScript-safe string variable
Monday, March 13th, 2006If you have a bunch of funky data to store in a JavaScript string, for example some HTML, you have to be careful to “escape” all the special characters so it doesn’t break your script.
Or you can just use my web data encoder and choose “JavaScript-safe” variable:
You can also use other encodings, such as encodeURIComponent to make a complex URL safe to pass as a component of another URL.
BarelyFitz discussion boards are back
Saturday, March 11th, 2006A year ago, the BarelyFitz discussion boards were hacked due to a nasty bug in PHPBB, so I had to remove them.
In the meantime I had a new edition to my family and a transition from running my own web design company to working as a full-time employee at WebMD. Needless to say, I have been busy and the forums were not a high priority.
But finally the forums are back (and hopefully this will stem the many email questions I receive about my open-source projects).
Eliminating redisplay flashes in JavaScript
Thursday, March 9th, 2006The Holy Grail in creating dynamic HTML is to have a page that works perfectly even when JavaScript is disabled. You want your page to be beautiful and dynamic, but you also want it to be accessible, search-engine optimized, and printable.
To make this happen you start with plain, semantic HTML, then you add a JavaScript layer to rework the page into something better:
One problem with this technique is that your JavaScript must run after the HTML has been set up and rendered on the page, so a user with a slow connection might see something like this using my JavaScript tabbifier:
This is not too pretty, so obviously we want to make it stop.
Your first thought might be “I’ll just add a style to the content to make it hidden (CSS display:none), then my JavaScript will run and reveal it!” But that puts a big crack in our Holy Grail, because if you use CSS to hide the content, it will not be visible to users who do not have JavaScript.
Here’s the method I used:
- Add a class javascript-hide-me to the content you need to hide, but do not define that class in your CSS.
- Before the content, use JavaScript to define the CSS class. The easiest way to do this is by using document.write in the head section of the page, but you will have to directly modify the DOM if you are serving XHTML pages that use MIME type application/xhtml+xml.
- After the content has been transformed, use JavaScript to remove the CSS class and reveal the content.
Here are two examples, one that exhibits the flashing problem, and another that fixes it using the technique described above. Note that in order to see the flashing problem, you need a slow internet connection: I recommend throttling your connection using the excellent Charles Web Debugging Proxy.
Updates 2006-03-09
Welcome, Ajaxians!
Bobby describes an alternate technique in case you are serving XHTML pages that use MIME type application/xhtml+xml.
Steve Clay makes a valid point that we should check for DOM compatibility before writing the styles on the page.
Easier JavaScript object constructor arguments
Tuesday, March 7th, 2006I stumbled across a nice technique when making my JavaScript tabifier.
Say you have a JavaScript object constructor:
function myObject() {
this.firstName = 'Patrick';
this.lastName = 'Fitzgerald';
}
var o = new myObject();
o.firstName = 'Lauren';
o.lastName = 'Fitzgerald';
But you want to make it easy to override the properties, so you pass them in as arguments to the constructor:
function myObject(firstName,lastName) {
if (firstName) { this.firstName = firstName; }
else { this.firstName = 'Patrick'; }
if (lastName) { this.lastName = lastName }
else { this.lastName = 'Fitzgerald'; }
}
var o = new myObject('Lauren','Fitzgerald');
Fine and dandy, but what if you start adding more properties? Suddenly your object constructor is getting complicated, ugly, and confusing:
myObject(firstName,lastName,phone,ssn,hairColor);
Instead set up all the default values for your object properties, and use a single argument to override the values:
function myObject() {
this.firstName = 'Patrick';
this.lastName = 'Fitzgerald';
this.phone = '';
this.ssn = '';
this.hairColor='';
for (var n in arguments[0]) { this[n] = arguments[0][n]; }
}
By adding one line to your object constructor, you have given the user the flexibility to change any of the default parameters. Furthermore, they can specify the parameters in any order, and leave out the ones they don’t want to change.
Compare the two:
var o = new myObject('Lauren','','','','brown'});
var o = new myObject({firstName:'Lauren',hairColor:'brown'});
This also gives the user the ability to add custom parameters or even methods to the object, all with a single call to the object constructor.
See also: Using JavaScript objects for function arguments with default values
He cupped her university of phoenix online universities
Sunday, March 12th, 2006Within a few hours of re-activating the discussion boards here on BarelyFitz, I started getting spammers.
Spammers have determined that if they register for a message board account, they can leave a link to their webpage, and the link shows up on the message board user list. I’ll have to hack PHPBB to remove this back door for spammers.
I noticed the following interesting attempt: instead of leaving an obvious link to a spammer site, the link was something like the following:
This URL looks relatively innocent – after all it has the word “religious” in it! But if you follow the link, you get a page that uses JavaScript to immediately redirect you to the spammer’s site.
After a bit more digging into the redirect page I found a JavaScript program that does the redirecting (heavily obfuscated to prevent Google from discovering the true purpose of the script), plus a bunch of computer-generated text to geared to increase their search results, a sample of which follows:
Update 2006-03-14: This morning there were three message board spam posts, which I quickly eliminated when I saw them in my RSS feed. They wouldn’t have helped the spammer since the links were all marked as rel=”nofollow” after some changes I made to PHPBB. But I just don’t want to deal with it, so I changed the discussion boards to require registration before posting. Sigh… why do spammers have to ruin it for all of us.
It would be nice if PHPBB had the same “moderate once” system that WordPress uses.
Posted in HTML, JavaScript, Message Boards, PHPBB, Spam, Web, WordPress, blogging, comment spam | 2 Comments »