Inferring the Locale text direction with Javascript

Here’s a hack to detect which is the locale text direction (e.g. left-to-right for English or right-to-left for Hebrew) using JavaScript:

 * Detects locale text direction...
 * @return {String} "ltr" or "rtl"
function detectTextDir() {
   var container = document.createElement("p"); = "0 0 0 0"; = "0 0 0 0";
    // = "start"; // If CSS 3+ = ""; // Explicitly override text align that might be assigned via style sheets
    var span = document.createElement("span");
    span.innerHTML = "X";
    // LTR if text position is nearer left of container, RTL if text position is nearer right of container
    var localeDirection = span.offsetLeft < (container.offsetWidth - (span.offsetLeft + span.offsetWidth)) ?
        "ltr" : 

    return localeDirection;

A limitation is that it doesn’t work if there is a style sheet present which explicitly assigns a text-align value other than “start” for paragraphs directly in the document body. You could probably tweak the idea to use something more obscure like an address block to reduce chances of this happening.

Webkit clipboard security hole

While on a search for accessing the System clipboard via JavaScript, it seems I discovered a security hole in Webkit.
Network Security
Usually system clipboard access is restricted in clipboard events like oncopy and onpaste. However I found that you can set the system clipboard in any context (e.g. a timer event).
Continue reading

Accessing the System Clipboard with JavaScript – A Holy Grail?

I am developing an API written in JavaScript for a project which requires the ability to copy data to, and retrieve data from, a clipboard within a web browser. A simple/common problem definition – but due to tight browser security, finding a solution is a bit of a nightmare. This article outlines and discusses a number of approaches for implementing a clipboard feature into your JavaScript applications.

Continue reading

Retrieving Inherited CSS Styles with DOM

If you need to get a CSS style from an element in a document, you cannot just test the style of the element directly. That is: won’t work. Take this example:

<p style="white-space:pre">
  Hello world - <b> A  B  C  D </b>

The immediate white space style of the bold element in the DOM will be normal (default for bold element). However the style is actually pre, since it inherits it from the paragraph ancestor element.
Continue reading

Allowing events to fall-through div regions

I have been on a mammoth quest to discover how to redirect events from a large transparent div (covering a whole web page) to elements below the div region. At this point I have not found a solution. However progress was made and such info could save a hell of a lot of time for some people who share such a quest!

First thing I achieved was to capture all mouse events on the transparent div and discover the underlying elements at which the mouse was over. This was achievable using object.elementFromPoint(x,y). It seems to be supported by both Mozilla and IE. I’m not sure about others.  I used Dojo for cross-browser event handling. Before elementFromPoint can be used you must somehow hide the div then afterwards show it again, you could adjust the style or remove/append the actual node. NB: this does not introduce flickering. Here is example code: = "hidden";
var targetElement = document.elementFromPoint(evt.clientX, evt.clientY); = "visible";

Note that when capture mouse events, capture all DOM and browser-specific events (e.g. DND events).

At this point we want to re-fabricate the event as if it were to be sent to targetElement. This is where I have racked my brains for the last day 😮  Originally I redirected the event by using targetElement.dispatchEvent or targetElement.fireEvent (depending on the browser support), however the results are very temperamental: sometimes things work and most times the event does not do anything! Very frustrating. I read here: ( that firing “fake” events so not cause the default action to occur due to security reasons etc. So now this approach is looking grim. It makes me wonder though about how on earth sometimes the default actions execute.

One of my theories is that it has to do with threading and events. For example, maybe the default action will only execute if the div is still invisible (or non-existent) at the time of the events execution. Therefore the div’s visible property must be set to “visible” after the default action (supposedly) occurs. I ran some tests and this theory does seem to stand. Plus event threading support with JavaScript is virtually non-existent.

If worst comes to worse and no elegant solution can be found, I may have to resort into implementing the “default action” in JavaScript which may be a nightmare!