G
Garrett Smith
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=/...tyle-Returns-Margin-for-Unset-Top-Left-Values
(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 ****?
<!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:
| 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').
The default value is "auto", and when both top and bottom are 'auto',
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 >
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=/...tyle-Returns-Margin-for-Unset-Top-Left-Values
(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 ****?
<!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:
| 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').
The default value is "auto", and when both top and bottom are 'auto',
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 >
