A Free JavaScript Speed Boost for Everyone!

A Free JavaScript Speed Boost for Everyone!: “An exciting development in the world of DOM scripting is the W3C Selector API. Up until now, using the DOM Level 2 API, the only way to obtain references to HTML elements in the DOM was to use either document.getElementById or document.getElementsByTagName and filter the results manually. With the rise of CSS, JavaScript programmers asked the obvious question, ‘If the browser has a really fast way of selecting HTML elements that match CSS selectors why can’t we?’.

The Selector API defines the querySelector, and querySelectorAll methods that take a CSS selector string and return the first matching element or a StaticNodeList of matching elements, respectively. The methods can be called from the document object in order to select elements from the whole document or a specific HTML element to select only from descendants of that element.

To illustrate how much easier your life will be using the Selector API, have a look at this example HTML:

<ul id='menu'>
  <li>
    <input type='checkbox' name='item1_done' id='item1_done'>
    <label for='item1_done'>bread</label>
  </li>
  <li class='important'>
    <input type='checkbox' name='item2_done' id='item2_done'>
    <label for='item2_done'>milk</label>
  </li>
  <!-- imagine more items -->
</ul>

Our task is to check all the checkboxes for the list items that have the class ‘important’. Using only DOM Level 2 methods we could do it this way:

var items = document.getElementById('menu').getElementsByTagName('li');
for(var i=0; i < items.length; i++) {
  if(items[i].className.match(/important/)) {
    if(items[i].firstChild.type == 'checkbox') {
      items[i].firstChild.checked = true;
    }
  }
}

Using the new selector API we can simplify it to this:

var items = document.querySelectorAll('#menu li.important input[type='checkbox']');
for(var i=0; i < items.length; i++) {
  items[i].checked = true;
}

That’s much nicer! The methods also support selector grouping — multiple selectors separated by commas. The Selector API is working right now in Safari 3.1, the Internet Explorer 8 beta, and Firefox 3.1 alpha1. Opera is also working on adding support for the API.

If you’re a fan of one of the many JavaScript libraries available you’re probably thinking ‘But, I can already do that.’ One of the great examples of the benefits of using JavaScript libraries are the implementations of CSS selectors found in nearly all of them. Recently we’ve seen huge speed improvements in the CSS selector implementations because library authors have been sharing their techniques. So what’s the benefit of using the Selector API? In a word: speed — native implementations are fast! And better yet all of the javascript libraries are poised to benefit. jQuery and Prototype are already developing implementations that make use of the Selector API, while The Dojo Toolkit, DOMAssistant and base2 have already made use of it.

There’s a reason why those 3 libraries were the first ones to benefit. Kevin talked about the potential problem back in Tech Times #190 in the article titled ‘Is Your JavaScript Library Standards Compliant?’ The Selector API makes use of standard CSS selectors so if the browser doesn’t support a certain selector then you won’t be able to use it. The libraries that have already taken advantage of the Selector API are those that only supported standard CSS selectors. For those libraries, supporting the API was (almost) as easy as doing this:

if(document.querySelector) {
  return document.querySelector(selector);
} else {
  return oldSelectorFunction(selector);
}

Libraries that support custom selectors will have more work to do. The risk is that if you have used custom CSS selectors extensively in your project, it may be difficult for your chosen library to pass on the speed benefit to you because the library will have to use its default selector instead of the Selector API. If the library somehow rewires its custom selectors so that they can utilize the Selector API, the secondary risk is increased code bloat.

Hopefully the Selector API will encourage the use of standard CSS selectors over custom ones. In fact if uptake of the new browser versions is good and the performance benefits of the new Selector API are compelling enough we could see custom selector functionality moved to supplementary libraries you only need to use in case of legacy compatibility requirements.

Dean Edwards’ base2 Library has the nicest implementation in my opinion. Base2 implements the API exactly, which means you can write your JavaScript using standard the standard API methods — Base2 only creates custom querySelector and querySelectorAll methods if the browser doesn’t support them. You can’t get any cleaner than that. Base2 does, however, implement the non-standard ‘!=’ attribute selector in it’s custom selector function, apparently because of peer pressure, so it’ll have to have points deducted for that.

Regardless of whether you use a JavaScript library or roll your own, the new browser implementations of the Selector API give everyone an instant speed boost. We all win, hooray!”

(Via SitePoint Blogs.)

The Future of Search According to Google

The Future of Search According to Google: Google VP Marissa Mayer talked about the future of search on the Google blog this afternoon. Mayer apparently spent Saturday keeping track of all the things that came up in conversations that she wished she could search for. The result was a long list of questions ranging from ‘Which school has a team called the Banana Slugs?’ to ‘What are the dance steps to the Charleston?’ to ‘What kind of bird is that flying over there?’

I would wager that for most of us, if we repeated Mayer’s exercise we’d each come up with an equally long and random list of potential search queries. According to Mayer, she could come up with answers to all of her questions (and does at the end of her post), but couldn’t do it ‘ideally or easily’ using today’s search tools, which she calls ‘a 90% solution,’ in which the remaining work will require the most effort.

‘Search is a science that will develop and advance over hundreds of years. Think of it like biology and physics in the 1500s or 1600s: it’s a new science where we make big and exciting breakthroughs all the time,’ wrote Mayer, saying that it could be a hundred years or more before we have ‘an understanding of the proverbial molecules and atoms of search.’

Mayer also presents a concise definition of Google’s ideal search engine, and presumably what they’re working toward:

‘[The idea search engine is] your best friend with instant access to all the world’s facts and a photographic memory of everything you’ve seen and know. That search engine could tailor answers to you based on your preferences, your existing knowledge and the best available information; it could ask for clarification and present the answers in whatever setting or media worked best.’

To reach that goal, Mayer talked about the things that she’d like to see improved upon in the near future.

Modes

Mayer says that search needs to be more accessible. For much of her Saturday experiment she wasn’t near a computer, so couldn’t just sit down and do a search. Mobile search is getting better, but it’s still slow and clunky and interrupts the flow of conversation. Mayer even throws out the wacky (and slightly creepy) idea of a wearable device that constantly listens to you talk and searches for answers to questions you voice.

In addition to accessibility and better mobile search, Google wants to expand upon the ways we interact with search, which means voice, natural language, and images. ‘You should be able to talk to a search engine in your voice. You should also be able to ask questions verbally or by typing them in as natural language expressions,’ writes Mayer. ‘You shouldn’t have to break everything down into keywords.’

Mayer expects to see advances in these areas in the next ten years that will have us searching via cell phone using voice and speaking in natural language, or by playing a song or taking a picture.

Media

Google bought YouTube for a reason, after all. Mayer says that links to information can be great, but some searches — like her need to remember how to dance the Charleston — can’t be readily solved with textual results. Mayer says that over the past year Google has been trying to figure out how to take advantage of rich media results and display them in the best way possible. She promises that we’ll see the ‘fruits of this experimentation in the coming months,’ but that over the next 10 years things will change even more dramatically.

We theorized in July that an iGoogle video search widget hinted at some of that future.

‘The one thing that the search experience can’t be – especially in the face of the online media explosion we’re currently experiencing – is stagnant,’ she says.

Personalization

I’ve argued here that social search isn’t the future, but it is a feature of future search engines. ‘Don’t get me wrong, social search is a great idea. Leaning on data from Twitter, StumbleUpon, del.icio.us, Digg, and every other site you participate in to augment and enhance search results is something that someone will do soon,’ we wrote. ‘And whenever someone figures out how to do it well — which will involve making social search run in the background during traditional searches, it will rock.’

We put our money on Microsoft and Facebook innovating first in this area, but Google isn’t sitting still. ‘Search engines of the future will be better in part because they will understand more about you, the individual user,’ promises Mayer. Mayer talks about Google learning from your previous search history, your location, and your social graph.

‘There’s a lot of expertise, knowledge, and context in users’ social graphs, so putting tools in place to make ‘friend-augmented’ search easy could make search more efficient and more relevant,’ she writes.

Language

Why is Google investing so much time and effort into machine translation? Simple, says Mayer, the web isn’t all in one language. ‘We know there are cases where an answer exists on the web, but not in a language you read,’ she writes. ‘The basic concept is — if the answer exists online anywhere in any language, we’ll go get it for you, translate it and bring it back in your native tongue. This is an incredibly empowering idea that could really change the way that users experience the web and communicate with each other, particularly in languages where not a lot of native content is available.’

Conclusion

This month, Google turned 10 years old, and Mayer’s look into the future is a thought experiment about how Google might look at 20. It’s an interesting read, though, and provides insights into where Google thinks search is going and where they might be investing their R&D money over the next few years.”

(Via Clippings.)

Künstlersozialkasse: Abschaffen?

Künstlersozialkasse: Abschaffen?: “Die Bundesländer Baden-Württemberg, Brandenburg, Bremen, Hessen, Niedersachsen, Sachsen-Anhalt und Schleswig-Holstein machen sich mit einem Antrag im Bundesrat für die Abschaffung der Künstlersozialversicherung stark. Weil weniger Bürokratie und so. Ganz lieb.

Nun ist es nicht so, dass ich die KSV ununterbrochen supertoll finden würde. Wir führen bspw. Beiträge ab, selbst wenn keiner der Autoren oder Designer oder Programmierer oder Fotografen, deren Leistungen wir in Anspruch genommen haben, in der KSK sind. Das nervt und kostet Geld, ist aber der Preis für einen der sehr raren Solzialbereiche, in denen in Deutschland so etwas wie künstlerische Selbstständigkeit oder Kulturschaffen überhaupt wahrgenommen wird. Schließlich erwartet einen meist nichts als reines Entsetzen, wenn man im September 2008 noch nicht genau sagen kann, wieviel man im Januar 2009 verdienen wird (Ha! Wer weiß das schon?), keine bezahlten Urlaubszeiten hat oder keine regelmäßigen und immer gleich hohen Zahlungseingänge auf seinem Konto nachweisen kann.

Auch die Aufnahme in die KSK ist eine Geschichte für sich, ich kenne genügend Leute, die es trotz klar künstlerischer Tätigkeit nicht in die KSK »geschafft« haben.

Trotzdem: Die KSV/KSK abschaffen, um Bürokratie zu vermeiden?
Da fallen mir ein Haufen dringendere Startpunkte ein.”

(Via Spreeblick.)

TYPO3-Podcast: Grafisches Text-Menü per TypoScript erzeugen

TYPO3-Podcast: Grafisches Text-Menü per TypoScript erzeugen: “typo3-podcast: grafisches text-menü per typoscript erzeugen

Im aktuellen Podcast von TYPO3-Gründer Kasper Skårhøj geht es um die Erstellung eines TypoScript-basierten grafischen Text-Menüs. Dirk Paulus und Jochen Stange von der Bad Dürkheimer Webagentur „die medienagenten‘ stellen das gemeinsam mit Arnd Messer, Geschäftsführer der Wilhelmsfelder Webagentur…

Dirk Paulus und Jochen Stange zeigen in der gut sieben Minuten langen Podcast-Folge eine Möglichkeit, per TypoScript ein grafisches Textmenü zu erzeugen, dessen Aussehen und Verhalten per CSS gesteuert werden. Dabei kommt das Menü ohne JavaScript aus und ist damit barrierefrei.

Das Menü besteht aus zwei Teilen: einem grafischen Menü und einem verbesserten Layer-Menü. Die Demosite www.gtmenu.de zeigt es im Einsatz. Der für das Menü erforderliche Code steht auf snipplr zum Download bereit.

Jochen Stange weist in dem Podcast ausdrücklich darauf hin, dass der Einsatz eines solchen Menüs erst ab TYPO3-Version 4.1 fehlerfrei funktioniert. Erst ab dieser Version ist das TypoScript-Array „{TSFE:lastImgResourceInfo|0}‘ verfügbar, durch den die Abmaße eines Menüpunkts (Breite und Höhe) direkt als Stlye-Eigenschaft in den Menüpunkt geschrieben werden können.

Der Podcast wurde während der letzten TYPO3-Snowboardtour aufgezeichnet, die Ende März in Laax in der Schweiz stattgefunden hat.

(Via t3n.yeebase.com – Open Source, Web & TYPO3.)