Getting computed/current style
in [JavaScript]
|
From: David Mark on 20 Mar 2010 14:34 Garrett Smith wrote: > Eric Bednarz wrote: >> Garrett Smith <dhtmlkitchen(a)gmail.com> writes: >> >>> Eric Bednarz wrote: >> >>>> Since I never attempted to retrieve offset values of relatively >>>> positioned elements by script, […] >> >>> "Offset" values and top/left style values are different >>> things. >> >> Ah. >> >>> Offset", to me, is about the badly defined and highly >>> inconsistent "offsetTop", "offsetLeft", and "offsetParent". >> >> “Offset”, to CSS 2.1, is about section 9.3.2. >> > > "offset" is a prefix for three nasty properties and one good property. > The nasties are: offsetLeft, offsetTop, and offsetParent. The one good > one is offsetWidth. Are you abstaining on offsetHeight? And BTW, the nasties can be very useful if you know how to train them. See the final resolution of this thread. ;) > > Those are defined in CSSOM Views, and, depending on the version of that > document, you'll get completely different definitions for the bad ones. They are written about in there, but that was after the fact, so whatever is written is just trying to explain what has already happened. It won't change reality retroactively and it remains to be seen if that _draft_ will ever be finished and formally approved. > The implementations of IE 6-8 are all different. Which doesn't matter a whit for the case at hand. > Likely IE9 will be > different again. And that won't matter either. Basic math is unassailable. > Of course other browsers all vary on what they do for > those properties as well. Not that much. In many contexts, the results are quite predictable (even when not using equations that factor out the discrepancies). I've managed to do some truly useful things with these properties over the years, but all you seem to do is complain about them and cite daffy W3C drafts. > > If you're trying to obtain element coordinates, relative to the root, > method getBoundingClientRect (also specified in CSSOM Views) does that. Fairly well. Of course obtaining such coordinates relative to the root is ill-advised and virtually always unnecessary (consider that fact at the design stage). > >>>> <http://bednarz.nl/tmp/relative/> >> >> (Unfortunately I had to move that:) >> >> <http://bednarz.nl/sandbox/js/relative/> >> >>> What I do not understand is the "expected" column. What are the >>> expectations coming from? >> >> See above; is the specification (candidate) an unreasonable point of >> reference? >> >>>> - jQuery does nothing more than returning the wrong results provided >>>> by the >>>> getComputedStyle/currentStyle branch >>> To retrieve element coordinate offsets with jQuery, >> >> Anybody who understands the difference between relative and absolute >> positioning should be able to understand why I am having a hard time to >> understand this persistant fixation on wanting to get element >> coordinates in respect to anything else but that element's position in >> the normal flow. >> > > It is unclear when you write "position" what you mean. Do you mean "top" > and "left" values or is it something else? I believe he wants one from each of top/bottom and left/right. > >>> jQuery's offset >>> method would be the method for that. >> >> I want to retrieve CSS values, and jQuery (as do some other libraries) >> pretends to provide a method to do that; unsurprisingly, the cross >> browser proposition is restricted to a tiny subset of the possible use >> cases. > > Use getComputedStyle for ViewCSS and currentStyle for IE to get that. Wrong again. (!) Do me a favor and read the thread to its conclusion before posting any more (or just let it lie as it is done). > It > is going to be limited to what the browsers can do. That's your self-imposed limitation, which seems to be the result of blinders. :( > In some cases, you > will find browser returning "auto" or worse -- when querying "left" > value, you'll get a value that corresponds to that element's marginLeft. What a blow for you. :) > > To get around that issue, the stylesheet will need a left value. Wrong. > > The dfference of IE current style is even greater. Yeah, you will have to deal with non-pixel units and the aforementioned requirement of explicitly declaring the position in a style sheet. That's all and it is all unnecessary. If you pursue this direction further into the weeds, I am just going to go ballistic. It's almost like you are being deliberately loopy (and that pisses me off as I don't care to have to clear up what you obscure). Leave it alone. We're cone here. Thanks for your attempts to help.
From: Garrett Smith on 20 Mar 2010 15:11
David Mark wrote: > Garrett Smith wrote: >> Eric Bednarz wrote: >>> Garrett Smith <dhtmlkitchen(a)gmail.com> writes: >>> >>>> Eric Bednarz wrote: >>>>> Since I never attempted to retrieve offset values of relatively >>>>> positioned elements by script, […] >>>> "Offset" values and top/left style values are different >>>> things. >>> Ah. >>> >>>> Offset", to me, is about the badly defined and highly >>>> inconsistent "offsetTop", "offsetLeft", and "offsetParent". >>> “Offset”, to CSS 2.1, is about section 9.3.2. >>> >> "offset" is a prefix for three nasty properties and one good property. >> The nasties are: offsetLeft, offsetTop, and offsetParent. The one good >> one is offsetWidth. > > Are you abstaining on offsetHeight? And BTW, the nasties can be very > useful if you know how to train them. See the final resolution of this > thread. ;) > Looking down further... >> Those are defined in CSSOM Views, and, depending on the version of that >> document, you'll get completely different definitions for the bad ones. > > They are written about in there, but that was after the fact, so > whatever is written is just trying to explain what has already happened. > It won't change reality retroactively and it remains to be seen if that > _draft_ will ever be finished and formally approved. > >> The implementations of IE 6-8 are all different. > > Which doesn't matter a whit for the case at hand. > >> Likely IE9 will be >> different again. > > And that won't matter either. Basic math is unassailable. > Is it here? >> Of course other browsers all vary on what they do for >> those properties as well. > > Not that much. In many contexts, the results are quite predictable > (even when not using equations that factor out the discrepancies). I've > managed to do some truly useful things with these properties over the > years, but all you seem to do is complain about them and cite daffy W3C > drafts. > >> If you're trying to obtain element coordinates, relative to the root, >> method getBoundingClientRect (also specified in CSSOM Views) does that. > > Fairly well. Of course obtaining such coordinates relative to the root > is ill-advised and virtually always unnecessary (consider that fact at > the design stage). > >>>>> <http://bednarz.nl/tmp/relative/> >>> (Unfortunately I had to move that:) >>> >>> <http://bednarz.nl/sandbox/js/relative/> >>> >>>> What I do not understand is the "expected" column. What are the >>>> expectations coming from? >>> See above; is the specification (candidate) an unreasonable point of >>> reference? >>> >>>>> - jQuery does nothing more than returning the wrong results provided >>>>> by the >>>>> getComputedStyle/currentStyle branch >>>> To retrieve element coordinate offsets with jQuery, >>> Anybody who understands the difference between relative and absolute >>> positioning should be able to understand why I am having a hard time to >>> understand this persistant fixation on wanting to get element >>> coordinates in respect to anything else but that element's position in >>> the normal flow. >>> >> It is unclear when you write "position" what you mean. Do you mean "top" >> and "left" values or is it something else? > > I believe he wants one from each of top/bottom and left/right. > Interesting. I would probably rather figure out if that is correct, and why, before claiming a final resolution. [...] > If you pursue this direction further into the weeds, I am just going to > go ballistic. It's almost like you are being deliberately loopy (and > that pisses me off as I don't care to have to clear up what you > obscure). Leave it alone. We're cone here. Thanks for your attempts > to help. I am trying to get to the heart of the problem. Making threats to "go ballistic" is childish. And I don't think you'd get very far with that if we met in person :-D. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |