 | |
getComputedStyle, where is my LI?
Javascript JavaScript language (comp.lang.javascript)
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
getComputedStyle, where is my LI? -
11-01-2009
, 01:03 AM
In the following example, the "top" value for each LI should be "auto"
or 0, based on the definition of absolute value for top in CSS 2[1].
Definitions of "absolute value" changed from CSS 2 to CSS 2.1.
Result:
Firefox: "0px"
Chrome 2: "auto"
Opera 10.1: "133px"
What the fuck?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<title>getComputedStyle(top) Opera Bug</title>
<style type="text/css">
li {
/* Remove 'position: relative;' for result "auto" in Gecko */
position: relative;
}
</style>
</head>
<body>
<ul>
<li><div>item 0</div></li>
<li><div>item 1</div></li>
<li><div>item 2</div></li>
<li><div>item 3</div></li>
<li><div>item 4</div></li>
<li><div>item 5</div></li>
<li><div>item 6</div></li>
<li id="i7"><div>item 7</div></li>
<li><div>item 8</div></li>
<li><div>item 9</div></li>
</ul>
<script type="text/javascript">
onload = function(){
var i7 = document.getElementById("i7");
var top = document.defaultView.getComputedStyle(i7,"").top;
var m = document.getElementById("m");
m.innerHTML = top;
};
</script>
<pre id="m">-</pre>
</body>
</html>
After over 10 years of having fickle, limited APIs to read styles, the
best efforts of browser vendors and CSS WG API designers have left us
with an API that is unreliable, complicated by design, non-interoperable
(doesn't work in IE and works differently in various browsers and
verions).
Did the browser vendors and CSS WG put forth the effort to cooperate to
design this? If so, do the implementation bugs indicate a problem in the
API design itself?
Definitions of "absolute value" are complex and vary between CSS
versions. That would seem to complicate implementation.
If the API design is such a problem, then it should be acknowledged. The
problem should not be denied (whether out of ignorance, laziness,
unwillingness, fear, etc).
As I understand CSS2.1, the following:
li {
position: relative;
}
should get the result "0px".
The CSS2 spec states:
Quote:
|
The 'top' and 'bottom' properties move relatively positioned element(s) up or down without changing their size. 'top' moves the boxes down, and 'bottom' moves them up. Since boxes are not split or stretched as a result of 'top' or 'bottom', the computed values are always: top = -bottom. If both are 'auto', their computed values are both '0'. If one of them is 'auto', it becomes the negative of the other. If neither is 'auto', 'bottom' is ignored (i.e., the computed value of 'bottom' will be minus the value of 'top'). |
their computed values are both '0'.
Fortunately, the solution is to use position: relative and top: 0. That
gets me "0px" in all three browsers.
(meanwhile Apple, aka "those scumbags in Cupertino" are patenting CSS
animations and Touch events, marketing iPhone, iPod, etc).
[1]<URL: http://www.w3.org/TR/CSS2/visuren.html#position-props >
[2]<URL: http://www.w3.org/TR/CSS2/visuren.html#relative-positioning >
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
#2
| |||
| |||
|
|
Opera 10.1 has a buggy implementation of getComputedStyle top. I've noticed now that getting the top value for an LI, in normal flow, returns what would be an in-flow offset y coordinate. Not surprising. I noticed a similar bug years ago in Opera. URL:http://dhtmlkitchen.com/?category=/Browsers/&date=2007/11/08/&entry=O... (messy URI and latency, probably due to my configuration of Blojsom); In the following example, the "top" value for each LI should be "auto" or 0, based on the definition of absolute value for top in CSS 2[1]. Definitions of "absolute value" changed from CSS 2 to CSS 2.1. Result: * *Firefox: * *"0px" * *Chrome 2: * "auto" * *Opera 10.1: "133px" What the fuck? |
item down two pixels, you would add two to whatever is there. In the
case of "auto" you would assume 0. GIGO.
If instead you are interested in the offset position, use offsetLeft/
Top, preferably within the confines of a positioned parent element.
#3
| |||
| |||
|
|
On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote: Opera 10.1 has a buggy implementation of getComputedStyle top. [...] In the following example, the "top" value for each LI should be "auto" or 0, based on the definition of absolute value for top in CSS 2[1]. Definitions of "absolute value" changed from CSS 2 to CSS 2.1. Result: Firefox: "0px" Chrome 2: "auto" Opera 10.1: "133px" What the fuck? Two words: who cares? |
following 10yr old standards? Yeah, I care about that.
In more than 10 years, there is not a way to read an element's style
value, cross browser.
It is a problem.
Given the rate of progress by the (useless individuals in the CSSWG),
there is no foreseeable change on the horizon.
*That* is a worse problem.
If you wanted to - for example - move the list
Quote:
|
item down two pixels, you would add two to whatever is there. In the case of "auto" you would assume 0. GIGO. |
I would not assume "0" for auto, because I read the specification
(indeed I cited it on this very thread) and I understand that such
assumption would be incorrect. "auto" is not 0.
Quote:
|
If instead you are interested in the offset position, use offsetLeft/ Top, preferably within the confines of a positioned parent element. OffsetLeft and offsetTop are not standard. That approach works for UL, |
Oddly, what Opera returns for the computed style string + "px" for the
value that you have described as "the offset position from the
positioned parent element."
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
#4
| |||
| |||
|
|
(...) (meanwhile Apple, aka "those scumbags in Cupertino" |
Waterloo (CA), right ?
No, because as they're still inventing it, they've got nothing to
patent yet... LOL
Never mind, see below.
Anyway, what does this have to do with anything in the post above ?
Quote:
|
are patenting CSS animations (...) |
Webkit.org:
http://webkit.org/blog/324/css-animation-2/
<quote>
We’re documenting these enhancements on webkit.org and are proposing
the specifications to standards bodies.
</quote>
w3.org:
http://www.w3.org/TR/css3-animations/
<quote>
This document was produced by a group operating under the 5 February
2004 W3C Patent Policy
</quote>
http://www.w3.org/Consortium/Patent-Policy-20040205/
<quote>
The W3C Patent Policy governs the handling of patents in the process
of producing Web standards. The goal of this policy is to assure that
Recommendations produced under this policy can be implemented on a
Royalty-Free (RF) basis.
</quote>
http://www.w3.org/Consortium/Patent-Policy-20040205/#def-RF
<quote>
With respect to a Recommendation developed under this policy, a W3C
Royalty-Free license shall mean a non-assignable, non-sublicensable
license to make, have made, use, sell, have sold, offer to sell,
import, and distribute and dispose of implementations of the
Recommendation that:
1. shall be available to all, worldwide, whether or not they are W3C
Members;
(...)
</quote>
Quote:
|
and Touch events (...) |
http://lists.w3.org/Archives/Public/www-dom/2009OctDec/0029.html
<quote>
No, fortunately that API is patented so it won't be usable (and hence,
will not be used as a public standard).
</quote>
You should know that something, even if patented by a 3rd party, can
still become a w3 standard.
See Maciej's response to Olli's "I was a bit afraid of that Apple
might have done something evil like this":
http://lists.w3.org/Archives/Public/www-dom/2009OctDec/0034.html
<quote>
I note that Apple is a member of the Web Apps Working Group and thus
subject to the W3C Patent Policy with respect to Web Apps WG
deliverables. I can't comment on whether Apple would exclude any
patent claims relating to this area, if they turn out to be
essential
claims.
</quote>
The point is: patented (to protect their intellectual property) or
not, the intellectual property of Apple's APIs/inventions is theirs
anyway.
What matters is if Apple *wants* their invention to become a w3
standard. If they don't, they are in their own right (and it's not
"something evil like this"). If they do, they know pretty well what
are the steps to take.
There are many reasons for Apple to prefer their API to become a w3
standard... at the right time (which is probably: "not yet" :-)
Had the w3c proposed a useful, well designed touch/gestures API
already, Apple wouldn't have had to invent it themselves, and we would
not be discussing this. But these design by commitee things don't
deliver so much nor so fast nor of course in anticipation to future
needs. They might be lucky if Apple gifts them this API too -as the
CSS animations/transforms- otherwise they're going to have to design
their own.
The <canvas> is patented too -if I got it right- in the "Unified
interest layer for user interface" US 2006/0015818...
--
Jorge.
#5
| |||
| |||
|
#6
| |||
| |||
|
|
On Nov 1, 6:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote: (...) (meanwhile Apple, aka "those scumbags in Cupertino" No news about the scumbags in Redmond (WA, USA), Espoo (FIN) or Waterloo (CA), right ? |
Quote:
|
See Maciej's response to Olli's "I was a bit afraid of that Apple might have done something evil like this": http://lists.w3.org/Archives/Public/www-dom/2009OctDec/0034.html quote I note that Apple is a member of the Web Apps Working Group and thus subject to the W3C Patent Policy with respect to Web Apps WG deliverables. I can't comment on whether Apple would exclude any patent claims relating to this area, if they turn out to be essential claims. /quote |
duplicate code for "touchmove", and uses the changedTouches[0], etc.
Programs that use mousemove/touchmove require more than double effort to
unit test.
Simulating touch events takes some 18 parameter variables, three of
those being TouchList objects, each requiring a "Touch" object. It is
actually more work to unit test code for iPhone, so to say that the
effort required to unit test code for iPhone is doubled would be
misleading. The effort is more than double.
Nokia is vying to get some of the touch screen consumer money.
As a (paying) member, these companies get some influence over what
gets standardized. What is disturbing is that many of the
representatives have very little knowledge of browsers, the relevant
standards, or RIA scripting experience. In particular, the
representatives from Microsoft and Nokia.
Meanwhile, developers are stuck with complicated, divergent,
non-interoperable strategies to answer the question of:
"What is the style of my element?"
in the latest versions of the latest browsers are produced by members of
the w3c, (including Apple). They fail to fulfill the requirement, in
even the most common, simple cases.
That is why I am picking on Apple.
A test suite is long overdue. Is there anyone on the w3c who is capable
of writing a test suite? Certainly the funding is there.
http://www.w3.org/Consortium/membership
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
#7
| ||||
| ||||
|
|
David Mark wrote: On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote: Opera 10.1 has a buggy implementation of getComputedStyle top. [...] In the following example, the "top" value for each LI should be "auto" or 0, based on the definition of absolute value for top in CSS 2[1]. Definitions of "absolute value" changed from CSS 2 to CSS 2.1. Result: * *Firefox: * *"0px" * *Chrome 2: * "auto" * *Opera 10.1: "133px" What the fuck? Two words: who cares? * The latest versions of the most popular, and mature browsers not following 10yr old standards? Yeah, I care about that. |
memory leaks. You miss the point that you wouldn't need to care if
you would just avoid these problems at the design stage.
Quote:
|
In more than 10 years, there is not a way to read an element's style value, cross browser. It is a problem. Given the rate of progress by the (useless individuals in the CSSWG), there is no foreseeable change on the horizon. *That* is a worse problem. If you wanted to - for example - move the list item down two pixels, you would add two to whatever is there. *In the case of "auto" you would assume 0. *GIGO. Is the answer to the question: How can I position an element. Who asked? I would not assume "0" for auto, because I read the specification (indeed I cited it on this very thread) and I understand that such assumption would be incorrect. "auto" is not 0. |
"auto" is not a computed style at all. If you run into walls like
this, change direction.
Quote:
|
If instead you are interested in the offset position, use offsetLeft/ Top, preferably within the confines of a positioned parent element. OffsetLeft and offsetTop are not standard. That approach works for UL, but not other elements, such as TD (I recall problems with Safari 2). |
real standards (yet). If you try to measure all the way to the root
of the document, you are going to end up with a lot of code.
Quote:
|
Oddly, what Opera returns for the computed style string + "px" for the value that you have described as "the offset position from the positioned parent element." |
relatively positioned element is not something you should rely on.
That's always been the case, driven home by Opera more than once.
#8
| |||
| |||
|
|
Oddly, what Opera returns for the computed style string + "px" for the value that you have described as "the offset position from the positioned parent element." |
left and nobody in their right mind would use those to determine the
offset position of an element. Hell, IE doesn't even handle computed
styles (as discussed ad nauseum). You'll get lots of "auto" results
(among other things) out of it and will have to jump through hoops to
do the required computations. It's not a good strategy, end of story.
And yes, you could assume 0 for auto in your example as there is no
bottom position specified. You should also know that assigning both
top and bottom (or right and left) positions is problematic in older
browsers (some won't know what to make of it at all). Always best to
stick with what you know.
#9
| ||||||||||
| ||||||||||
|
|
On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote: David Mark wrote: On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote: Opera 10.1 has a buggy implementation of getComputedStyle top. [...] [...] |
follow up to comp.infosystems.www.authoring.stylesheets
(this is more of a CSS topic).
Quote:
|
If you wanted to - for example - move the list item down two pixels, you would add two to whatever is there. In the case of "auto" you would assume 0. GIGO. Is the answer to the question: How can I position an element. Who asked? I would not assume "0" for auto, because I read the specification (indeed I cited it on this very thread) and I understand that such assumption would be incorrect. "auto" is not 0. Doesn't matter. I wouldn't bother memorizing such useless trivia as "auto" is not a computed style at all. If you run into walls like this, change direction. |
to it earlier in this thread.
It is too complicated to memorize. Things that make sense conceptually
(patterns or formulas) seem easier memorize.
Anyone may read it.
Quote:
|
If instead you are interested in the offset position, use offsetLeft/ Top, preferably within the confines of a positioned parent element. OffsetLeft and offsetTop are not standard. That approach works for UL, but not other elements, such as TD (I recall problems with Safari 2). Works great within a positioned parent. Doesn't matter if they are real standards (yet). If you try to measure all the way to the root of the document, you are going to end up with a lot of code. |
Nonstandard properties are problematic because they often get copied in
ways that are different from the original. The result is a sort of
"mystery meat" property which may mean any things in many contexts.
OffsetTop is the poster child for mystery meat properties.
I explained that problem to VK recently.
Quote:
|
Oddly, what Opera returns for the computed style string + "px" for the value that you have described as "the offset position from the positioned parent element." Again, who cares what they say (or do?) The computed left/top of a relatively positioned element is not something you should rely on. That's always been the case, driven home by Opera more than once. |
nonstandard properties.
The computed style is standard and specified. The value "auto" is a
standard and specified value for computed style for top.
That is clearly stated in the link to CSS2 spec that I provided earlier.
http://www.w3.org/TR/CSS2/visuren.html#position-props
Quote:
|
Computed value: for 'position:relative', see section Relative Positioning. For 'position:static', 'auto'. Otherwise: if specified as a length, the corresponding absolute length; if specified as a percentage, the specified value; otherwise, 'auto'. |
Method getComputedStyle should indeed return that value, as stated in
DOM 2 StyleSheets[1]:
http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-OverrideAndComputed
Quote:
|
2.2.1. Override and computed style sheet Interface ViewCSS (introduced in DOM Level 2) This interface represents a CSS view. The getComputedStyle method provides a read only access to the _computed values_ of an element. |
varies between CSS2 and CSS2.1:
CSS2:
http://www.w3.org/TR/1998/REC-CSS2-19980512/cascade.html#computed-value
Quote:
|
Specified values may be absolute (i.e., they are not specified relative to another value, as in 'red' or '2mm') or relative (i.e., they are specified relative to another value, as in 'auto', '2em', and '12%'). For absolute values, no computation is needed to find the computed value. Relative values, on the other hand, must be transformed into computed values: percentages must be multiplied by a reference value (each property defines which value that is), values with relative units (em, ex, px) must be made absolute by multiplying with the appropriate font or pixel size, 'auto' values must be computed by the formulas given with each property, certain keywords ('smaller', 'bolder', 'inherit') must be replaced according to their definitions. |
http://www.w3.org/TR/CSS21/cascade.html#computed-value
Quote:
|
When the specified value is not 'inherit', the computed value of a property is determined as specified by the Computed Value line in the definition of the property. |
Quote:
|
Computed value: for 'position:relative', see section Relative Positioning. For 'position:static', 'auto'. Otherwise: if specified as a length, the corresponding absolute length; if specified as a percentage, the specified value; otherwise, 'auto'. |
http://www.w3.org/TR/CSS2/visuren.html#relative-positioning
Quote:
|
The 'top' and 'bottom' properties move relatively positioned element(s) up or down without changing their size. 'top' moves the boxes down, and 'bottom' moves them up. Since boxes are not split or stretched as a result of 'top' or 'bottom', the computed values are always: top = -bottom. If both are 'auto', their computed values are both '0'. If one of them is 'auto', it becomes the negative of the other. If neither is 'auto', 'bottom' is ignored (i.e., the computed value of 'bottom' will be minus the value of 'top'). |
(for Relative positioning).
In many browsers, getComputedStyle returns used values for some
properties. The used value and the computed value are not the same
thing.
http://www.w3.org/TR/CSS2/cascade.html#used-value
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
#10
| ||||||||||||||||
| ||||||||||||||||
|
|
David Mark wrote: On Nov 1, 2:22 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote: David Mark wrote: On Nov 1, 1:03 am, Garrett Smith <dhtmlkitc... (AT) gmail (DOT) com> wrote: Opera 10.1 has a buggy implementation of getComputedStyle top. [...] [...] follow up to comp.infosystems.www.authoring.stylesheets (this is more of a CSS topic). |
Quote:
| If you wanted to - for example - move the list item down two pixels, you would add two to whatever is there. *In the case of "auto" you would assume 0. *GIGO. Is the answer to the question: How can I position an element. Who asked? I would not assume "0" for auto, because I read the specification (indeed I cited it on this very thread) and I understand that such assumption would be incorrect. "auto" is not 0. Doesn't matter. *I wouldn't bother memorizing such useless trivia as "auto" is not a computed style at all. *If you run into walls like this, change direction. No need to memorize, the specification is publicly available. I linked to it earlier in this thread. |
with memorizing quirks that are better avoided in the first place.
The issue of unexpected computed left/top/height/width was dealt with
in my library. Though it used a feature test, you really don't need
one for this. If you want to know whether a computed left/top is
accurate (meaning the element won't move if you assign that style),
check whether offsetLeft/Top change. Same goes for dimensions (use
offsetHeight/Width to check that work).
Quote:
|
It is too complicated to memorize. Things that make sense conceptually (patterns or formulas) seem easier memorize. Anyone may read it. |
Quote:
|
If instead you are interested in the offset position, use offsetLeft/ Top, preferably within the confines of a positioned parent element. OffsetLeft and offsetTop are not standard. That approach works for UL, but not other elements, such as TD (I recall problems with Safari 2). Works great within a positioned parent. *Doesn't matter if they are real standards (yet). *If you try to measure all the way to the root of the document, you are going to end up with a lot of code. How about Safari 2, inside a TD? |
that element, spell it out.
Quote:
|
Nonstandard properties are problematic because they often get copied in ways that are different from the original. |
standard. These are apples and oranges. There is correlation, which
is why you can use one to check the other, but they are not the same
thing. Furthermore, one is known to be accurate (in a usable subset
anyway) and one is known to be all over the map.
Quote:
|
The result is a sort of "mystery meat" property which may mean any things in many contexts. |
known to work cross-browser.
Quote:
|
OffsetTop is the poster child for mystery meat properties. |
available for determining the position of an element. Certainly not
computed styles.
Quote:
|
I explained that problem to VK recently. |
Quote:
|
Oddly, what Opera returns for the computed style string + "px" for the value that you have described as "the offset position from the positioned parent element." Again, who cares what they say (or do?) *The computed left/top of a relatively positioned element is not something you should rely on. That's always been the case, driven home by Opera more than once. Generally standards approach should be favored over proprietary, nonstandard properties. |
Quote:
|
The computed style is standard and specified. The value "auto" is a standard and specified value for computed style for top. |
obvious why not.
Quote:
|
That is clearly stated in the link to CSS2 spec that I provided earlier.http://www.w3.org/TR/CSS2/visuren.html#position-props | Computed value: for 'position:relative', see section Relative | Positioning. For 'position:static', 'auto'. Otherwise: if specified as | a length, the corresponding absolute length; if specified as a | percentage, the specified value; otherwise, 'auto'. So for "position: static", the expected computed value is "auto". |
positioned element doesn't move when you adjust left and top, so
computing those styles is impossible.
Quote:
|
Method getComputedStyle should indeed return that value, as stated in DOM 2 StyleSheets[1]:http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-OverrideAndComputed |
Quote:
|
| 2.2.1. Override and computed style sheet | | Interface ViewCSS (introduced in DOM Level 2) | | *This interface represents a CSS view. The getComputedStyle method | provides a read only access to the _computed values_ of an element. |
Quote:
|
That leads to the definition of "computed values". That definition varies between CSS2 and CSS2.1: CSS2:http://www.w3.org/TR/1998/REC-CSS2-19980512/cascade.html#computed-value |
Quote:
|
| Specified values may be absolute (i.e., they are not specified | relative to another value, as in 'red' or '2mm') or relative (i.e., | they are specified relative to another value, as in 'auto', '2em', and | '12%'). For absolute values, no computation is needed to find the | computed value. | | Relative values, on the other hand, must be transformed into computed | values: percentages must be multiplied by a reference value (each | property defines which value that is), values with relative units (em, | ex, px) must be made absolute by multiplying with the appropriate font | or pixel size, 'auto' values must be computed by the formulas given | with each property, certain keywords ('smaller', 'bolder', 'inherit') | must be replaced according to their definitions. CSS2.1http://www.w3.org/TR/CSS21/cascade.html#computed-value | When the specified value is not 'inherit', the computed value of a | property is determined as specified by the Computed Value line in the | definition of the property. The definition for Computed Value, for |top|, one more time: |
[snip]
Quote:
|
In many browsers, getComputedStyle returns used values for some properties. The used value and the computed value are not the same thing.http://www.w3.org/TR/CSS2/cascade.html#used-value |
map. That's why you should stick to what is known to work and use
better alternatives where they exist. Add in that there is no such
method in IE and you've got a clear loser.
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.