This article is dedicated to regular expressions in python based on javascript knowledge. This is the follow up to the article “Javascript to Python API reference guide”.
There is not much of python RegExps that you could directly map to javascript. For this reason i’ve decided to write an introduction article to regexp in python, by using your current knowledge of JavaScript RegExps. It would still be possible to reverse-engineer this article to get the knowledge about JavaScript based on Python examples ;). But enough talking, let’s start diving.
(Main)
Working with regexp begins with importing the “re” module.
import re
Now you are ready to perform searches, but forget about the lovely inline RegExp literals like /zork/gi. Python leaves us with normal, boring strings e.g., "zork" and flags also are not the part of the expression, but are defined in a different place. As you will shortly see for yourself.
Due to the fact that the expression is a string, you will quickly get tired of using escapes in your regexp. The good news is that python has raw-strings, which can help you with this problem. Just prepend the ‘r’ symbol before a string and backslashes will be interpreted as characters and not escapes:
# python:
str = r"regexp\."
Now the basics are covered, it’s time to start. I propose we start this journey with a simple regexp test, which most of us perform everyday.
// js:
var r = /bork/.test("dork bork fork zork");
(r === true);
Python doesn’t provide any direct equivalent instead, the search method can be used to accomplish the desired task. This method returns None if nothing is found and this is exactly what we can use for our test. I will explain about the search method a bit later, but for now this will work as a test equiualent.
# python:
r = (re.search(r"regexp", "someString") != None);
Well, a test is a fine start, but a regexp is often used for real searching. And while you would expect that I will now tell you more about the search method, you will be disappointed 🙂
Next, we are going to search for all ( using GLOBAL flag ) occurrences of a regular expression in a string, but with a different method. If you have noticed, I’ve put an extra accent the GLOBAL word because the match method in javascript returns different information whenever the global flag and groups are used. Example:
From this snippet you can see that match omits groups and only entire matches are returned when global is on and shows group information when g is on.
On the other hand python is “more” consistent with return values. It doesn’t omit groups, instead it ONLY returns them. Which means that if you want to have a simple array of all matches, groups SHOULD be uncaptured ( by using ?: after parenthesis ).
See? This result has only groups in it and not an entire match.
Sometimes I use a workaround which gives me more powerful version – wrap entire regexp in a group and it will give the whole match as a first item in your tuple. Since it’s a quirk there is also a normal way of doing this in python, but I will tell about it later. First, the quirk example:
That’s fun, isn’t it, javascript has no direct mapping to such an extended result, you could achieve the same with replace, but that’s a different story. Still there are a couple of methods to go.
The next question is, how would you, in a pythonic way, get groups and the whole match result. Let’s start with a simple, non global version. In javascript it’s a matter of taking away the ‘g’ flag, right?
// javascript:
var result = "dork bork fork zork".match(/(b|z)ork/);
result == [ "bork", "b" ];
// full match of the regexp
var match = result[0]; // equals "bork"
var group1 = result[1]; // equals "b"
// var groupN = result[N];
In python you would use search as an equivalent. There is also the match method, which is similar to search, but it’s slightly limited. You can read more about it here
# python:
import re
result = re.search(r"(b|z)ork","dork bork fork zork")
# result == MatchObject instance
# full match of the regexp
match = result.group(0) # 0 can be omitted - result.group() will do the same
group1 = result.group(1)
# groupN = result.group(n)
re.search(r"(b|z)ork","dork") == None
While you are used to working with arrays of strings in javascript, python gives you access to the MatchObject itself. This object has a lot of extra information which you can use when doing regexp matches, just read the manual.
I think your next question is, what is a pythonic way of doing this for all matches? As you know javascript doesn’t have one and often the replace method is used for such situations.
// javascript :
"dork bork fork zork".match(/(b|z)ork/g, function(match, group1 ...groupN, pos, full_str) {
// use position, group information, etc
});
To achieve all group matches in python you can use the finditer method, which will return an iterator with MatchObject instances.
# python:
iter = re.finditer(r"(b|z)ork", "dork bork fork zork");
for result in iter:
match = result.group()
group1 = result.group(1)
Okidoki. The basics are covered. Now for the last part: flags, where do you put them and how do you use them.
Normally, regexps in python are compiled before being used. I haven’t used this feature ’cause I wanted examples to be as close as possible to the javascript ones. When regexps are compiled they have the same methods which I’ve already covered.
# python
import re
p = re.compile(r"(b|z)ork", re.IGNORECASE)
p.search("dork bork fork zork")
That finished my introduction. Before I go, I would like to give some advice about the findall method. Despite the fact that it’s easier to map it to your javascript knowledge, I would recommend that you use finditer instead of findall. First of all, you will save yourself time by not fixing captured groups all the time and the second reason is that finditer is much more powerfull and can be used for a broader scope of problems.
Do you also keep searching for JS terms to find out what Python API to use? I use this article as a reference guide of the javascript to python API.
Prologue
After constantly working with javascript for more than seven years I’ve decided to explore another programming language. Python became my language of choice.
Since I’m not doing python coding fulltime, I keep diving into the same docs of python again and again, in order to recall how to do simple and basic stuff. For example: looping through the different data types or searching in a string for a pattern.
My long-running relationship with JavaScript only makes the process of learning even more difficult. Every time I’m trying to do something in python i’m searching for the equivalent of javascript API in python. However it can take a long time before the answer is found. For example, how would you do charCodeAt in python? I have to say it took me a while to find an answer to this question, but then, time passes by and I forget it again.
For this reason I wrote this short reference guide. Though it only contains stuff which differs from the javascript perspective. This means I haven’t done a mapping for methods which are the same in both languages.
One piece of advice. In the python REPL you can execute the help function and pass any object to it. The help function will show you documentation regarding the passed object e.g.,
help([])
will return documentation about arrays.
Global stuff
escape
Syntax: escape(x)
import urllib;
urllib.quote(x)
unescape
Syntax: unescape(x)
import urllib
urllib.unquote(x)
parseFloat
Syntax: parseFloat(x)
float(x)
parseInt
Syntax: parseInt(x)
int(x)
Note: Be carefull with this one, since it might other thing than you expect. Often parseInt is used to parse any string ( with int or float in it) to an integer. In case you try to parse a float or non-valid number it will throw an error. This means that, stuff like:
int("123.456")
will break in python, but is still valid in javascript.
RegExp support in python is pretty BIG and is much more extended than in javascript ( IMHO: mostly like anything in Python ). That’s why I have dedicated a separate article to this subject. So if you are going to use regexps intensively I recommend you read that article as well.
Also match and replace are part of the String object, I specify it here in order to emphasize that searching and replacing in Python is not the same as it is in JavaScript.
test
Syntax: var r = /regexp/.test(“string”)
import re
r = (re.search(r"regexp", "someString") != None)
Note: search doesn’t return boolean value, but None if no match is found.
replace
Syntax: “string”.replace(/regexp/, “newSubStr”)
import re
re.sub(r"regepx", "originalString", "newSubStr")
Note: Please note that only match with the GLOBAL flag is presented here. The reason for that is explained in “Introduction into Python Regexp” as a follow up article.
Yesterday I came across two interesting JavaScript behaviors. They gave me different results based on the browser. The first one was only reproducible in Internet Explorer (IE) and the second one only in Firefox.
First, lets see the IE code:
var get = function() {
return function bla() {
alert( bla.property );
}
}
var fnc = get();
fnc.property = "Hello There!";
fnc();
If you think that this code alerts “Hello There!” you are half right. It does in all browsers, except the IE.
The second one also interesting, this is for the Firefox :
var get = function(flag) {
if (flag) {
function it() {
alert( "Flag is true" );
}
} else {
function it() {
alert( "Flag is false" );
}
}
it();
};
get( true );
When I typed it, I thought it would alert me “Flag is true”. Well, the problem is, my thoughts were correct, but only for the Firefox browser. In all other browsers it alerts “Flag is false”.
Experiment, test, analyze. Experiment again, test again, analyze again. This is the process of learning the environment, the language and the tools I work with. Taking things apart, looking inside, diving deeper and building a picture of understanding. I think JS is a language with a lot of hidden corners and this time I’ve decided to dig into timers and intervals of the JavaScript. This experiment grew into a browser-based activity monitor of JavaScript execution and I would like to share my experience about it, with you.
How it all started
As you all know, timers in JavaScript get triggered at the moment when the browser is idling. This is described very well in one of the John’s articles at http://ejohn.org/blog/how-javascript-timers-work/ : “Since all JavaScript in a browser executes on a single thread asynchronous events (such as mouse clicks and timers) are only run when there’s been an opening in the execution.”
This information gave me a pretty absurd idea: Is it possible to determine the active/idle state of the browser by using the “opening” behavior of the timers? I thought – yes. But the question is – how? If we start looping “setTimeout” with scheduled time of zero milliseconds, we could collect an interval between the timers and identify the current browser’s state ( active/idling ) based on the interval’s info. Something, like the picture below shows:
To prove for myself that this craziness had at least a small rational kernel, I built a small prototype. I injected it into a heavy ajax-based application and I was quite happy with the results. All the results I received had a common pattern in them, indicating that the calculated interval is a reliable source for tracking the browser’s activity. I do agree, that maybe this approach can’t be used for precise profiling of an application, but I still think that it could be used to get the global picture of the browser’s execution flow for the ajax driven applications.
Path into the experiment
To quickly proceed with this experiment, I started with pretty simple code. Collect the difference between the current time and time of the previous timer call, save all the values into an array, and I have everything I need for now. In the first place the code looked like this:
In all the tests I’ve done so far, there was one thing bothering me. Even when the browser was idling, there were almost no zero values in an array, but two digits were continuously repeating. For example: in Firefox (mac) these were 10 and 11. You can see that also also in the example above.
It was clear to me that these two values represent a kind of “baseline” for browser’s idling state. In Mozilla Developer Network (MDN) it’s described as a timeout clamping https://developer.mozilla.org/en/DOM/window.setTimeout ( at the bottom of the page ). Summarizing: clamping is the minimum amount of time between any interval or timer. I also tested different browsers in diferent OS’s ( Windows, Linux, OSX ) and almost none of them got zero values at the moment of idling. Besides that, these clamping values varied between all the browsers.
The funny thing about the timers clamping is that this interval is not just one static number, but two numbers, repeating in turn. These two numbers I called the “baseline”. Let’s look at some of them in different browsers.
Browser
“Baseline”
Firefox 3.5.11 ( osx )
10, 11
Safari 5.0 ( osx )
10, 11
Chrome 5.0.375 ( osx, win )
4, 5
IE 7.0 ( win )
15, 16
Opera ( win )
10, 11
Table: the baseline for different browsers
Despite the fact that the MDN claims that there is always a delay between timers, this was not the case. Sometimes the interval values were lower than the clamping interval, even dropping to zero value. Digging deeper sheds some light on this weird behavior. I’ve discovered that the dropped interval happened only at the moments of non idle state, when the browser was busy with really heavy execution flow. This gave me an idea that the timers are executing in two different cases.
Case one: The browser is idling. It periodically checks for the suitable timer/interval inside the timer’s and interval’s queue. This period is exactly the clamping moment, which is described in the MDN. At the moment when the browser finds an interval or a timer to be executed – fire.
Case two: Browser is executing JS code. Periodic checks are stopped to prevent timers and intervals being executed at the moment of other code execution. This means, the browser is waiting for an “opening” now. When the execution is finished, the browser starts checking the timers’ queue, without waiting for clamping offset. It controls if the execution of the timer was not far away in the past/future from the current moment and if not the browser executes it. This case also explains why my prototype code gave as a first value – zero. Because there was nothing else to execute and browser could pick up the scheduled timeout.
I do not claim, that this is actually what is happening, but by analyzing from the outside, it appeared to me so.
Tests with simple dump tool
Well, enough of raw data. Users need a GUI and I also needed some representation of the collected data. For this reason I made a first prototype version of a dumping tool. As an input it receives the array with values and as an output it produces some “very” simple graph like the one bellow.
This graph has two sates: “activity” and “no activity” state. They are represented by high level and low level of the bar, respectively. As you’ve noticed the high bar consists of red and black areas. In this way duration and type of the activity was represented.
Let’s start with the red part. The longer the red bar is, the longer the browser stays active. It becomes red, only when the activity interval is longer than the “baseline”. At the moment when the activity goes below the baseline, it becomes a small black stripe.
Because of the visual graph, you can analyze data much faster than with the raw array. Faster analysis, more intensive tests. More conclusions. And the first conclusion which I made was that, it is almost impossible to trace activity, if it is less than the clumping interval. But still, here comes the nice part, web pages nowadays are all heavily event driven, and even a small event often executes longer than the clumping interval. Take for example a typing event, resizing a window, etc. Typing event in an text-area triggered this so well, that I could easily see this in the graph.
Image : Firefox Typing activity
Image : Chrome Typing activity
Or, scrolling. I scrolled a couple of times and I think, this is quite fascinating to see, that graph shows you this four scrolls I made.
Image : Safari scroll activity
Last activity as an example is based on resizing of the Firefox window:
Image : Firefox resize activity
Another conclusion I made was that based on the examples you can see that the timers depend not only on the JavaScript execution of the code, but also on the internal parts of the browser, like moving of the window, or opening a new tab. So, keep this in mind 🙂
Besides all the graphs of event driven behavior, I also came across another interesting aspect in Firefox when it was “doing nothing” and checking the idle state. Firefox when idling still has some activity peeks. I also looked at Chrome and Safari, but they are all stable as statues. These browsers showed no sign of activity at all, in idle state. First, I thought that it’s just some crazy late running timer, but when I checked the Activity Monitor of OSX I found that there are also the same small peaks of the CPU usage for Firefox processor.
Image : Firefox small idle peaks
From here, I can draw two conclusions: 1. Firefox is really doing something all the time (which is reflected in the CPU usage) or 2. Firefox just has inaccurate timers.
More ?
I could not resist and not to build some kind of runtime activity monitor.
First thing which I did was to check the response of this monitor to the activity. The fastest way was to fire up native Activity Monitor of OSX and compare the peaks of both. It was a surprise to see peaks in the browser monitor first, and only after that in OSX. 🙂
Image : Firefox and Activity Monitor
Because runtime monitor gives you a global overview of the activity, it was really nice to play with it in a different browsers and compare how they react on different kinds of events/execution. It gave me an instant coverage of the places where browsers spend much time and of the places where they “fly”. For example, I used the test code like this
var arr = [];
for (var i=0;i<16099;i++) {
var div = document.createElement("div");
arr.push( div );
}
and I got these results :
image: Firefox (win)
image: IE6
image: Chrome (win)
Another thing which I noted is the way IE behaves. Its activity always stays at “zero” level when it’s idle, a really “silent” browser. Also in the image above you can see that IE gave only the activity of the JS execution, but nothing else. I assume that it has to do with the clamping interval. It has the highest interval between all the browsers, which means that the activity bellow 15ms will always stays invisible to us. Sad. At least we can track resize of the window, with ease 🙂
While I was busy with timers I found another interesting article about timers and intervals. I did a small experiment with that too and it appeared that the argument which Firefox passes to the timeout function is equal to the sum of the calculated interval + the baseline. It’s not always the same, but in most situations it is. I did not perform any further tests in other browsers, but if you are interested feel free to fill this gap.
This experiment gave me some interesting thoughts. This monitor can actually help you to look at the application from a different angle. It can show you the way the application performs and interacts with the browser. It can show you that the clicking on a button in one browser triggers a more complicated wave of the execution than in the other browsers. It helps to see you your web application as a whole piece and not as a bunch of separated code regions.
As usually, a playground is available for everyone who is interested in it :
Known issues: In Linux in Firefox calibration of the baseline sometimes is not working the first time, so you should recalibrate if it behaves strangely.
Summary : Do you still believe that there are only public, private and privileged members in JavaScript objects? With JavaScript, you never can be sure.
Lego principle
As I might have told you, I think that JavaScript is an amazing language. Even so, I would like to repeat it again. It is the ultimate language for me, and I hope it’s so for you. JavaScript is like a Lego constructor, depending on how you combine different parts, you might get a car, a house or maybe just a pile of crap. Your imagination defines the rules.
This time I’ve discovered some unbelievable combination. It allows you to create and use so called “protected” members in JavaScript. How do I define protected members in JavaScript? As a mixture of both, private and public members, which gives you the possibility to inherit, override and access private members without use of a privileged bridge. If you don’t know what these members are or have just forgotten them, here is a link to refresh your memory. For now, let’s look at an example below :
function Some(...) {
// defining private member
var value = 'value';
}
Some.prototype.getValue = function() {
return value;
};
Code : Scoping issue when adding methods to prototype
As you might have noticed, the code above is broken. Executing getValue function, will throw an exception, because the declaration of getValue is not in the same scope where value variable is declared. To make the code work, function getValue should be declared inside a constructor, hereby becoming a privileged member. This limitation makes it impossible to access the private variables outside the constructor.
The experiment I wrote does allow you to work with the private members outside the constructor, meaning you can add functions to the prototype and expect them to behave as if they are all in the same scope. Sounds cool, right? Actually, it doesn’t look half bad.
Code : Declaring class with protected member using prodec wrapper
In the example above there is one protected member _value. It is declared like other public members getValue and setValue, but it is accessed as a private member. Accessing _value variable in the SubSome class shows that the private scope, indeed, “can be” shared. I would like to put extra emphasis on the fact that the protected member is not accessible from outside the object, there is just NO possibility to do that. This means that someObj._value will be unavailable.
I used a declaration wrapper to hide all implementation details ( I love code separation ), but here is the approximately unwrapped code, which will help you to easily “diff” both listings:
The code above does the same thing as the first broken example, except that it also consists of SubSome inheritance. The SubSome inheritance is there to show you that you can access protected members declared in a superclass. Consider that the constructor is created by the Declare function and not like usually by function(){}. ( For those who need explanation about __proto__- here is link ) Note, that it’s also possible to share protected functions, not only variables, like in this example.
Internals
I guess you already have plenty of questions concerning the implementation of this experiment. I will not withhold the answers from you and will start explaining all the details right now. If you think that the code is the best source for explanation, I suggest you move at once to the last part of this article or visit a playground.
The first answer is with :). I was always wondering how private scope could be shared. We have the ability to share “this” scope, by saving it as variable, but we have no way to save a private scope and unroll it somewhere else. In context of “protected” members, we really need to save the private scope and apply it in different places. Even though we can’t do that “officially”, it’s possible to emulate this behavior by using with keyword. I’m sure everyone of you know what with is doing, but everyone is avoiding it, because it’s a bad coding practice. Anyhow, let’s leave prejudice out of this and look at the possibilities with brings us.
var obj = { zork : "Bork" }
with (obj) {
alert( zork );
}
Code : “With” Nature
This code, is doing exactly what is needed for emulating protected members. It allows you to access obj variables as if they are private variables. Looking from with perspective, the given obj can be seen as private scope. But let’s leave this part for a second and look at the next code.
var s = function(){
var zork = 'Bork';
return function() {
alert( zork );
}();
}
var fnc = s();
fnc(); // alerts Bork
Code : Closure nature
We know that internal closure bla will popup “Bork”, because of the nature of the closures. Now, I will combine both characteristics of closure and with and show what would happen if we create closure inside with. All the variables of obj will be available to the closure, meaning we could manipulate the scope :
var s = function(){
var obj = { zork : "Bork" }
with (obj) {
return function() {
alert( zork );
}();
}
}
var fnc = s();
fnc(); // alerts Bork;
Code : Combining “closure” with “with”
The result is the same, except now, we have our private scope coming from object and not from “var” declaration. This is really the main element of my experiment : Creation of the functions inside with and assigning them to the object. All thanks to the dynamic ability of JavaScript, which allows us to create and bind functions at runtime. Time to see how to apply this closure-with combination to create objects based on their prototype.
We know, that every constructor consists of a prototype object. This object contains almost the full definition of the object. I say almost, because functions can be created inside the constructor, which are not visible through the prototype. Even then, during object creation, it’s possible to walk through the prototype of the object and do things based on some requirements. For example : As you’ve already seen, protected members in my code start with an underscore. Based on this, we can collect all such members and place them inside our protected object. Later we can use this object inside with, so that the underscore members appear as private members.
function Some() {
var proto = Some.prototype;
this._protected = {};
for (var i in proto) {
if ( /^_/.test(i)) {
this._protected[i] = proto[i];
}
}
}
Code : Using protected object to emulate private scope
As you can see, we’ve made the first, yet the most important step of the “protected members” principle. However, there are still a number of issues. To start with, protected scope is available to the outside world, because it’s publicly defined. Further more, it is the requirement for the with keyword in every function where protected scope is presented. These issues leave an implementation footprint in the declaration of the class, which does not look very neat. Both issues are related, meaning that fixing them should be done at the same time.
First of all, we need the technique to hide our protected scope from the public “eyes”. A solution to this would be to use the nature of private members. The protected scope object should be defined as a private member. The only issue in this case that we will be facing the problem described above, namely inability to access private members outside the constructor. A fix for that would be to keep creation of the functions inside the constructor as well. The question is, how? Well, in the constructor we have access to any function and to the object itself, so if we could clone every function of Some object and reassign it, the desired behavior would be achieved.
To clone a function I have to resort to using another “evil” keyword – eval. Because every function exposes its body via toString(), we could evaluate it, at the places we need. Here is clone example :
var fnc = function() { alert('a') ; }
var member = '';
var clone;
clone = eval( "clone = " + fnc.toString() );
Code : Cloning function
Because eval remembers the scope in which it was evaluated ( has access to the member variable), a function can be cloned inside the with statement, having access to the protected scope object. Well, enough talk, it’s time to put all the building blocks together and see the result :
function Some() {
var proto = Some.prototype;
var protscope = {};
for (var i in proto) {
var member = proto[i];
if (typeof member == "function") {
with (protscope) { //adding protected scope
// cloning,
// cloned function receives automatically the scope correct scope
member = eval( "member = " + member.toString() );
}
}
// doing reassign
this[i] = member;
if ( /^_/.test(i)) {
protscope[i] = proto[i];
// removing protected variables from outside
this[i] = null;
}
}
}
Some.prototype._value = 'value';
Some.prototype.getValue = function() {
alert( _value );
}
Some.prototype.setValue = function(val) {
_value = val;
}
Code : Result of all the effort – creating protected members
If you are familiar with JavaScript the code should be fairly self explanatory. To get a better feeling for protected members, as I mentioned earlier,I’ve created a playground for you. I did not cover all parts of the declaration wrapper here, such as dealing with this keyword, using super classes, etc. If you are interested, grab the src-code and enjoy.
How much does it cost ?
What actually is a price of protected members? First of all – Speed. I haven’t performed any benchmarks, but by analyzing the code I can tell you that this emulation will run slower than normal creation of objects. Using with together with eval for every object member will stall the runtime. Secondly – memory consumption. Using a set of functions for every instance will eat up more memory in comparison to the prototype based instances.
Nevertheless, if the speed does not play a big role and you see advantages in using protected members you could adopt the src-code for your own needs.
Today I’ve found an interesting [link](http://blogs.msdn.com/b/ie/archive/2010/06/03/a-gpu-powered-html5-flickr-photo-viewer.aspx) in my RSS reader about IE progress in open-standards niche. Personally I think it’s really good that IE team puts so much effort to make IE a faster browser, a better browser and an HTML5 compatible browser. Finally, we – web developers, will be able to concentrate on web-applications and their functionality, instead of doing different dirty tricks to allow application to work in any browser.
Still I think we should ask our-selfs, when will this happen? When will web-developers be free of “hacking browser specific defacto’s “, when will they be able to have fun with latest web technologies? Actually, it’s a rhetorical question in this note. Despite the happiness of the fact that web-world moved, I have some sad thoughts.
Even if IE9 will be in one line with other open-standard browsers, it will not make it’s debut to all Windows platforms. IE9 does not run on Windows XP and requires at least Windows Vista with SP2. What does this means to us? Well, first of all, it means that, till the time all the Windows users switch to a successor of Windows XP, we will be binded to the good old HTML4. And I’m afraid it will not happen any time soon, at least for some of us. Officially Windows XP [stays](http://blog.marcliron.com/windows-xp/windows-xp-support-ends-in-2009-and-2014) in Extended support for the next four years, till 2014. Sorry for skepticism, but even if most of the users will move on to Windows Vista or Windows 7, there are organizations and people which will not make this jump.
Of course the situation is not dramatic, but it has some hidden and sad story. The percentage of AJAX driven applications growth and will grow even more. Different web-portals, CRM system and other web2.0 related applications are an entry point for thousands of people working in different organizations. As said, some of this organizations will not make a fast jump to Windows Vista/7. Meaning that web-developers will have to continue targeting IE(7,8) audience without HTML5 and other cool, fun things which are already included in IE9.
I know that Microsoft said “modern browser” needs a “modern operating system”, but it is still strange to see that other browser vendors can deal with Windows XP “non-modern operating system”, while Microsoft can’t. Can someone, please, explain?
My point of all this is : It’s all pretty cool and funky with IE9, but without being delivered to XP machines, it does not become new superior open-standard web-browser for me. Why? Cause it’s not a drop-in-replacement for IE family, but simply an extra browser to test in.
Recently I had an opportunity to deal with focus behavior in browsers, with tabindex attribute and other focus related stuff. When I was doing this work I came across interesting aspects of focus implementation in different browsers. This article is exactly about all these things. Tested browsers are IE (6,7,8), Firefox (linux-3.6.3) , Chrome 4.x, Safari 4.0.4 , Chromium(5.x linux), Opera 10.5.
# Stem
Before I start, let me remind you some basics about focus, tabIndex and user interaction.
As you know tabindex is used to specify focus order of the nodes and enable focus. I say, enable focus, because there are nodes which are not focusable by default, like div, span, table, etc, but can receive focus if tabindex is applied. Element receives focus when clicked by mouse (or touched on touch screens ) or when tab key is pressed. I’ve divided this article into two parts : “Interaction by tab-key” and “Interaction by click”. There has been a lot written about tab pressing interaction, so I will keep it briefly. The main part of this article will be “focused” on “focus with mouse click”.
For testing purpose I took different tabindex values as in example below :
<input type="text" value="tabindex is not here" />
<div>not tabindex</div>
<input type="text" tabindex="-1" value="tabindex is negative" />
<div tabindex="-1">tabindex is negative </div>
<div tabindex="0">zero or positive </div>
<input type="text" tabindex="0" value="positive or zero" />
<div tabindex="">omitted tabindex</div>
## Tab-stops
First, let’s refer to the w3c documentation to fully understand the tabIndex meaning in the tab-press story. The most important of all in that link is the tabIndex value. Which defines if node should be included in tab-press sequence – equal or greater than zero, or discarded from this sequence – negative value. If value is omitted it has different meanings based on node type. For non focusable elements it means nothing, while for inputs it will have effect like zeroed tabindex.
All the theoretical information is repeated, time to start and test the browsers’ implementation. The result of my titanic work of that test you can see below 🙂
Attribute in markup
Node is focused
input tabindex = “-1”
no
div tabindex = “-1”
no
div tabindex = “”
no
input tabindex = “0”
yes
div tabindex = “0”
yes
div (no tabindex)
no
input (no tabindex)
yes
Table: Node is focusable when performing tab-press
Tab-stop sequence in all browsers is exactly the way it’s described by W3C. Focus is placed only on nodes which have tabindex equal or greater than zero. Default nodes like input, do not need any tabindex to be included in tab-stop sequence. Though if tabindex is negative, all browsers skip this node from tab sequence. Well, it’s all clear. Nothing more to say about this subject, so let’s move to the next stage.
## To click or not to click
This test was a little bit controversial for me. From the user perspective – focused node is the node which gets outlined or selected by some other kind of visual selection ( border dotted, blue, etc). From us, developers perspective, focused node is the node which receives onfocus event and it does not matter whether focus is visible or not.
Of course, end-user is the person who will work with an application. We have to originate from his point of view, which means that visual style is everything. If node is not visually selected, it does not exists as focused element for user. That’s why my test was aimed at end-user experience – “Hey, when I click nothing happens…it’s broken” – or something like that.
Because input elements can always receive focus ( when enabled ), I did not include them in the results below:
markup attribute
Firefox
IE
WebKit *
Opera
div tabindex = “-1”
yes
no
yes
no
div tabindex = “0”
yes
yes**
yes
no
div tabindex = “”
yes
no
no
no
div (no tabindex)
no
no
no
no
Table: Node is focusable when clicking it
* Safari and Chrome both uses Webkit render engine and have the same results
** IE bug
That’s sorrowful. There are no identical browsers which have the same focus implementation, except Safari and Chrome (I assume only because they both use WebKit engine).
One of the first things which came to my mind, is that, it’s still not possible to rely on the browser’s default behavior. One browser will make visual style, while other will not. It could be okey, if we were working only with positive or zeroed tabindex. But it is 2010 and ajax applications are sometimes more complex than desktop’s are, it’s not possible to pretend that no one uses negative values for tabindex. So… such a big difference in outline implementation left us not a big choice. If you want to have visual accent on focused nodes, use your own CSS classes, like most of us do for the :hover elements or stop using negative tabindex at all.
Beside all of that weird stuff I’ve also noticed two strange aspects in Firefox and MS Internet Explorer.
It appears that only Firefox is the browser which shows outlined node when tabindex is presented as attribute but value is omitted. I do not know, if it was a feature or not, but keep in mind, that
node.setAttribute("tabindex","");
will make node focusable by click.
Another interesting issue is non focusable nodes in IE. It seems that nodes like div, which have tabindex zero or greater than zero do not receive focus by click. Yet, they will start receiving click focus if such node has been focused by tab-press. After node has been focused once (by tab), it will start receiving focus by click (even if you reload the page). Though, if you delete browser’s cache and open the same page again, node becomes non focusable back. Really weird… If interested – Try it yourself.
UPDATE: Tested in IE6/7 in mac (with wine) and the bug is not possible to reproduce.
## To dispatch or not to dispatch
After end-user test there is still one open item. Ajax applications are event-driven, so how does tabindex influence “onfocus” event? Does it get dispatched or do we stay unaware like usual users do? Well, check the results :
Attribute in markup
Firefox
IE
WebKit *
Opera
div tabindex = “-1”
yes
yes
yes
yes
div tabindex = “0”
yes
yes
yes
yes
div tabindex = “”
yes
no
no
no
div (no tabindex)
no
no
no
no
Table: Node fires onfocus event
What do we have here? It appears that even if node is not visually outlined, it still fires an onfocus event. All of the major browsers behave the same, except that Firefox keeps receiving focus with omitted tabindex value.
## Detecting focusable node through JavaScript
To say frankly, I’m a bit meticulous person, I always try to understand internal part of the subject. In situation with focusable nodes, I was wandering what information does browser expose to the JavaScript environment, depending on the tabIndex and node type (like input and div). As an challenge I decided to write code which could detect any focusable element, despite the focus visualization. Even that such functionality has not much to do with daily work, but maybe for some of you it will be useful.
Actually defining if node is focusable or not does not look difficult. Node with negative or positive value is focusable by click ( at least can receive onfocus event ). Node with positive or zero is focusable by tab-press. In theory the only left thing is to get appropriate tabindex value of the node and check if node is focusable by default. Easy… 🙂
At that time I knew, that getting tabindex value can be done in two different ways. First by using property node.tabIndex, described at MSDN. Or by using node.getAttribute("tabindex") function.
I used both functions to see the differences and to decide which one I need. In a result table below I grouped all browsers, except IE, due to the fact that IE gives totally other results than the rest.
Attribute in markup
tabIndex
getAttribute
tabIndex ( IE )
getAttribute ( IE )
tabindex = “-1”
-1
-1
-1
-1
tabindex = “”
-1
“”
0
0
tabindex = “0”
0
0
0
0
div (no tabindex)
-1
null
0
0
input (no tabindex)
0
null
0
0
Table: Different approaches in getting tabIndex value
Because of these zeros in IE column, first I will analyse “all” browsers and then I will return to IE.
When looking at the results I can mention a number of positive aspects. First of all it’s really nice that browsers respect markup and give the correct value via getAttribute function meaning that getAttribute is trustable, but in IE. The second valuable aspect is that browsers return positive or zero value if node is focusable via tab-press even if no tabindex is specified. You can see that in “input” node column, which does not have any tabindex, but still tabIndex returns 0. This indicates, that browsers even help us to identify focusable nodes.
Yet, there is one little pitfall. What first hits the eye is the tabIndex which is -1. Browsers return -1 in three different cases when querying div :
When tabindex is not specified
When tabindex is specified as -1
When tabindex is omitted
You may ask, why is it a pitfall, browsers return -1 to any node which is not inside tab-press sequence? Fair enough. But please do not forget, detection code should identify all focusable nodes, which includes nodes focusable by mouse click.
Gathering all information together it become clear for me that through all the good things tabIndex property is doing for developers, I still have to use both approaches.
Instead of limiting myself to the isFocusable( node ) function, I decided to write generic getTabIndex( node ) function. This function would return correct tabindex value only if node is focusable ( dispatches onfocus event). Furthermore knowing IE issue with tabIndex/tabindex, I can also include the workaround to retrieve correct tabIndex for MSIE.
For now, based on the getAttribute and tabIndex, getTabIndex will looks like this :
window.getIndex = function (node) {
var index = node.tabIndex;
if (isIE) {
// later
} else {
if (index == -1) {
var attr = node.getAttribute("tabindex");
if (attr == null || (attr == '' && !isFirefox )){
return null;
}
}
}
return index;
}
I think the code is self explaining and I do not have to dive into the explanation. Btw, as you can see, I’ve included check for firefox (let’s respect his own small weirdness) 🙂
## IE tabIndex retrieval
Now, lets’ look to the Internet Explorer results. IE returns zero value in a lot of different cases. The only case when IE returns correct value is when tabIndex is specified on node. So how can we determinate if node is focusable or not?
First of all we should get real value from markup and because getAttribute(“tabindex”) is not working, it’s time to find something different. The answer hides inside “attributes” property of the node. It’s possible to query attribute of the node by using node.attributes.tabIndex which will return an AttributeNode object. Though this node in most cases has value of 0, AttributeNode also consists of “specified” property, which show the real state of markup.
Here is the short IE getTabIndexAttributeValue function based on the info :
function getTabIndexAttributeValue(node) {
var ti = node.attributes.tabIndex;
return ti.specified ? ti.value : null;
}
Yet, there is another problem with IE tabIndex. As I explained above, other browsers return zero also for nodes, which are focusable by default, like input, textarea, etc. IE also does that. However it does that also for nodes which do not receive focus by default, for example for div (and even more weird for <BR/> ) :O. Solution? Take names of nodes which are focusable by default and match them with given node. These names are listed in the spcecs : a, BODY, button, frame, iframe, img, input, isIndex, object, select, textarea
Well, here is the final version of getTabIndex :
window.getIndex = function (node) {
var index = node.tabIndex;
if (isIE) {
// late
var tnode = node.attributes.tabIndex.specified;
if (!tnode) {
var map = { a:true, body:true, button:true,
frame:true, iframe:true, img:true,
input:true, isindex: true, object: true,
select: true, textarea: true
};
var nodeName = node.nodeName.toLowerCase();
return (map[nodeName]) ? 0 : null ;
}
} else {
if (index == -1) {
var attr = node.getAttribute("tabindex");
if (attr == null || (attr == '' && !isFirefox )){
return null;
}
}
}
return index;
}
# Suffix
I hope you found also some useful information in this note, like I did, when I was testing. And one of the things for me was : IMHO : If you need visually selected focused elements, do not rely on browsers’ implementation. Just get rid of the active border and use your own highlighting mechanism.
Info: I’ve posted this javascript quiz almost two years ago. Unfortunately I’ve got some problems with host and this quiz was not available anymore. I still like this challenge, that’s why I decided to repost it again.
Introduction
I always enjoy programming JavaScript, it always brings me some new and interesting puzzles. I was explaining functions in JS to a friend and got realized that it’s a really great language with its flexibility, closures, anonymous functions, first-class functions etc. Even the stupid idea that you can write a function by calling it an unlimited number of times is simply amazing.
Example:
fnc()()()()()()()()();
Challenge
Further thinking gave me the idea that it would be nice to have this function do something more weird and confusing. This useless function should give as the output the number of times it has been called (for example in alert box). The challenge of this puzzle is that it must give output only at the end of the execution, with the last call.
That means that code like that fnc()()()()()()() MUST show one alert box with text “Fnc called 7 times”.
After some experiments I found a solution for this puzzle and I figured that you might also want to challenge yourself by finding out the way it can be done. So, I propose everyone to post their solutions in the comments.
Solution
Try it live :
(Execute)
If you decided that it’s enough for you to break your head with this puzzle, you can always check my solution (in html code 🙂 ).
I hope you liked my idea, and also get enthusiastic, like I did, when I was searching for the answer.
The original entry was posted on Saturday, July 12th, 2008 at 4:12 pm
“If you don’t like ‘this’, try Zet.js” (c) M.Nemisj
Plot: This article is about an experiment of avoiding “this” and “new” keywords in JavaScript and about the results of it.
Harmful “new” keyword and replacement for that
There are different debates flying around the internet about the safety of using “new” keyword in JavaScript. It’s all started when Douglas Crockfordstated that “new” keyword can be harmful and that he doesn’t use it any more in his code. In replacement for that Douglas Crockford proposed factory functions. In public they also called sometimes Function OOP or Module pattern.
I really like dynamic nature of JavaScript, so this solution excited me. The fact that in JavaScript there is always something new to found or new to learn brings me esteem to the JavaScript language.
The only thing which I considered to be not elegant in this solution, was the inheritance paradigm. It gave me the feeling that code is too “custom”, too “hardcoded”. To fully understand what I mean, you should see it yourself:
This is how normal factory function looks like :
var User = function(){
var privatMethod = function(){
alert('hello');
}
return {
sayHello : function(){
privateMethod();
this.done = true;
}
}
}
In the code above we created declaration of the User class.
Creation of the new User instance is possible without “new” keyword:
var user1 = User();
var user2 = User();
Now, let’s imagine that we would like to create sub-class of the User. Using inheritance in this pattern is not trivial when it concerns methods overriding, but it still can be achieved by the following code:
var SubUser = function(){
var user = User();
var oldMethod = user.sayHello;
user.sayHello = function(){
oldMethod.apply(user, arguments);
user.done = false;
}
return user;
}
As you can see, the declaration of subclass differs from its super-class. In my opinion this makes code less readable, and more fragile. Moreover there is too much logic involved inside the declaration of the class itself( like “apply” logic or keeping track of instance scope), so code does not become self-expressing to the reader.
That’s why my idea was to make library which would make some unified structure for Class declaration in Functional OOP style with inheritance support. There are some libraries which support Functional OOP style, but all of them, which I’ve seen are using “new” keyword. Then I’ve started with experiments and ended up with the library which is full of experiments or simply Zet.js. About all of the interesting points and experiments you can read bellow in this post.
First seeing, then believing
Before reading all this text bellow, I guess it can be interesting to see how class declaration with Zet.js looks like. Let’s redeclare SubUser :
Working with different people, reading articles on the net, brings me to the idea, that “this” keyword is one of the most complex concepts in the JavaScript. Especially when new developers find out that “this” can point to different scopes. Such instability of “this” keyword brings a lot of confusion, especially to the people, who came from static languages like Java or C#.
First and most valuable aspect of Zet.js is, that it provides a solution to stop dealing with cumbersome “this” variable.
There are different ways in which “this” variable can be substituted. I think, it’s essential to know global/important cases, when it can occur. People, who are not interested in causalities can skip this chapter and start reading about implementation details.
As I told, by knowing most used cases it’s much more easier to identify the generic solution. One of the most important cases in my list is accessing of “this” variable from within anonymous function. Let’s look at standard non working example below.
Since “this” variable inside anonymous function points to the global scope, the code will throw error, because someFunction is undefined. I guess, this situation happened to most of us, including me. At the time when I only started with JavaScript, my attempt to fix this was to assign function to the variable and then execute it.
Perhaps, code looks logic and normal, and in some situations it may work, but it’s still not working code. The problem is that as soon as someFunction will try to access “this” variable inside of it, code will break. The reason stays the same. Function someFunction is called as anonymous, so “this” variable will point to the global scope.
To help JavaScript developers, most frameworks and libraries offers helping functions, like “bind” in jQuery or “hitch” in Dojo to use. They help to keep correct scope at the moment of the execution.
Although we have now support from libraries, there are another two cases which can lead to scope substitution. Take notice that one of them is only valid, if instances are created with “new” keyword.
1. Instantiate class without *"new"* keyword.
2. Using apply or call API calls
I will not explain first one, since the Functional OOP prevents this kind of bugs by default, but let’s check the second one.
Intentionally substitute scope can be done through call or apply API calls. By using one of this it’s possible to make “this” aim at any JavaScript object. In some situations this can be useful (hitch and bind are based on this), but also it can lead to unpredictable results.
After all this theory material it’s time to see what Zet.js proposes.
To protect “this” variable from pointing it to some-where-we-do-not-know, Zet.js prevents usage of it. Instead Zet.js forces developers to use “that” variable. This variable is available from the begin of the instance life-cycle and always points to the correct scope.
JavaScript developers knows, that “this” variable can be assigned to anything (caching it). Zet.js passes “that” to the factory function at the moment of execution and it stays in the private scope of the instance. Because private scope is always available to the body of the instance, developer always have the correct value of “this” in hands.
I also want to notice that, by having such manner of declaring classes, all the private functions inside the class also automatically have the scope to the object instance. This means, that there is no more need in doing extra work like privateFunction.call(this); to access public variables or functions from the private scope.
As I mentioned already class declarator passes “that” to defineBody factory function, which points already to newly created object.
Strange Zet.public function
I guess you’ve already noticed strange Zet.public declaration in defineBody factory. This is another experiment of mine. It is not usual to see such way of declaring things, but it is made to create logical split between functions, which are included for private purpose and public functions. Further it brings totally no functionality into the object, pure for experiment.
In case you think, this is REALLY useless, Zet.js supports also return statement as normal Functional OOP declaration does.
Except that in such situation “that” variable should be used instead of “this”.
Functional OOP/Module pattern pitfall.
One of the strong arguments for people not to use Functional OOP is the fact that the instanceof functionality is not working correctly. Because factory function creates every time unique object instanceof will always return false.
I’ve seen some solutions to fix this, but they remain using “new” keyword internally in the declarator itself. As I told already before, Zet.js is truly “newless”, so I could not use any of the solutions which I’ve seen.
Instead Zet.js extend every instance of the object with own instanceOf method. Passing class constructor to this function will return false or true depending on the constructor which belongs to this object or to its superclass. Thus, expressions bellow will return true.
To make instanceOf more universal, I’ve included global instanceOf method API. Which works with normal objects, Zet objects and with fixed instanceof String case :
Yes, besides strange .public syntax, forced “that” usage and other experimental stuff, Zet.js also has some “normal” facilities, like :
Support for Inheritance
Separate “initialize” call
Declaring classes through Namespaces
Simple loggin facilities
Inner constructor function
CommonJS Modules API support
This article is big enough, so I will not describe here in details all of the listed things. If you are interested you can find all the explanation inside README on a github.
Update : As noted by Tim Caswell it’s better to name your factory functions with a “new” prefix to indicate that such constructor should be called without new keyword, for example :
var person = newPerson();
Also it’s important to understand that each instance of such factory has a big impact on the memory, since it consists of own copy of all the functions of the class.
