Re: Find Element Position

On Feb 20, 1:48 am, David Mark <dmark.cins...@xxxxxxxxx> wrote:
On Feb 20, 2:40 am, dhtml <dhtmlkitc...@xxxxxxxxx> wrote:

David Mark wrote:
On Feb 19, 3:40 pm, dhtml <dhtmlkitc...@xxxxxxxxx> wrote:
On Feb 19, 2:41 am, David Mark <dmark.cins...@xxxxxxxxx> wrote:

On Feb 19, 4:15 am, dhtml <dhtmlkitc...@xxxxxxxxx> wrote:

On Feb 18, 6:51 pm, David Mark <dmark.cins...@xxxxxxxxx> wrote:

On Feb 18, 8:05 pm, dhtml <dhtmlkitc...@xxxxxxxxx> wrote:

On Feb 17, 9:01 pm, David Mark <dmark.cins...@xxxxxxxxx> wrote:

On Feb 17, 9:01 pm, David Mark <dmark.cins...@xxxxxxxxx> wrote:

On Feb 17, 5:09 pm, dhtml <dhtmlkitc...@xxxxxxxxx> wrote:

[snip about offsetParent]


[snip about rying to get the position of an element in abstract view][
[snip]


[snip about several feature tests req'd to calc the viewport width in
quirks mode]

[snip about detecting viewport dimensions]

[snip about compatMode]


<snip about my incomplete example>

What does the computed border width evaluate to? I suppose it doesn't
matter much as I use clientLeft/Top when available, which are always
going to be rounded in whatever way the browser sees fit. Oh well,
none of this is going to be perfect for every possible layout.

The border width of em gets based on the fontSize, but gets rounded.

Oh well.
Opera seems to have problems calculating ems.

http://dhtmlkitchen.com/ape/test/tests/dom/style-f-test.html

testGetComputedStyle : function() {
var Assert = YAHOO.util.Assert;
var ArrayAssert = YAHOO.util.ArrayAssert;
var dom = APE.dom;

var testNode = document.getElementById( "testNode" );
var rule = this.data.rule;
rule.style.fontSize = "12px";
rule.style.fontFamily="fantasy";
rule.style.padding = "6em";
rule.style.height = "1000em";

var foundFontSize = dom.getStyle(testNode, "fontSize" );
var foundPadding = dom.getStyle(testNode, "paddingBottom" );
var foundHeight = dom.getStyle(testNode, "height" );

Assert.areEqual( "12px", foundFontSize );
//Assert.areEqual( (12 * 6) + "px", foundPadding );
Assert.areEqual( "12000px", foundHeight,
"height was set in em, and was either \nreturned wrong or
miscalc'd by the browser." );

},

FAIL testGetComputedStyle: height was set in em, and was either
returned wrong or miscalc'd by the browser. Expected: 12000px (string)
Actual:12144px (string)


Using currentStyle, well, it's completely f'd in Opera.
currentStyle.opacity => always 1
letterSpacing => 1, when it should be 0
currentStyle.fontSize => floor(expected) + unit.


Opera 9.25:

javascript:void(document.body.style.fontSize ='.9em');
javascript:alert(document.body.currentStyle.fontSize );

result:

"0em"

This one's really weird:
javascript:alert(document.getElementsByTagName("head")
[0].currentStyle.fontSize);

currentStyle is broken in Opera.

Opera is worse at Math than I am.

When using larger numbers for font size, it becomes apparent that
there's also some internal miscalcuation. The numbers aren't off by 1.
They're off by a lot.

I see.

When cumulatively adding clientLeft/Top the rounded pixelValues are
added up, resulting in a much more skewed result.

This sounds like a good case for using gCS in the offset position
function, ignoring clientLeft/Top. I think I will do that.

That is true.

[snip about IE requiring 100 based fontWeights]

Did you mean fontWeight? And I did not know you could have non-
integer zIndex values. I can't imagine a use for them though.

In doing animation transitions, just use floats, but I guess it's nota
problem anyway.

I don't follow you there.

floating point numbers for zIndex. I guess it's nota prob.

Regardless, I have no control over what
sort of element is transitioned. I endeavored to support everything
for all of the effects. For instance, using the slide effect (the one
that Prototype fakes by requiring an extra container element),
positions a static element in its initialization.

Here's a really weird one. I have a "grow" effect that can optionally
size the font of the element. Using my em-based layout (which was my
first stab at aligning to a baseline grid), I found that setting
inline font sizes to their cascaded or computed values would make the
fonts change in size (which makes no sense to me) and this only
happened at certain text size settings (e.g. larger, smaller,
smallest, but not medium.) However, if I set the inline font size
style to what I know is the cascaded value before I run the animation,
then all is well (the fonts have already jumped in size.)

I did change taht example I showed you to use em for fonts. It's
probably your TV.

[snip]



The separate CSS selector test page is a hacked version of the
MooTools "SlickSpeed" test page and is semi-automatic (you click one
button to run all of the tests.) Check it out when you a get a
chance. Testing here, mine wins every time overall and wins most of
the individual tests as well. As an aside, Prototype is by far the
slowest for virtually every test. I am sure if I add Ext to the mix I
will lose in browsers that don't support XPath (and Safari 3 where I
disable XPath due to a failed feature test.) Adding the Function
constructor trick that Peter demonstrated in the tabbed pane sample
will likely rectify that.

I missed that one.

[animation]

FF is the worst. And what is the deal with that stupid blink when
setting opacity to 1?

I saw the blink in old 1.x, pre 1.5. I thought it got fixed. I haven't
seen it. I don't like having such workarounds either.

There's not test for "did blink".

I'd be inclined to let it just blink. This kind of browser bug is
unacceptable, and especially if it's a regression. If a browser cannot
correctly support a feature, it should not support it in a broken way.
This seems broken to me.

LOL. I like pretty fonts as much as the next guy. But seriously, my
primary monitor is an ancient 60" TV (S-VHS connection) and Safari's
rendering is much easier on the eyes.

Weird.

[snip]

That's why I have dumb tests for things like Assert.isTypeof("string",
el.toString()).

I remember staying at work late one night because toString didn't work
on a certain library -- threw an error, actually. I didn't call
toString, but other code in the library did.

Didn't work in what way?

They had a to string that had a ReferenceError (they changed the API)

toString : function() {
return this.noexistant.prop;
}

The author probably just put in toString for debugging but then
changed the design. Being javascript, there was no compile-time error.
The design was also a contributing factor in that one. A 3-4 long
inheritance chain, which was nicely diagrammed on the libary's website
in *reverse* UML (the graphical arrows -- which were quite attractive
-- were all backwards). Anyway, the code worked fine and went to
production. Then toString didn't work in my case. The author of the
script had to leave early, but I stayed late, trying to figure out
what was wrong.

So the point is that toString was not mission critical, was not
tested, and actually caused a problem (related to a complicated
design). I'm not saying toString is bad.

I didn't follow that, but I don't use toString on elements anyway.


They had a toString that was broken. The problem with not testing is
it invites problems to creep in to less common execution paths.

I use toString a lot. It makes debugging easier (for me).

I don't have a good partial degradation strategy. If i could test more
browsers, I degrade to acceptable levels. This takes a lot more time,
from what I remember about the old version 4 browsers, it was a lot of
work to do small things. It is definitely the right approach and
attitude for web scripting.

<snip>

getComputedStyle is (or should be) a pixel value.

It is indeed.

Webkit returns 'auto' when margin: auto and left is undeclared.http://www.dhtmlkitchen.com/test/bug/getComputedStyle.html

My gCS wrapper will never return "auto", but instead returns null.

I would probably return an empty string. to avoid having to write:

if(val != null && val != "")

But when would the computed style ever be an empty string? I know
cases where it can be null (e.g. display:none makes all of them null
in some browsers), but an empty string?

A lot of times.

LOL. I was blinded by my own abstractions. I convert them to null.



Safari returns '' for clip

That makes sense as clip is shorthand.

Mozilla does too, for any shorthand prop, like border. Mozilla at
first only implemented a few styles.

Computed shorthand styles sounds like a contradiction in terms to me.
I wouldn't rely on being able to query styles like that.



if(s != null && s.split(" "))

You could turn it around and use /\s/.exec(s), I suppose.

What are you doing there?



I like String methods to return strings. I like my code to be safe
enough for me to use on a bad day, and hopefully safe enough for
others, too.

Generally, I prefer that they return strings only for valid results
and null otherwise. Some functions are allowed to return empty
strings and some are not. The gCS wrapper is one that is not.



Its more annoying with arrays.

var m = s.match(exp);
if(m && m[0])
v = m[0];

I would rather have had match return an empty array.

I don't follow what you are doing with these last two examples.


using String.prototype.match.

match returns an array, or null if the array would be empty.

I'd rather have an empty array than have to do a null check.

[snip]


About build... When you've got time, I'd like to ask you about YUI
compressor. (we can kill this thread) I'd really like to hear your
build process (in a new thread, of course).

Okay. In a nutshell, the YUI compressor is outstanding. It has never
let me down.

I'm using it, but I've got to get it hooked into ANT and automate the
process.

[snip]


<body>
<div>
<p>..parsing...
appendChild called -> <div/>

You lost me there.

1. polling for document.body every 60ms
2. document.body is evaluated as true in our poll, but after some of
it's content has been parsed.
3. call body.appendChild
4. what will IE do?

IE6 will throw the dreaded "operation aborted" error AFAIK. You
really need to change that. See the attachDocumentReadyListener
ticket in CWR.

Grabbing documentElement.innerHTML every 10ms seems pretty
inefficient. That's a lot of large strings. I've got a
ContentLoadAdapter.

Be very afraid. There's no catastrophe (short of ill-formed XHTML)
that can compare to "operation aborted."

I remember now, yeah.

BTW, do you know in what way gBOF fails in embedded Mozilla-based
browsers? An exception? If so, I need to get rid of it ASAP.

All I know is what I read in that bugzilla report. I would guess that
if it's available but doesn't work, it would return a Null Object (all
0's), but then, it might return null or throw an Error. You could try
a capability detection test to see if it works.

getBoxObjectFor = (function(){
// create element,
// do some assertions.
// return supported.
})();

Check the buzilla rep't to see if it throws an error or how it fails.
The reporter had strong words about not using it.

Garrett
.

Loading