You searched for: 'ruter'

Wednesday, April 28th, 2010

Telling robots about your crawl-able Ajax apps

Category: Ajax, Google

Weston Ruter wants to talk to the search robots out there and tell them about the URL format for crawling Ajax apps.

Google came out with a spec for doing this with hash bang URLs such as: http://shepherdinteractive.com/#!portfolio/interactive/.

What if we could tell Google and others something like:

  1. <meta name="crawlable-fragment-prefix" content="/">

and Google would grok http://shepherdinteractive.com/#/portfolio/interactive/ and convert it to http://shepherdinteractive.com/?_escaped_fragment_=portfolio/interactive/.

Want flexibility? Or want simplicity and think we should all just hash bang away?

Posted by Dion Almaer at 12:37 am
10 Comments

+++--
3.7 rating from 38 votes

Monday, December 14th, 2009

Text to Speech via HTML5 Audio

Category: Accessibility

html5texttospeach

Weston Ruter has created a nice mashup that marries HTML5 Audio support in modern browsers with the new Google Translate API that does text to speech (for them):

Recently Google Translate announced the ability to hear translations into English spoken via text-to-speech (TTS). Looking at the Firebug Net panel for where this TTS data was coming from, I saw that the speech audio is in MP3 format and is queried via a simple HTTP GET (REST) request: http://translate.google.com/translate_tts?tl=en&q=text. Google Translate notes that the speech is only available for short translations to English, and it turns out that the TTS web service is restricting the text to 100 characters. Another restriction is that the service returns 404 Not Found if the request includes a Referer header (presumably one that is not for translate.google.com).

In spite of the limitations of the web service which certainly reflect the intention that the web service is only to be used by Google Translate, thanks to the new HTML5’s Audio element and rel=”noreferrer”, the service may be utilized by client-side web applications

Others have been playing with text to speech too, such as this French Ubiquity command. I hope that Google makes it a public API of translate!

Posted by Dion Almaer at 6:24 am
3 Comments

+++--
3.4 rating from 31 votes

Tuesday, July 28th, 2009

CSS Gradients for All!

Category: CSS

Weston Ruter has created a very cool library that enables CSS gradients on non-WebKit browsers (at least, a subset). Incredibly cool:

CSS Gradients via Canvas provides a subset of WebKit’s CSS Gradients proposal for browsers that implement the HTML5 canvas element.

To use, just include css-gradients-via-canvas.js (12KB) anywhere on the page (see examples below). Unlike WebKit, this implementation does not currently allow gradients to be used for border images, list bullets, or generated content. The script employs document.querySelectorAll()—it has no external dependencies if this function is implemented; otherwise, it looks for the presence of jQuery, Prototype, or Sizzle to provide selector-querying functionality.

The implementation works in Firefox 2/3+ and Opera 9.64 (at least). Safari and Chrome have native support for CSS Gradients since they use WebKit, as already mentiond.

This implementation does not work in Internet Explorer since IE does not support Canvas, although IE8 does support the data: URI scheme, which is a prerequisite (see support detection method). When/if Gears’s Canvas API fully implements the HTML5 canvas specification, then this implementation should be tweakable to work in IE8. In the mean time, rudimentary gradients may be achieved in IE by means of its non-standard gradient filter.

CSS Gradients via Canvas works by parsing all stylesheets upon page load (DOMContentLoaded), and searches for all instances of CSS gradients being used as background images. The source code for the external stylesheets is loaded via XMLHttpRequest—ensure that they are cached by serving them with a far-future Expires header to avoid extra HTTP traffic.

The CSS selector associated with the gradient background image property is used to query all elements on the page; for each of the selected elements, a canvas is created of the same size as the element’s dimensions, and the specified gradients are drawn onto that canvas. Thereafter, the gradient image is retrieved via canvas.toDataURL() and this data is supplied as the background-image for the element.

An aside. I only just noticed the Gears Canvas API. It doesn’t quite do what you think….. I always wanted to implement Canvas in Gears. It is also strange that Gears is so under the radar at Google these days. One blog post per year?. I guess all of the work is going into Chrome / WebKit itself.

Posted by Dion Almaer at 6:00 am
13 Comments

++---
2.9 rating from 32 votes

Thursday, January 15th, 2009

CSS Transitions Shim; Getting transition support into other browsers

Category: CSS

Weston Ruter has developed a very nice shim that allows you to get CSS Transitions support in browsers that do not have the WebKit renderer.

He has an innovative approach that uses XBL and HTC bindings to detect when a style rule changes and thus when the selected elements need to be animated/transitioned into the newly matched transition style rule:

Declarative animations in CSS are an attractive solution, and I wanted to use the technology today.
I therefore developed a prototype script which implements a subset of CSS Transitions via jQuery Animation (inspired by Chris Schneider’s CSS Effects powered by mootools).

This implementation requires a binding language such as Mozilla’s XBL or MSIE’s DHTML Behaviors. Because of this, the script works in Firefox 2, Firefox 3, and MSIE 7 (IE 6 is not supported, but it does have limited functionality); in WebKit-based browsers the script does nothing since CSS Transitions are supported natively. Opera is not supported because it has no binding language.

Why is a binding language required? The script parses the stylesheet rules looking for transition-* properties, and when it finds one, it adds a binding to that style rule so that when the rule gets applied, the binding’s code is executed on each of the newly selected elements.

This enables transitions to get triggered when a class name is changed. The binding code knows the transition style properties which were defined in its containing style rule, so when it gets executed it transitions the elements’ styles from the previously matched style rule to the styles defined in the newly matched style rule. Each of these style rules I’m calling transition states.

He then goes on to talk about the subtle issues. Very nice work indeed Weston!

Posted by Dion Almaer at 5:09 am
3 Comments

++++-
4.1 rating from 19 votes

Friday, June 6th, 2008

Google Analytics after onLoad and document.write for XHTML

Category: JavaScript

I saw two articles that were both looking at similar issues.

Firstly, Pete Higgins has looked at the fact that Google Analytics is normally loaded via serial script tags which cause the rest of the application to wait and created a simple wrapper that changes things.

We have all seen the tell tale: “waiting for google-analytics.com … “.

This is usually before the body tag is closed, which causes [at least] Dojo’s addOnLoad() function to wait until after ga.js has been loaded, and executed. I notice it most on the SitePen Dojo QuickStart guide. The whole guide is sent as valid HTML and CSS, then enhanced to break major sections into a custom tabbed view, with simple navigation. Unfortunately, all the code to do that is run from within an addOnLoad function, and my poor pitiful ethernets here in Tennessee make ga.js take upwards of five seconds to load. Long story short, sometimes I’m presented with a nasty jolt of rendering as the navigation is added, and the unselected chapters go hidden.

I decided it was a safe bet I could just append a script tag to my head element, and run that onLoad, allowing the rest of the code to execute as soon as the Dom was ready, regardless of Google being ready.

He pasted in the code (with his hard coded agent…. change that):

javascript

  1. dojo.provide("dojox.analytics.ga");
  2. dojo.mixin(dojox.analytics.ga, {
  3.     // _acct: String
  4.     //      your GA urchin tracker account numbers.
  5.     _acct: dojo.config.urchin || "",
  6.  
  7.     // _loadInterval: Integer
  8.     //      time in ms to wait between checking again
  9.     _loadInterval: 420,
  10.  
  11.     _loadGA: function(){
  12.         // summary: load the ga.js file and begin initialization process
  13.         var gaHost = ("https:" == document.location.protocol) ? "https://ssl." : "http://www.";
  14.         var s = dojo.doc.createElement('script');
  15.         s.src = gaHost + "google-analytics.com/ga.js";
  16.         dojo.doc.getElementsByTagName("head")[0].appendChild(s);
  17.         setTimeout(dojo.hitch(this, "_checkGA"), this._loadInterval);
  18.     },
  19.  
  20.     _checkGA: function(){
  21.         // summary: sniff the global _gat variable Google defines.
  22.         //      if it exists, run _gotGA, otherwise, do another interval
  23.         setTimeout(dojo.hitch(this, window['_gat'] ? "_gotGA" : "_checkGA"), this._loadInterval);
  24.     },
  25.  
  26.     _gotGA: function(){
  27.         // summary: initialize the tracker, we've got ga.js loaded
  28.         var ga = this._tracker = dojo.hitch(_gat, "_getTracker", this._acct)();
  29.         ga._initData();
  30.         ga._trackPageview();
  31.         this.GAonLoad.apply(this, arguments);
  32.     },
  33.  
  34.     GAonLoad: function(){
  35.         // stub function to fire when urchin is complete
  36.         // you also have access in this function to this._tracker, which is the
  37.         // root tracker instance you called _initData() on
  38.     }
  39.  
  40. });
  41.  
  42. // start it all up after body is ready:
  43. dojo.addOnLoad(dojox.analytics.ga,"_loadGA");

This will be in Dojo itself soon, so you will be able too:

javascript

  1. var pagetracker = new dojox.analytics.Urchin({ ua: "UA-123456-7" });
  2. pagetracker.trackPageView("/ajaxy-notification");

Secondly, Weston Ruter noted the other problem where Google AdSense and the AJAX Libraries API are using document.write() to inline script tags. In the past John Resig wrote a little wrapper to make document.write to DOM work instead. Weston builds on this work:

My solution, however, has a couple advantages as I see it. First, his solution uses some regular expression hacks to attempt to make the HTML markup well-formed enough for the browser’s XML parser, but as he notes, it is not very robust. Secondly, John’s solution relies on innerHTML which causes it to completely fail in Safari 2 (although this implementation also fails for an unknown reason). I’m trying a different approach. Instead of using innerHTML, this implementation of document.write() parses the string argument of HTML markup into DOM nodes; if the DOM has not been completely loaded yet, it appends these DOM nodes to the document immediately after the requesting script element; otherwise, it appends the parsed nodes to the end of the body.

I’ve incorporated John Resig’s own HTML Parser (via Erik Arvidsson), but I’ve made a couple key modifications to make it play nice with document.write(). I turned HTMLParser into a class with member properties in order to save the end state of the parser after all of the buffer has been processed.

To this class I added a parse(moreHTML) method which allows additional markup to be passed into the parser for handling so that it can continue parsing from where it had finished from the previous buffer. And by removing the last parseEndTag() cleanup call (for document.write() is anything but clean), it then became possible for multiple document.write() calls to be made with arguments consisting of chopped up HTML fragments like just a start tag or end tag, which is exactly what AdSense does and is a common usage of the method.

Check out the
full source code.

Posted by Dion Almaer at 7:35 am
5 Comments

++++-
4.1 rating from 20 votes

Friday, August 17th, 2007

Web Forms 2.0: Cross Browser Implementation

Category: HTML, Standards

Weston Ruter has created Web Forms 2, a cross-browser implementation of the WHATWG Web Forms 2.0 specification. This specification is currently a mature working draft and has been adopted by the W3C HTML Working Group to serve as a starting point for the next version of HTML. This implementation will follow the HTML 5 specification that evolves from the W3C process.

So far it features:

  • Extensions to form control elements
  • The repetition model for repeating form controls
  • The forms event model: Form validation
  • Fetching data from external resources (with the data attribute)

Weston has a test suite to play with.

Posted by Dion Almaer at 9:45 am
3 Comments

++---
2.5 rating from 56 votes

Tuesday, January 23rd, 2007

WHATWG Web Forms 2.0 Repetition Model Implementation

Category: JavaScript, Library

Weston Ruter has created a cross-browser JavaScript implementation of the WHATWG Web Forms 2.0 Repetition Model after taking to heart the spec that annotates:

The entire model can be emulated purely using JavaScript and the DOM. With such a library, this model could be used and down-level clients could be supported before user agents implemented it ubiquitously. Creating such a library is left as an exercise for the reader.

A simple example is:

  1. <tr id="order" repeat="template">
  2.       <td><input type="text" name="row[order].product" value=""/></td>
  3.       <td><input type="text" name="row[order].quantity" value="1"/></td>
  4.      </tr>

Read the spec for more details, such as the add/delete/moveup/movedown features.

Posted by Dion Almaer at 10:00 am
6 Comments

+++--
3.6 rating from 36 votes