IE8 Javascript Error
Swifty
reported is:
scwTableBackground =
window.getComputedStyle(document.body,null).backgroundColor;
... the error message is "Object doesn't support this property or
method"
This works (the effect of setting scwTableBackground to the body
background colour is observed) in Firefox, Chrome, Opera and Safari
Can I change the code so that it also works with IE8?
For extra bonus points, can anyone explain why the error was reported
on line 449 but when I "View" "Source" the code is on line 447? ( I
arranged for lines 444-446 of the actual source to be blank, and then
proved that the problem was in the line above, by moving it upwards
through the blank lines.
For even more bonus points, can IE6 be persuaded to display the actual
line of source that is causing the error, so I won't care so much when
it gets the maths wrong?
--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Gregor Kofler
> I noticed that IE8 reports an error on one of my webpages. The line
> reported is:
>
> scwTableBackground =
> window.getComputedStyle(document.body,null).backgroundColor;
>
> ... the error message is "Object doesn't support this property or
> method"
Because there is no getComputedStyle() in IEs...
> This works (the effect of setting scwTableBackground to the body
> background colour is observed) in Firefox, Chrome, Opera and Safari
>
> Can I change the code so that it also works with IE8?
Use the element.currentStyle object instead.
> For extra bonus points, can anyone explain why the error was reported
> on line 449 but when I "View" "Source" the code is on line 447? ( I
> arranged for lines 444-446 of the actual source to be blank, and then
> proved that the problem was in the line above, by moving it upwards
> through the blank lines.
> For even more bonus points, can IE6 be persuaded to display the actual
> line of source that is causing the error, so I won't care so much when
> it gets the maths wrong?
There is some sort of "rule" to IEs line numbers, but I just forgot
about it. I suppose some googling will help.
Gregor
Swifty
<use...@gregorkofler.com> wrote:
>Use the element.currentStyle object instead.
Fine. The IE users can live with the yellow triangle. They are the
minority amongst my users. I love answers that mean I don't have to do
anything. :-)
Thomas 'PointedEars' Lahn
> Gregor Kofler [wrote:]
>> Use the element.currentStyle object instead.
>
> Fine. The IE users can live with the yellow triangle.
You do realize that there is more to runtime errors than a yellow triangle
in a status bar, yes?
> They are the minority amongst my users. I love answers that mean I don't
> have to do anything. :-)
You do realize that this is not the behavior of a responsible Web developer,
but of a script-kiddie, yes?
Simply implement feature-testing.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Richard Maher
;-)
williamc
This blog entry might be worth a read...
http://robertnyman.com/2006/04/24/get-the-rendered-style-of-an-element/
Critiques of Nyman's wrapper function, anybody?
--
-williamc
Dr J R Stockton
com>, Fri, 19 Nov 2010 19:36:55, Swifty <steve....@gmail.com>
posted:
>I noticed that IE8 reports an error on one of my webpages. The line
>reported is:
>
>scwTableBackground =
>window.getComputedStyle(document.body,null).backgroundColor;
>
>... the error message is "Object doesn't support this property or
>method"
Indeed, while a form in my web page js-props.htm will enumerate that
property in Firefox, it does not do so in IE8; but it does not in IE8
enumerate document.write either, so that is unconvincing. But pasting
window.getComputedStyle into the General Tester below confirms its
presence in FF and absence in IE.
To all : Is there any reasonable way in IE 8 of obtaining a list of
unknown but existing properties of an element (trying *all* possible
properties will be too slow)? If so, please show how, if you can.
I do have a method in mind for obtaining a list of element properties in
IE that are also properties of that element in at least one of my other
browsers.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Swifty
<Point...@web.de> wrote:
>You do realize that there is more to runtime errors than a yellow triangle
>in a status bar, yes?
I wasn't born yesterday. The effect in this case is that they get the
default background colour for my element rather than having it match
the page they are viewing. So the IE users will be saying "Nice
contrasting colour" while everyone else probably won't even notice the
trouble I went to get the element looking similar to the rest of the
page.
It's not the end of the world, and the corporation that I work for
will certainly not fund my effort to find a solution that works on the
minority browser.
I'm driven by Return On Investment, and I'm way overdrawn on this
topic, so I'm out of here.
Swifty
wrote:
>http://robertnyman.com/2006/04/24/get-the-rendered-style-of-an-element/
That was the answer that I needed. Thank you! It's in production
seconds later.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>>You do realize that there is more to runtime errors than a yellow triangle
>>in a status bar, yes?
>
> I wasn't born yesterday.
But you are obviously sufficiently inexperienced to make reasonable design
decisions.
> The effect in this case is that they get the default background colour for
> my element rather than having it match the page they are viewing. So the
> IE users will be saying "Nice contrasting colour" while everyone else
> probably won't even notice the trouble I went to get the element looking
> similar to the rest of the page.
You are mistaken. Whether or not a runtime error is reduced to showing that
yellow triangle or displayed as a very much visible error message window
depends first on the user's settings, second whether these settings take
effect in the runtime environment (particularly with MSHTML-based displays).
And of course such an error is going to cause all further scripts in that
document to not work anymore in IE/MSHTML.
> It's not the end of the world, and the corporation that I work for
> will certainly not fund my effort to find a solution that works on the
> minority browser.
Wrong again, see e.g.
<http://en.wikipedia.org/wiki/Usage_share_of_web_browsers>
Of course, if you never make any adaptions for IE/MSHTML, and let their
users deal with the runtime errors that you produce, it is not at all
surprising that you perceive IE/HTML users as being in the minority.
(The same can be said for people programming for IE only and state that IE
users are by far in the majority according to their so-called statistics.)
This is called a self-fulfilling prophecy, and it is the predominant fallacy
in Web development.
And the corporation certainly would fund your going to
<http://www.google.com/search?q=getComputedStyle+ie&filter=0>
("28,300 results (0.16 seconds)")
or copy-pasting code along
/**
* Returns the computed style of an {@link Element} or the
* computed value of an <code>Element</code>'s style property.
*
* @param o : Element
* Element for which the computed style should be retrieved.
* @param sPseudoEl : string
* The name of the pseudo-element, such as ":first-child".
* Use <code>null</code> (default) for the element itself.
* @param sProperty : string
* The property name in CSS or script syntax (names are mapped
* automatically according to the feature used). If not passed
* or empty, the entire computed style is returned.
* @return CSSStyleDeclaration | currentStyle | string
*/
var _getComputedStyle = (function () {
var
hasGCS = jsx.object.isMethod(document, "defaultView",
"getComputedStyle"),
propertyMap = {
"float": hasGCS ? "cssFloat" : "styleFloat"
};
return function(o, sPseudoEl, sProperty) {
if (hasGCS || typeof o.currentStyle != "undefined")
{
var compStyle = (hasGCS
? document.defaultView.getComputedStyle(o, sPseudoEl || null)
: o.currentStyle);
return (sProperty
? compStyle[
jsx.string.hyphenatedToCamelCase(
jsx.object.getProperty(propertyMap, sProperty, sProperty))
]
: compStyle);
}
var emptyResult = {};
emptyResult[sProperty] = "";
return (sProperty ? emptyResult : null);
};
}());
(<http://pointedears.de/websvn/filedetails.php?repname=JSX&path=/trunk/dhtml.js&rev=198&peg=198>)
> I'm driven by Return On Investment, and I'm way overdrawn on this
> topic, so I'm out of here.
Ignorance must be bliss. So good-bye, script-kiddie. And good luck,
for you are really going to need it.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
Thomas 'PointedEars' Lahn
> This blog entry might be worth a read...
>
> http://robertnyman.com/2006/04/24/get-the-rendered-style-of-an-element/
>
> Critiques of Nyman's wrapper function, anybody?
This is Usenet, _not_ a Web forum. With exceptions (like referring to
Google search results), avoid forcing readers to switch media.
[Indented by 2 spaces, tabs replaced by 2 spaces; word-wrap at 76 characters
due to Usenet recommendations]
function getStyle(oElm, strCssRule){
var strValue = "";
if(document.defaultView && document.defaultView.getComputedStyle){
strValue = document.defaultView.getComputedStyle(oElm,
"").getPropertyValue(strCssRule);
}
else if(oElm.currentStyle){
strCssRule = strCssRule.replace(/\-(\w)/g, function (strMatch, p1){
return p1.toUpperCase();
});
strValue = oElm.currentStyle[strCssRule];
}
return strValue;
}
The feature-testing is insufficient. That a property value can be converted
to boolean `true' does _not_ need to mean that the property is callable.
And the user of this function might soon (IE 9) be facing the problem that
host object's methods in MSHTML of type "unknown" must _not_ be subjected to
implicit type conversion, unless one wants to cause a *runtime error*.
See also
<http://jibbering.com/faq/notes/detect-browser/#bdFD>
and numerous discussions in this newsgroup (keywords: isMethod,
isHostMethod).
The getComputedStyle() call is _not_ standards-compliant; interoperability
is at risk here: For targeting elements instead of pseudo-elements, the
second argument must be `null', _not_ the empty string.
See also: <https://developer.mozilla.org/en/DOM:window.getComputedStyle>
The method chaining is error-prone: That an implementation implements one
interface (which provides one method) does _not_ need to mean that it
implements another (which provides another method).
This is patently true with W3C DOM Level 2 Style CSS:
<http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-extended>
The property mapping is too extensive on the one hand, insufficient on the
other. `\w' equals [A-Za-z_], but `foo_bar' should _not_ be mapped to
`fooBar' (ibid.) `float' should _not_ be mapped to `float' in MSHTML, but
to `styleFloat':
<http://msdn.microsoft.com/en-us/library/ms533758(v=VS.85).aspx>
The method is written inefficiently: In most if not all cases it suffices to
feature-test document.defaultView.getComputedStyle() once, which can be
accomplished by use of a closure.
The code is hard to read; pretty-printing is almost non-existent (e.g., no
visible difference between statements and calls, no word-wrapping at column
80).
One used identifier is misleading: A CSS *property name* is most definitely
_not_ a CSS *rule*: a CSS rule(set) consists of a selector, and a set of
property name-value pairs. This is even more severe since it is the
identifier of an argument of a public function, and a documentation comment
is missing.
HTH
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
williamc
...
> HTH
Thx, I'll work through your comments. That indeed qualifies as a critique.
> PointedEars
--
-williamc
williamc
>
>> This blog entry might be worth a read...
>>
>> http://robertnyman.com/2006/04/24/get-the-rendered-style-of-an-element/
...
> The property mapping is too extensive on the one hand, insufficient on the
> other. `\w' equals [A-Za-z_], but `foo_bar' should _not_ be mapped to
> `fooBar' (ibid.) `float' should _not_ be mapped to `float' in MSHTML, but
> to `styleFloat':
>
IIRC this particular issue was brought up by a 3rd. party in the
comments section of the blog entry, and Nyman decided not to modify the
function for whatever reason...
> HTH
>
> PointedEars
--
-williamc
Dr J R Stockton
Sun, 21 Nov 2010 12:44:19, Thomas 'PointedEars' Lahn
<Point...@web.de> posted:
>williamc wrote:
>
>> This blog entry might be worth a read...
>>
>> http://robertnyman.com/2006/04/24/get-the-rendered-style-of-an-element/
>>
>> Critiques of Nyman's wrapper function, anybody?
>
>This is Usenet, _not_ a Web forum. With exceptions (like referring to
>Google search results), avoid forcing readers to switch media.
One should always quote the sources used, when specific. Copying from
those sources needs to be done judiciously, if it is done at all.
>[Indented by 2 spaces, tabs replaced by 2 spaces; word-wrap at 76 characters
>due to Usenet recommendations]
Usenet recommendations are 72 characters. Don't try to pass off German
newsgroup requirements as generally valid.
FAQ requirements should be met in addition to general ones.
The FAQ says 72 characters, and implies indentation to show structure.
That means NOT allowing the posting agent to do the wrapping, as you
have done, but to break lines in the manner most helpful to the reader.
--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn posted:
>>[Indented by 2 spaces, tabs replaced by 2 spaces; word-wrap at 76
>>[characters due to Usenet recommendations]
>
> Usenet recommendations are 72 characters.
There are no definitive Usenet recommendations other than in your head.
Mine was merely a hint that word-wrap had been applied to the original code,
and that it was applied according to the settings of my newsreader, which
happens to be at 76 characters.
> Don't try to pass off German newsgroup requirements as generally valid.
Stop trying to pass off anything non-English as inferior, or anything in
your opinion as definitive.
> FAQ requirements should be met in addition to general ones.
The FAQ only makes recommendations.
> The FAQ says 72 characters, and implies indentation to show structure.
The FAQ does not say posters are *required* to post texts that are not wider
than 72 characters.
> That means NOT allowing the posting agent to do the wrapping, as you
> have done, but to break lines in the manner most helpful to the reader.
You must have had a really bad day when you had nothing off-topic or not
related to formalities to bitch about.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
David Mark
wrote:
> williamc wrote:
> > This blog entry might be worth a read...
>
> >http://robertnyman.com/2006/04/24/get-the-rendered-style-of-an-element/
>
> > Critiques of Nyman's wrapper function, anybody?
>
> This is Usenet, _not_ a Web forum. With exceptions (like referring to
> Google search results), avoid forcing readers to switch media.
>
> [Indented by 2 spaces, tabs replaced by 2 spaces; word-wrap at 76 characters
> due to Usenet recommendations]
>
> function getStyle(oElm, strCssRule){
> var strValue = "";
> if(document.defaultView && document.defaultView.getComputedStyle){
> strValue = document.defaultView.getComputedStyle(oElm,
> "").getPropertyValue(strCssRule);
> }
> else if(oElm.currentStyle){
> strCssRule = strCssRule.replace(/\-(\w)/g, function (strMatch, p1){
> return p1.toUpperCase();
> });
> strValue = oElm.currentStyle[strCssRule];
> }
> return strValue;
> }
>
In addition to Thomas' comments, the getPropertyValue method, though
standard, is known to be broken in some older browsers and so requires
feature testing. And some (very) old browsers will choke on the
passing of a function as the second argument to the replace method.
It is possible to avoid both of these issues by passing the
"camelized" property name in the first place. That property will
invariably exist on the object returned from getComputedStyle. No,
it's not an "official" standard, but neither is the currentStyle
property.
Regardless, if detection/testing determines neither will work, you
don't create the function (this is the bit that seems to elude most
library authors). If the function is missing and your application
needs it for anything critical, you bail out and leave the document
alone (as if scripting were disabled). It's as simple as:-
var getStyle;
[testing and conditional creation of function here]
if (getStyle) {
// There you go
}
Unfortunately, virtually all GP libraries create such functions
*unconditionally*, which implies that they will work in any
environment (which is exactly the impression the authors/marketers
want to create). Sorting out the results (if any) is left to the
calling code, which is typically written by developers trusting that
the libraries will always "do the right thing" for "all browsers" (or
at least the five they claim to support). It's certainly much simpler
and less time-consuming to wrap your application (or parts of it) in
an - if - clause, isn't it? It may seem like more typing (as if that
is an issue), but the lack of "extra" typing after calling a library
function only indicates blind faith in the function, not that
additional logic is unnecessary.
Taken to a perverse extreme, the chaining style of coding assumes all
functions will always work as expected in all browsers, so there is no
need to ever return anything but "this". The train of thought goes
something like: if the function exists (and it invariably does), it
will always perform exactly as expected, so there is no need to test
anything afterward and therefore no need to return any meaningful
results. This pattern would be considered ludicrous for any language,
but it is particularly unsuited for a language used primarily for
browser scripting.
Of course, functions are designed to map a domain (arguments) to a
range (return value) and if you don't account for the fact that they
may not work at all in the current environment, you are left with only
their return values (assuming they don't throw an exception) to
analyze. And if they always return a reference to the same (typically
discarded) object, you have nothing at all to go on. Basically, you
are flying blind with John Resig as your co-pilot; he just enrolled in
flight school yesterday and his dog ate the flight plan. :)
But I digress. I should add that the IE's proprietary currentStyle
property is nowhere near equivalent to the getComputedStyle method.
The only documentation that could complete this work is that it in
many cases the results will be inconsistent between IE and virtually
every other browser. Of course, such ominous disclaimers tend to cut
down on readership and fan worship. ;)
One could go to a lot of trouble to try to account for every
conceivable difference between the two approaches (or download the
folly of others). Then there's the realistic approach, which is to
write only as much of a wrapper as is needed for your application,
carefully defining and documenting its limitations. The result is
smaller, faster code with clearly defined behavior (and perhaps even
greater understanding of the subject), as opposed to bloated, slow,
magic "wheels" that tend to fall off periodically, much to the
surprise of their makers (but don't even think about re-inventing,
just wait and they'll "get them right" some year).
But in the end, fetching computed (or cascaded or whatever you want to
call IE's take on them) styles is *rarely* needed for well-designed
applications. Take CSS positioning, which is notoriously buggy and
inconsistent, even in non-IE browsers (and virtually impossible to
deal with in IE, unless you use pixel units for everything):-
http://www.cinsoft.net/position.html
Or dimensions:-
http://www.cinsoft.net/size.html
..and similar strategies can be employed to detect margins, borders,
etc.
The "argument" against such alternatives was that the getComputedStyle
method is "standard" (recommended by the W3C anyway) and the offset*
properties are not. Of course, in this particular context, that sort
of argument is no argument at all. Both are implemented just as
widely and as the offset* properties are in the process of being
standardized, they won't be going away in the future.
Both strategies employ properties that are known to be inconsistent
cross-browser. The difference is that with getComputedStyle there is
no way to factor out the differences. Took two months of back-and-
forth to explain this to the last FAQ maintainer and he still didn't
add a note to the FAQ. To whomever takes over his duties, this is the
sort of stuff that should be in the FAQ notes. There is obviously a
lot of confusion out there (even among supposed experts), which is
unsurprising considering the shortage of useful resources (and the
abundance of useless blog posts and dubious libraries).
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> williamc wrote:
>> > This blog entry might be worth a read...
>>
>> >http://robertnyman.com/2006/04/24/get-the-rendered-style-of-an-element/
>> >
>> > Critiques of Nyman's wrapper function, anybody?
>>
>> […]
>> function getStyle(oElm, strCssRule){
>> var strValue = "";
>> if(document.defaultView && document.defaultView.getComputedStyle){
>> strValue = document.defaultView.getComputedStyle(oElm,
>> "").getPropertyValue(strCssRule);
>> }
>> else if(oElm.currentStyle){
>> strCssRule = strCssRule.replace(/\-(\w)/g, function (strMatch, p1){
>> return p1.toUpperCase();
>> });
>> strValue = oElm.currentStyle[strCssRule];
>> }
>> return strValue;
>> }
>
> In addition to Thomas' comments, the getPropertyValue method, though
> standard, is known to be broken in some older browsers and so requires
> feature testing.
Name them, please.
> And some (very) old browsers will choke on the passing of a function as
> the second argument to the replace method.
As for this, I wonder: Do we *really* need (or want) to consider Netscape
3.x and IE/MSHTML 5.0 anymore (Netscape is dead, R.I.P., and M$ dropped IE 5
support in 2005-06, IE 6 support in June this year)? Similar to Peter
Micheaux's approach a few years ago, I am considering phasing out support
for those in JSX so that the rather expensive workarounds need only be
included if absolutely necessary.
> It is possible to avoid both of these issues by passing the
> "camelized" property name in the first place. That property will
> invariably exist on the object returned from getComputedStyle. No,
> it's not an "official" standard,
Yes, it is. (Bug in the matrix detected.)
> [TLDR]
David Mark
wrote:
> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> williamc wrote:
> >> > This blog entry might be worth a read...
>
> >> >http://robertnyman.com/2006/04/24/get-the-rendered-style-of-an-element/
>
> >> > Critiques of Nyman's wrapper function, anybody?
>
> >> […]
> >> function getStyle(oElm, strCssRule){
> >> var strValue = "";
> >> if(document.defaultView && document.defaultView.getComputedStyle){
> >> strValue = document.defaultView.getComputedStyle(oElm,
> >> "").getPropertyValue(strCssRule);
> >> }
> >> else if(oElm.currentStyle){
> >> strCssRule = strCssRule.replace(/\-(\w)/g, function (strMatch, p1){
> >> return p1.toUpperCase();
> >> });
> >> strValue = oElm.currentStyle[strCssRule];
> >> }
> >> return strValue;
> >> }
>
> > In addition to Thomas' comments, the getPropertyValue method, though
> > standard, is known to be broken in some older browsers and so requires
> > feature testing.
>
> Name them, please.
It's been too many years since we had that discussion. Perhaps search
the archive.
>
> > And some (very) old browsers will choke on the passing of a function as
> > the second argument to the replace method.
>
> As for this, I wonder: Do we *really* need (or want) to consider Netscape
> 3.x and IE/MSHTML 5.0 anymore (Netscape is dead, R.I.P., and M$ dropped IE 5
> support in 2005-06, IE 6 support in June this year)?
I don't need to consider them as I don't use the replace method in
that way. As for MS dropping support for IE6, I don't see the
connection. AFAIK, IE6 is fine with a function as the second argument
to replace.
And who is going to tell all of those IE6 users that MS dropped
support for their browser? There's no way that Web developers can
drop support for that one at this point. And if you write scripts
defensively with proper feature testing, you never have to drop
support for anything.
For example, last winter I had users testing My Library with NN4.
Methods that could not work in such a limited environment disappeared
from the API, making it trivial for applications that need those
methods to bail out on such browsers (leaving a working document
behind, as if scripting were disabled).
> Similar to Peter
> Micheaux's approach a few years ago, I am considering phasing out support
> for those in JSX so that the rather expensive workarounds need only be
> included if absolutely necessary.
In general, it's best not to consider specific browsers during
design. You do your testing afterward (preferably including as many
lesser browsers as possible) to make sure that your feature testing is
solid.
It's certainly not expensive to test the replace method with function
arguments (if you insist on using it that way). As for
"camelization", there are alternatives that avoid the issue. I've
heard opinions that performance could be impacted by such alternatives
(something about "beating the frame rate" in animations IIRC), but
that presupposes a design foolish enough to convert property names
inside loops (or at timed intervals).
>
> > It is possible to avoid both of these issues by passing the
> > "camelized" property name in the first place. That property will
> > invariably exist on the object returned from getComputedStyle. No,
> > it's not an "official" standard,
>
> Yes, it is. (Bug in the matrix detected.)
Well, we (meaning the group) had had that discussion numerous times as
well. If those shortcut properties are "official" recommendations,
then all the better. I really can't see how this:-
x = getStyle(el, 'background-color');
...is preferable to:-
x = getStyle(el, 'backgroundColor');
...and yes, I understand that if the goal is to attract as many
neophytes as possible (and assuming they will overlook the all-
important extra typing), one might consider the former a must. Of
course, those strings won't be addressed by minifiers, so it's also an
extra byte to download. :)
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> williamc wrote:
>> >> > This blog entry might be worth a read...
>> >>
>> >> >http://robertnyman.com/2006/04/24/get-the-rendered-style-of-an
>> >> >element/
>> >>
>> >> > Critiques of Nyman's wrapper function, anybody?
>> >>
>> >> […]
>> >> function getStyle(oElm, strCssRule){
>> >> var strValue = "";
>> >> if(document.defaultView && document.defaultView.getComputedStyle){
>> >> strValue = document.defaultView.getComputedStyle(oElm,
>> >> "").getPropertyValue(strCssRule);
>> >> }
>> >> else if(oElm.currentStyle){
>> >> strCssRule = strCssRule.replace(/\-(\w)/g, function (strMatch, p1){
>> >> return p1.toUpperCase();
>> >> });
>> >> strValue = oElm.currentStyle[strCssRule];
>> >> }
>> >> return strValue;
>> >> }
>> >
>> > In addition to Thomas' comments, the getPropertyValue method, though
>> > standard, is known to be broken in some older browsers and so requires
>> > feature testing.
>>
>> Name them, please.
>
> It's been too many years since we had that discussion. Perhaps search
> the archive.
I don't have the time (at the moment), hence my question. (Surely you would
have documented your API design decisions somewhere?)
>> > And some (very) old browsers will choke on the passing of a function as
>> > the second argument to the replace method.
>> As for this, I wonder: Do we *really* need (or want) to consider Netscape
>> 3.x and IE/MSHTML 5.0 anymore (Netscape is dead, R.I.P., and M$ dropped
>> IE 5 support in 2005-06, IE 6 support in June this year)?
>
> I don't need to consider them as I don't use the replace method in
> that way. As for MS dropping support for IE6, I don't see the
> connection. AFAIK, IE6 is fine with a function as the second argument
> to replace.
Mentioning IE 6 support being phased out *at Microsoft* was meant to
emphasize how very out-of-date IE 5, and consequently, JScript 5.0 is. And
given the inherent security risk with using MSHTML 5 (it had a great many
security leaks, and there are no more security updates), one must question
the need (or want) to support it.
>> Similar to Peter Micheaux's approach a few years ago, I am considering
>> phasing out support for those in JSX so that the rather expensive
>> workarounds need only be included if absolutely necessary.
>
> In general, it's best not to consider specific browsers during
> design. You do your testing afterward (preferably including as many
> lesser browsers as possible) to make sure that your feature testing is
> solid.
Of course. I am referring to ECMAScript implementations by their primary
runtime environments: virtually ancient browsers. With the browser version
being globally deprecated (even by its vendor), it strikes me as being a
good idea to provide extra support code for those who still need to support
them, and to spare others the larger footprint.
> It's certainly not expensive to test the replace method with function
> arguments (if you insist on using it that way).
The feature tests for methods that are supposed to be there in conforming
implementations are not very expensive; serving the workarounds, often for
nothing nowadays, is.
As for my "insisting" on using it that way, what is the reasonable
alternative?
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)