Posts Tagged ‘javascript’

Re: Dustin’s Brain Teaser

Thursday, July 10th, 2008

I’m a bit late, but rather later then never :). I just didn’t had even 10 Minutes spare time in the last few days.

Here is my response to Dustin’s brain teaser. I’m offering a solution without regular expressions. Though after reading the problem I first thought “Nice, I’ll use regular expressions.”. But then I realized that now I’m facing two problems :). I’m really not that good at regexps.
But I promise I’ll keep the teaser in mind and one day I’ll solve it with regular expressions.

var teaserNoRegExp = function() {
  var input = ['a', 'b', 'c', 'c', 'd','e', 'e','e', 'e',
'e', 'f', 'e', 'f', 'e','f', 'a', 'a', 'a', 'f', 'f', 'f'];
  var output = '';

  // assume Array.prototype.forEach

  var spanOpened = false;
  input.forEach(function(el, index, input){
    if (input[index-1] == el && input[index-2] == el && !spanOpened) {
      output = output + '';
      spanOpened = true;
    }
    output = output + ' ' + el;
    if (input[index+1] != el && spanOpened) {
      output = output + '';
      spanOpened = false;
    }
  });
  document.getElementById('result').value = output;
};

P.S. It actually took me a minute or two to write it down.

nofollow Bookmarklet

Saturday, June 14th, 2008

Here is a smallish bookmarklet that highlights all links that are marked with the nofollow attribute. Just drag and drop it to your bookmarks bar.

show nofollow

In its current version the bookmarklet is very very simple: it just highlights nofollow-links and reports back the total number. However it only works on frameless documents.

Here’s the code in a readable <code>-block:

javascript:(function(){
  for (var i = 0, a = document.getElementsByTagName('a'), b = a.length, c = b; i < b; i++) {
    a[i].rel.match(/nofollow/i) ? a[i].style.backgroundColor = '#ff0066' : c--;
  }
  alert(c);
})();

That’s the shortest I could get. Have fun :).

P.S. You can test-drive it right away on this page: the about-link in the footer is a nofollow-link.

P.P.S. It’s the browser that turns a double minus into a single long dash.

Unobtrusive Smilies :)

Wednesday, February 20th, 2008

I don’t know whether you may find use for this, it might be a complete overhaul, but anyway.

Smilies are small inline images that represent a mood like being sad :( or help enrich the context with some emotion like winking after a joke ;). Everybody uses them but no one actually puts down those img-tags: we rely on our smart CMS’s to the job. Smilies are accessible since screen readers use either the title or the alternative text attributes of the img-tag. The problem is that such inline images aren’t semantically correct: they should be part of the text as text and not as images.

I’ve put down a small (~2KB minified) mixture which filters all smilies and replaces them with images in an unobtrusive way.

Download uns v. 0.2

What is the basic?

Default behavior is to query the document for span-tags that have the class smiley. Each one option is customizable.

What’s the compatibility?

It’s known to work with Firefox 2, Firefox 3, IE5.5, IE6, IE7, Safari 3 and Opera 9 under Windows, Safari 3 under Mac OS X and Konqueror 3.5 under Kubuntu.

How to trigger it?

Use it just as any other unobtrusive JavaScript out there:

window.onload = function() {
  uns.parse();
};

Or gain performance by providing a node where smilies are to be found, like the main content div-block:

window.onload = function() {
  uns.parse({node: document.getElementById('content')});
};

You can also provide an onfinish callback:

window.onload = function() {
  uns.parse({
    node: document.getElementById('content'),
    onfinish: function() {
      alert('finished');
    }
  });
};

Or you can add additional smilies:

window.onload = function() {
  uns.smilies({
    ':cska:': 'images/cska.gif'
  });
  uns.parse();
};

You can also AJAX load new content into some poor div and run the parser afterwards:

xhr.onreadystatechange = function() {
  if (xhr.readyState == 4) {
    var comments = document.getElementById('comments');
    comments.innerHtml = xhr.responseText;
    uns.parse({node: comments});
  }
};

Where can it be seen?

I’ve put down a small demo.

Log

20.02.2008: 0.1 Initial release.
22.02.2008: 0.2 Added support for native getElementsByClassName and tested with Firefox 3, added support for IE5.5 and IE6.

Slickspeed Shots, Part 2

Saturday, July 7th, 2007

In addition to the first part of screenshots of the Slick Speed test suite I’ve been able to get my hands on a Konquerer 3.5.6 running on Kubuntu Feisty.

on Linux (kubuntu feisty)

Konquerer 3.5.6

Default install. 383KB, 1000×1190.
slickspeedwk3lin

Prototype and mootools throw an error on every single selector. dojo on Konquerer is comparable to dojo on Firefox on Linux and is the fastest one along with ext. However the winner this time is jQuery: it throws only one error, like cssQuery, but is twice as fast.

Final Notes

Note that the jQuery team released the new 1.1.3 version just a few days back and selector speed is improved by the amazing 800% (!!!). This is one hell of improvement. I haven’t made new tests on my own, be aware. I will be just giving a calculation of the improved time, next to the measured one.

So I’ve decided to make a simple error and time count, but excluding the double Firefox 2.x install. In parenthesis is given the result without Konquerer:

  • Prototype: 48 » 6326 (10 » 6312)
  • jQuery: 46 » 34813(45 » 32689)
  • jQuery 1.1.3, improved by 800%: 46 » 4351.625 (45 » 4086.125)
  • mootools: 53 » 5156 (15 » 5150)
  • ext 60 » 6925(55 » 6405)
  • cssQuery 11 » 64219 (10 » 60550)
  • dojo 39 » 4747(36 » 4195)

While making that count I’ve made one discovery: every library struggles with the same selectors on the different A-graded browsers. Another one interesting fact is that cssQuery offers the same browser support on all participants, even on IE5.5

There are no winners in this case study, because each library has its own uniqueness and greatness. Besides, all of them are comparably fast and offer a comparable amount of supported selectors. Now let’s go back to the real thing - coding on top of them and not comparing them!

Slickspeed Shots

Wednesday, June 13th, 2007

on Windows

Firefox 1.5

A fresh install. No extensions. 396KB, 1000×1224.
slickspeedff15win

Firefox 2.x

A fresh install. No extensions. 400KB, 1000×1240.
slickspeedff2xfreshwin

A bunch of extensions: ~25. 399KB, 1000×1235
slickspeedff2xdefaultwin

IE 5.0

MultipleIE install. 156KB, 1000×679.
slickspeedie50win

IE 5.5

MultipleIE install. 530KB, 1000×1452.
slickspeedie55win

IE 6.0

MultipleIE install. 404KB, 1000×1221.
slickspeedie6xwin

IE 7.0

Default install. 384KB, 1000×1221.
slickspeedie7xwin

Opera 9.1

Default install. 392KB, 1000×1261.
slickspeedop91win

Opera 9.2

Default install. 399KB, 1000×1242.
slickspeedop92win

Safari 3 beta

Default install. 484KB, 1000×1132.
slickspeedsf3bwin

Observations on Windows

All libraries behave equally fast/slow on the different Firefox installations. Except jQuery and mootools on my default FF install. This could be caused by GMail Notifier, which is checking my mail every minute.

IE7 improves speed by factor 2. Frustrating is that IE5.5, IE6 and even IE7 return different results on the * selector compared to other browsers and compared between the libraries.

Opera 9.2 is slower than 9.1.

Safari is in beta and is a freshman among Windows browser, so results are “just for fun”.

Prototype, mootools and dojo are the winners. I am somehow disappointed by jQuery.

on Linux (ubuntu feisty)

Firefox 2.x

A fresh install. No extensions. 375KB, 1000×1190.
slickspeedff2xfreshlin

A bunch of extensions: ~25. 375KB, 1000×1190.
slickspeedff2xdefaultlin

Opera 9.2

Default install. 325KB, 1000×1192.
slickspeedop92lin

Observations on Linux

Opera is the faster one on my Linux box, but it took an awful long time to load the official test page.

Both Firefox 2.x profiles, clean one and one with a bunch of extension, behave quite equally - there are no speed improvements by factor 3 like mootools on Windows.

I couldn’t find any trident or WebKit browsers for ubuntu, but if you know of any feel free to drop me a line and I will run test once again.

We have the same winners - prototype, mootools and dojo.

Final Notes

Observations

Overall: libraries are running faster under Windows.

Locally I’ve tested also MochiKit - it threw a lot of errors.

Download the Shots (CC BY-SA)

Download SlickSpeed on Windows & Linux (~4.8MB).

Update: Note, that the Konquerer screenshot is not included in the archive. Download it separately.