Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

The Wizard of Oz: Feb 7, 2004

I need to determine what the input focus is without touching any elements directly - so no onfocus injection. I also need to do this within an iframe which has arbitrary contents.

The only method I've been able to figure out so far is to inject a style element that has such a condition as:

code:

input:focus { unused: 666; }

Where unused can be anything that's not relevant to the control but is present. Then I window.getComputedStyle anything that seems appropriate and test for my property.

This works and should be portable but I wouldn't want to run it on a massive HTML file or one containing a huge number of focusable elements. AFAICT there is no standard solution. I've found the one that should be in Gecko, and now I mostly want to know if there's one for WebKit.

FateFree posted:

I am a java developer primarily, and my knowledge of javascript is pretty limited. I've come into a requirement for a project that takes a giant chunk of html (mostly text, a few bold, italic, or underline tags, and images are possible), and instead of displaying it in one page with a long scrollbar, the requirement is to paginate it so that the viewers can click a navigation bar on the bottom (first, next, page 1, 2, 3, .. 10, last etc).

Initially, this requirement was only for a chunk of text, so server side my java code would count characters and lines and line breaks, and break the text into several page objects, which were easy to paginate. However it never felt right because it seemed like this was something a browser was meant to do, and now that html is possible, I can't run the same algorithm because I can't compute the size of the images and i'd have to strip out all the tags and whatnot.

Can you think of a way this may be accomplished with javascript, or should I try to do it with java still? One thing that may be an issue is if the browser will know when to break apart the text in order to paginate it correctly. Any ideas?

You don't need to count characters/lines, just walk through at the document.body level testing node.getBoundingClientRect(). Once that exceeds a page, make a note to cut the document at that point and continue. When you've gathered all the pages together, blank the document if it's displayed, transfer nodes into your pages, and then show the first page.

This won't work for everything, and there can't be any general rule because the page could be dynamic or use CSS to break position order. But it'd be easy enough to chase the rabbit down the hole far enough to work for whatever it is you need.

That leads to a second question, is there any god-damned reason to be using offsetLeft/offsetTop/offsetParent when getBoundingClientRect does the same thing without a loop? I only started doing it because I had a page in Gecko flat-out fail when I tried the offset method, and AFAICT it always produces the correct result.

# ¿ Apr 14, 2009 23:35

Adbot: ADBOT LOVES YOU

# ¿ May 8, 2024 00:36

The Wizard of Oz: Feb 7, 2004

Nigglypuff posted:

getBoundingClientRect hasn't always been available in Gecko, iirc. But as long as it's there, you should definitely use it.

You're right, it's Firefox 3, and a port of one of IE's handful of good ideas. So no WebKit. I did find a page which covers all the edge conditions HERE.

# ¿ Apr 15, 2009 01:40

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.