Simple script works in Firefox but not IE7
garey
I am trying to write some Javascript that will move both buttons
and selects from far left of the viewport into and out of the
viewport. I present a button that moves in another button. The second
button moves in a select.
All of this works in Firefox. Moving the button in and out works
in IE7, but moving in the select does not, despite the exact same code
being used in both cases. The code is below. Note that I added the
"min-height: 0" style statement to the style because I thought that
this might be a Microsoft "layout" problem, but setting min-height
did not affect the problem.
Any help appreciated;
Garey Mills
<html>
<head>
<style type="text/css">
div.extraout { position: absolute; left: -9999em; min-height: 0 }
</style>
<script language="JavaScript">
function ucbmoveIn(name) {
var elem = document.getElementById(name);
elem.style.position = "static";
}
function ucbmoveOut(name) {
var elem = document.getElementById(name);
elem.style.position = "absolute";
}
</script>
</head>
<body>
<button name="more" value="more" onClick='ucbmoveIn("l");return
false;'>More</button>
<div class="extraout" id="l">
<table>
<tr>
<td><button name="a" value="a" onClick='ucbmoveIn("a");return
false;'>A</button></td>
</tr>
</table>
<button name="less" value="less" onClick='ucbmoveOut("l");return
false;'>Hide</button>
</div>
<div class="extraout" id="a">
<tr><td>As</td><td>
<select name="lA" id="lA" size="10" multiple="multiple">
<option value="ach">acholi</option>
<option value="ada">adangme</option>
<option value="afh">afrihili</option>
</select>
</td></tr></table>
<button name="hideAs" value="hideAs" onClick='ucbmoveOut("a");return
false;'>Hide</button>
</div>
</body>
</html>
Thomas 'PointedEars' Lahn
> I am trying to write some Javascript that will move both buttons
> and selects from far left of the viewport into and out of the
> viewport. I present a button that moves in another button. The second
> button moves in a select.
>
> All of this works in Firefox. Moving the button in and out works
> in IE7, but moving in the select does not, despite the exact same code
> being used in both cases. The code is below. Note that I added the
> "min-height: 0" style statement to the style because I thought that
> this might be a Microsoft "layout" problem, but setting min-height
> did not affect the problem.
>
> Any help appreciated;
>
> Garey Mills
>
> <html>
Not Valid.
> <head>
> <style type="text/css">
>
> div.extraout { position: absolute; left: -9999em; min-height: 0 }
Smart people hide the element instead of placing it in CSS hell.
> </style>
>
> <script language="JavaScript">
Not Valid. HTML 4.01 and the `type' attribute turn 10 years this December;
amazing how long such obsolete nonsense as above keeps floating around the Web.
> function ucbmoveIn(name) {
>
> var elem = document.getElementById(name);
The feature test is missing. RTFM, RTFFAQ, STFW.
> elem.style.position = "static";
"static" is the default value. Had you not mindlessly moved the element
beyond good and evil in the first place, that operation would have been
unnecessary.
>
> }
>
> function ucbmoveOut(name) {
>
> var elem = document.getElementById(name);
See above.
> elem.style.position = "absolute";
No.
> }
>
> </script>
> </head>
>
> <body>
>
> <button name="more" value="more" onClick='ucbmoveIn("l");return
> false;'>More</button>
The less compatible `button' element is unnecessary here, a (dynamically
generated) input[type="button"] suffices.
> <div class="extraout" id="l">
Very self-explaining ID, really.
> <table>
> <tr>
> <td><button name="a" value="a" onClick='ucbmoveIn("a");return
> false;'>A</button></td>
See above.
> </tr>
> </table>
You don't need this table at all. Learn HTML and CSS before you try to
learn JS.
> <button name="less" value="less" onClick='ucbmoveOut("l");return
> false;'>Hide</button>
See above. Forget about `return false'; use type="button" instead and
generate this dynamically. (Did anyone tell you already that you should
learn HTML before you try to learn JS?)
> </div>
>
> <div class="extraout" id="a">
See above.
> <tr><td>As</td><td>
Not Valid. There is no table for this table row as the one table in the
document ended well before this line.
> <select name="lA" id="lA" size="10" multiple="multiple">
See above. Besides, this isn't XHTML, is it? HTML UAs tend to choke on
this boolean syntax, even though SGML allows it. RTFM.
> [...]
> </td></tr></table>
> <button name="hideAs" value="hideAs" onClick='ucbmoveOut("a");return
> false;'>Hide</button>
See above.
PointedEars
Eric Bednarz
>> <select name="lA" id="lA" size="10" multiple="multiple">
>
> See above. Besides, this isn't XHTML, is it?
Why would that matter?
> HTML UAs tend to choke on this
That’s a nice bunch of weasel words.
> boolean syntax,
Come again?
> even though SGML allows it.
I withdraw my first question.
You seem to know that HTML UAs don’t have any SGML capabilities. Please
explain all those URI references to the W3C validation service to
confirm compliance with a validating SGML system.
> RTFM.
Or STFW if you are too cheap to buy the manual that actually matters if
you want to discuss esoterica.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>>> <select name="lA" id="lA" size="10" multiple="multiple">
>> See above. Besides, this isn't XHTML, is it?
>
> Why would that matter?
In XHTML this is required; in HTML this is recommended against.
>> HTML UAs tend to choke on this
>
> That’s a nice bunch of weasel words.
>
>> boolean syntax,
>
> Come again?
>
>> even though SGML allows it.
>
> I withdraw my first question.
>
> You seem to know that HTML UAs don’t have any SGML capabilities. Please
> explain all those URI references to the W3C validation service to
> confirm compliance with a validating SGML system.
>
>> RTFM.
>
> Or STFW if you are too cheap to buy the manual that actually matters if
> you want to discuss esoterica.
Idiot. <http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.4>
<http://jibbering.com/faq/#posting>
<http://www.catb.org/~esr/faqs/smart-questions.html#before>
PointedEars
kangax
> garey wrote:
[...]
>> div.extraout { position: absolute; left: -9999em; min-height: 0 }
>
> Smart people hide the element instead of placing it in CSS hell.
CSS hell? Please explain another way to "hide" an element in such way
that its content is "picked up" and pronounced by screen readers.
[...]
--
kangax
Thomas 'PointedEars' Lahn
No, because the whole thing is not accessible in the first place.
PointedEars
David Mark
If an element is hidden, you don't want it to be read by screen
readers. If it is not hidden, you certainly don't want to place it
off-screen so that only blind people will be aware of it.
kangax
Most of the time not. But there are cases when information can be
perceived fully only visually and some additional content/explanation
needs to be presented to a screen reader. These cases are rare but they
do come up once in a while.
I suppose this article explains it best (and features actual examples):
<http://www.webaim.org/techniques/css/invisiblecontent/>
--
kangax
David Mark
> David Mark wrote:
> > On Apr 30, 8:53 am, kangax <kan...@gmail.com> wrote:
> >> Thomas 'PointedEars' Lahn wrote:
> >>> garey wrote:
> >> [...]
> >>>> div.extraout { position: absolute; left: -9999em; min-height: 0 }
> >>> Smart people hide the element instead of placing it in CSS hell.
> >> CSS hell? Please explain another way to "hide" an element in such way
> >> that its content is "picked up" and pronounced by screen readers.
>
> > If an element is hidden, you don't want it to be read by screen
> > readers. If it is not hidden, you certainly don't want to place it
> > off-screen so that only blind people will be aware of it.
>
> Most of the time not. But there are cases when information can be
> perceived fully only visually and some additional content/explanation
> needs to be presented to a screen reader. These cases are rare but they
> do come up once in a while.
Sure, there are exceptions. I've seen that strategy advocated as a
replacement for hidden visibility though, which it clearly is not.
>
> I suppose this article explains it best (and features actual examples):
>
> <http://www.webaim.org/techniques/css/invisiblecontent/>
No time at the moment, but beware of anything you find on the Web.
Just as with JS, there are lots of people expressing lots of ideas
about how to use CSS on the Web (and most of them are wrong.)
>
> --
> kangax
kangax
>> I suppose this article explains it best (and features actual examples):
>>
>> <http://www.webaim.org/techniques/css/invisiblecontent/>
>
> No time at the moment, but beware of anything you find on the Web.
> Just as with JS, there are lots of people expressing lots of ideas
> about how to use CSS on the Web (and most of them are wrong.)
That's true; There's plenty of bizarre explanations and workarounds
floating around. WebAIM, on the other hand, is a quite respected
resource, as far as I know. If you have any objections to the material
from that article, I would be interested to hear them.
On a side note, it would be nice if the information one can find in this
newsgroup would get more attention on the web. Cornford's and
Crockford's articles are good examples of spreading some of the
browser-scripting (or language, overall) techniques, as well as Peter
Michaux's blog (I think one of his feature detection -related articles
is how I found out about comp.lang.javascript in the first place).
Some time ago, I made a naive attempt at releasing a set of examples of
some of the common feature tests one might stumble upon. The funny thing
is that when it got to Ajaxian, some people actually argued about
sniffing being "faster" and supposedly more superior.
--
kangax
David Mark
> David Mark wrote:
> > On Apr 30, 12:47 pm, kangax <kan...@gmail.com> wrote:
> [...]
> >> I suppose this article explains it best (and features actual examples):
>
> >> <http://www.webaim.org/techniques/css/invisiblecontent/>
>
> > No time at the moment, but beware of anything you find on the Web.
> > Just as with JS, there are lots of people expressing lots of ideas
> > about how to use CSS on the Web (and most of them are wrong.)
>
> That's true; There's plenty of bizarre explanations and workarounds
> floating around. WebAIM, on the other hand, is a quite respected
> resource, as far as I know. If you have any objections to the material
> from that article, I would be interested to hear them.
I'll check it out when I get a chance.
>
> On a side note, it would be nice if the information one can find in this
> newsgroup would get more attention on the web. Cornford's and
More is always better when it comes to attention. Lots of
misconceptions to clear up at this point.
> Crockford's articles are good examples of spreading some of the
> browser-scripting (or language, overall) techniques, as well as Peter
> Michaux's blog (I think one of his feature detection -related articles
> is how I found out about comp.lang.javascript in the first place).
>
> Some time ago, I made a naive attempt at releasing a set of examples of
> some of the common feature tests one might stumble upon. The funny thing
> is that when it got to Ajaxian, some people actually argued about
> sniffing being "faster" and supposedly more superior.
Ajaxian is a rag. And that must have been some time ago as I don't
think anyone would argue for browser sniffing at this point.
Eric Bednarz
[multiple="multiple"]
>>> RTFM.
>>
>> Or STFW if you are too cheap to buy the manual that actually matters if
>> you want to discuss esoterica.
>
> Idiot.
You are a pompous wannabe-hacker permanently stuck in adolescence.
> <http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.4>
If you wanna be pragmatic, the HTML 4.01 spec is ten years old, that
section was already in the first HTML 4 spec that is eleven years old,
and if you consider WG speed it is likely that this note is about the
browser landscape twelve years ago or older. So this is supposed to back
up your statement “HTML UAs tend to choke on this”?
If you wanna be dogmatic, there are no ‘boolean attributes’ in
SGML. There’s attribute name omission for name token lists, and
historically that was *the* reason to enable SHORTTAG in the quixotic
attempt to retrofit HTML into an SGML application.
So where’s the appendix note that explains how ‘boolean attributes’
enable notation like
<td justify>
? :-)
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
> [multiple="multiple"]
>>>> RTFM.
>>> Or STFW if you are too cheap to buy the manual that actually matters if
>>> you want to discuss esoterica.
>> Idiot.
>
> You are a pompous wannabe-hacker permanently stuck in adolescence.
At least I'm not such a luser like you. I've given (you) enough hints on
where to find the relevant information, yet you've been either unable or
unwilling to look it up, and instead engage in pointless quibbling over
words without even trying to back up *your* assertions.
>> <http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.4>
>
> If you wanna be pragmatic, the HTML 4.01 spec is ten years old, that
> section was already in the first HTML 4 spec that is eleven years old,
> and if you consider WG speed it is likely that this note is about the
> browser landscape twelve years ago or older. So this is supposed to back
> up your statement “HTML UAs tend to choke on this”?
Unless someone can provide sufficient proof to the contrary. Which nobody
can, of course.
> If you wanna be dogmatic, there are no ‘boolean attributes’ in
> SGML. There’s attribute name omission for name token lists, and
> historically that was *the* reason to enable SHORTTAG in the quixotic
> attempt to retrofit HTML into an SGML application.
Interesting if true, but entirely irrelevant here. Following the HTML 4.01
Specification, Appendix B, section 3.4, has only potential advantages and no
drawbacks.
> So where’s the appendix note that explains how ‘boolean attributes’
> enable notation like
> <td justify>
> ? :-)
Hush, hush, baby.
PointedEars
kangax
>> Some time ago, I made a naive attempt at releasing a set of examples of
>> some of the common feature tests one might stumble upon. The funny thing
>> is that when it got to Ajaxian, some people actually argued about
>> sniffing being "faster" and supposedly more superior.
>
> Ajaxian is a rag. And that must have been some time ago as I don't
> think anyone would argue for browser sniffing at this point.
You'll be surprised :)
Less than a month ago someone created a jQuery plugin to emulate
text-overflow on non-supporting browsers
<http://ajaxian.com/archives/text-overflow-for-firefox-via-jquery>
Then someone in the comments says - "Because of the use of
$.browser.mozilla in the plugin, this won�t work with jQuery 1.3.2+."
A response to that comment:
<cite>
@MichaelThompson: this is why feature detection never gets you all the
way there. There�s no way to detect this feature from javascript, as it
is a purely visual feature that doesn�t affect the DOM state in any way.
</cite>
Another response made me spill my coffee:
<cite>
It�s not terribly difficult to replace jQuery�s browser detection with
your own.
For instance:
var isGecko = (!!window.Array.every || !!window.Iterator ||
!!window.getComputedStyle) && !!document.doctype && !window.opera &&
(!!window.devicePixelRatio && !!window.getMatchedCSSRules);
First group is features Gecko has introduced; second and fourth avoid
confusion with some Safari versions; third is obvious.
</cite>
I suggested to remove silly inference by testing style of an element and
an author actually did remove an inference from the script (which made
it compatible with new jQuery :))
My "solution" was:
var s = document.documentElement.style;
if (!('textOverflow' in s || 'OTextOverflow' in s)) {
// implement workaround
}
which I would now probably replace with something like:
var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
var docEl = document.documentElement, s;
if (docEl && (s = docEl.style)) {
return typeof s.textOverflow == 'string' ||
typeof s.OTextOverflow == 'string';
}
return null;
})();
I'm still not convinced that document.documentElement's style should not
be tested since HTML can not have a style attribute, but if that's a
concern, it's trivial to test an element that supports it. The problem
is that then a test would rely on `document.createElement` being available.
var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
if (/^(?:function|object|unknown)$/i.test(document.createElement)) {
var el = document.createElement('div'), s;
if (el && (s = el.style)) {
return typeof s.textOverflow == 'string' ||
typeof s.OTextOverflow == 'string';
}
}
return null;
})();
--
kangax
David Mark
> David Mark wrote:
> > On Apr 30, 8:13 pm, kangax <kan...@gmail.com> wrote:
> [...]
> >> Some time ago, I made a naive attempt at releasing a set of examples of
> >> some of the common feature tests one might stumble upon. The funny thing
> >> is that when it got to Ajaxian, some people actually argued about
> >> sniffing being "faster" and supposedly more superior.
>
> > Ajaxian is a rag. And that must have been some time ago as I don't
> > think anyone would argue for browser sniffing at this point.
>
> You'll be surprised :)
Not really.
>
> Less than a month ago someone created a jQuery plugin to emulate
> text-overflow on non-supporting browsers
> <http://ajaxian.com/archives/text-overflow-for-firefox-via-jquery>
Nobodies don't count. :)
>
> Then someone in the comments says - "Because of the use of
> $.browser.mozilla in the plugin, this won’t work with jQuery 1.3.2+."
Which isn't true (for some definition of "work" that applies to all of
the other plugins as well.)
>
> A response to that comment:
>
> <cite>
> @MichaelThompson: this is why feature detection never gets you all the
> way there. There’s no way to detect this feature from javascript, as it
> is a purely visual feature that doesn’t affect the DOM state in any way.
> </cite>
The usual BS. I saw this one (and thousands like it over the last
five years or so.)
>
> Another response made me spill my coffee:
>
> <cite>
> It’s not terribly difficult to replace jQuery’s browser detection with
> your own.
All old news. The jQuery cult preaches incompetence.
>
> For instance:
> var isGecko = (!!window.Array.every || !!window.Iterator ||
> !!window.getComputedStyle) && !!document.doctype && !window.opera &&
> (!!window.devicePixelRatio && !!window.getMatchedCSSRules);
That's a new one. What do they infer from that?
>
> First group is features Gecko has introduced; second and fourth avoid
> confusion with some Safari versions; third is obvious.
> </cite>
These are the people building major Websites today. They won't be
around much longer.
>
> I suggested to remove silly inference by testing style of an element and
> an author actually did remove an inference from the script (which made
> it compatible with new jQuery :))
Please don't help jQuery. As with Prototype, it doesn't deserve your
help.
>
> My "solution" was:
>
> var s = document.documentElement.style;
> if (!('textOverflow' in s || 'OTextOverflow' in s)) {
> // implement workaround
I assume the second is the proprietary Opera style.
>
> }
>
> which I would now probably replace with something like:
>
> var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
> var docEl = document.documentElement, s;
> if (docEl && (s = docEl.style)) {
> return typeof s.textOverflow == 'string' ||
> typeof s.OTextOverflow == 'string';
> }
> return null;
>
> })();
Something like that. So much for hysterics about browser sniffing
being needed to get "all the way there." Hopefully the readers of
that blog will get this point now.
There are indeed cases where you can't detect (or test) a feature
(e.g. PNG translucency support.) As we know, there are other ways to
make such decisions (e.g. IE conditional comments.) Often the issue
can be designed out of the system (e.g. substitute GIF's for IE < 7 in
a conditionally added style sheet.) General purpose scripts like
jQuery and its plugins don't design anything out as they want to
please as many incapable people as possible.
>
> I'm still not convinced that document.documentElement's style should not
> be tested since HTML can not have a style attribute, but if that's a
> concern, it's trivial to test an element that supports it. The problem
> is that then a test would rely on `document.createElement` being available.
Depends on the context. A recent project I worked on would have FoUC
in IE4 (or browsers that don't support
document.documentElement.style.) I can certainly live with that, so I
wouldn't consider adding a call to createElement.
>
> var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
> if (/^(?:function|object|unknown)$/i.test(document.createElement)) {
> var el = document.createElement('div'), s;
> if (el && (s = el.style)) {
> return typeof s.textOverflow == 'string' ||
> typeof s.OTextOverflow == 'string';
> }
> }
> return null;
>
> })();
Why not wait until the body is ready to test this. The only
conceivable reason for this that I can see is to emulate text overflow
with script for browsers that don't support those rules. You wouldn't
do that until the body is ready.
Also, the flag doesn't tell you much. You should create a function
(like setOpacity) rather than a flag.
kangax
>> I suggested to remove silly inference by testing style of an element and
>> an author actually did remove an inference from the script (which made
>> it compatible with new jQuery :))
>
> Please don't help jQuery. As with Prototype, it doesn't deserve your
> help.
I don't explicitly help jQuery. In this case, I saw a misconception, as
well as a trivial solution and I thought it made sense to point out more
or less robust replacement. I don't care if it's jQuery or Mootools that
this misconception is employed into; The same way any of us would
recommend a best practice to someone asking for advice in this newsgroup.
I do "help" Prototype.js because my work involves maintaining intranet
based apps that use it quite heavily. Since these apps are not for
general web and are only required to work in a limited set of clients, I
don't see a reason to wipe Prototype out (nor do I have a time to do
so). There's a lot of code and it does what it needs to do just fine
(that is, for people who use it).
I also happen to be a Prototype.js core developer (for a couple of
months now) and am trying to eliminate all of the bogus stuff from the
library. You can probably imagine that it's no easy task; Prototype
happens to penetrate an environment way too much and makes too many bold
actions. Sniffing is another problem. I removed half of it, but some
things are just impossible to get rid of, due to "specific" design of a
library. What's frustrating is that some sniffs don't even have an
explanation; I, for example, still have no idea why Prototype.js
disables element extension when userAgent looks like it's a Mobile
Safari. Changelog is hardly helpful too.
>
>> My "solution" was:
>>
>> var s = document.documentElement.style;
>> if (!('textOverflow' in s || 'OTextOverflow' in s)) {
>> // implement workaround
>
> I assume the second is the proprietary Opera style.
Yes it is.
The problem I see here is that if Mozilla decides to implement
text-overflow via its proprietary version, e.g. - "MozTextOverflow" -
the code would need to be changed. Same could happen with Webkit,
Konqueror or whatever else. This kind of sucks.
Do you think it would make sense to include those in a test right away
(as an intelligent guess)?
It feels sloppy and it's not clear when to "stop". It's quite a mess
with all these proprietary CSS3 patching that browser vendors rush to
implement but are cautious to mess with currently draft CSS3 names.
var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
var docEl = document.documentElement, s;
if (docEl && (s = docEl.style)) {
return typeof s.textOverflow == 'string' // CSS3
|| typeof s.OTextOverflow == 'string' // opera
|| typeof s.MozTextOverflow == 'string' // mozilla
|| typeof s.WebkitTextOverflow == 'string' // webkit
|| typeof s.KhtmlTextOverflow == 'string'; // khtml
}
return null;
})();
Isn't there also "-ms" and "-icab"? :)
>
>> }
>>
>> which I would now probably replace with something like:
>>
>> var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
>> var docEl = document.documentElement, s;
>> if (docEl && (s = docEl.style)) {
>> return typeof s.textOverflow == 'string' ||
>> typeof s.OTextOverflow == 'string';
>> }
>> return null;
>>
>> })();
>
> Something like that. So much for hysterics about browser sniffing
> being needed to get "all the way there." Hopefully the readers of
> that blog will get this point now.
>
> There are indeed cases where you can't detect (or test) a feature
> (e.g. PNG translucency support.) As we know, there are other ways to
True. Visual aspects can not be tested. Iframe shim for IE (needed to
prevent SELECT elements leaking through) is a good example. Then there
are key events discrepancies which are not easy to test either (maybe
only by testing user-generated key event but that could be quite a hassle)
> make such decisions (e.g. IE conditional comments.) Often the issue
> can be designed out of the system (e.g. substitute GIF's for IE < 7 in
> a conditionally added style sheet.) General purpose scripts like
> jQuery and its plugins don't design anything out as they want to
> please as many incapable people as possible.
>
>> I'm still not convinced that document.documentElement's style should not
>> be tested since HTML can not have a style attribute, but if that's a
>> concern, it's trivial to test an element that supports it. The problem
>> is that then a test would rely on `document.createElement` being available.
>
> Depends on the context. A recent project I worked on would have FoUC
> in IE4 (or browsers that don't support
Interesting. So FoUC would occur when `style` property of a
`document.documentElement` was accessed?
I was also thinking about a more compatible alternative of getting a
"dummy" element for inspection:
function getElement(){
var el = document.documentElement;
if (el) return el;
if (document.createElement) {
el = document.createElement('div');
if (el) return el;
}
}
...
var el = getElement();
if (el && el.style) {
...
}
or maybe a more specific `getStyle` helper -
function getStyle(){
var el = document.documentElement, s;
if (!el && document.createElement) {
el = document.createElement('div');
}
if (el && (s = el.style)) return s;
}
...
var style = getStyle();
if (style) {
...
}
> document.documentElement.style.) I can certainly live with that, so I
> wouldn't consider adding a call to createElement.
>
>> var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
>> if (/^(?:function|object|unknown)$/i.test(document.createElement)) {
>> var el = document.createElement('div'), s;
>> if (el && (s = el.style)) {
>> return typeof s.textOverflow == 'string' ||
>> typeof s.OTextOverflow == 'string';
>> }
>> }
>> return null;
>>
>> })();
>
> Why not wait until the body is ready to test this. The only
> conceivable reason for this that I can see is to emulate text overflow
> with script for browsers that don't support those rules. You wouldn't
> do that until the body is ready.
That's an option, of course. I just don't like to use `body` when not
absolutely needed (for the reason of making it more compatible and
portable). On the other hand, it's all about context, as you said. If
I'm writing this test inline and body is already available, i would
probably use it.
>
> Also, the flag doesn't tell you much. You should create a function
> (like setOpacity) rather than a flag.
Which flag are you talking about?
--
kangax
David Mark
> David Mark wrote:
> > On May 2, 11:46 pm, kangax <kan...@gmail.com> wrote:
> [...]
> >> I suggested to remove silly inference by testing style of an element and
> >> an author actually did remove an inference from the script (which made
> >> it compatible with new jQuery :))
>
> > Please don't help jQuery. As with Prototype, it doesn't deserve your
> > help.
>
> I don't explicitly help jQuery. In this case, I saw a misconception, as
> well as a trivial solution and I thought it made sense to point out more
> or less robust replacement. I don't care if it's jQuery or Mootools that
> this misconception is employed into; The same way any of us would
> recommend a best practice to someone asking for advice in this newsgroup.
I was half-kidding. But you do work on Prototype, which seems like
masochism to me.
>
> I do "help" Prototype.js because my work involves maintaining intranet
> based apps that use it quite heavily. Since these apps are not for
> general web and are only required to work in a limited set of clients, I
> don't see a reason to wipe Prototype out (nor do I have a time to do
> so). There's a lot of code and it does what it needs to do just fine
> (that is, for people who use it).
You should definitely wipe it out of your projects, rather than try to
keep it up.
>
> I also happen to be a Prototype.js core developer (for a couple of
> months now) and am trying to eliminate all of the bogus stuff from the
> library. You can probably imagine that it's no easy task;
This is what I'm talking about.
> Prototype
> happens to penetrate an environment way too much and makes too many bold
> actions. Sniffing is another problem. I removed half of it, but some
> things are just impossible to get rid of, due to "specific" design of a
> library. What's frustrating is that some sniffs don't even have an
> explanation; I, for example, still have no idea why Prototype.js
> disables element extension when userAgent looks like it's a Mobile
> Safari. Changelog is hardly helpful too.
Right. It's a derelict at this point. Abandon ship.
>
>
>
> >> My "solution" was:
>
> >> var s = document.documentElement.style;
> >> if (!('textOverflow' in s || 'OTextOverflow' in s)) {
> >> // implement workaround
>
> > I assume the second is the proprietary Opera style.
>
> Yes it is.
>
> The problem I see here is that if Mozilla decides to implement
> text-overflow via its proprietary version, e.g. - "MozTextOverflow" -
> the code would need to be changed. Same could happen with Webkit,
> Konqueror or whatever else. This kind of sucks.
I doubt it. The next browser versions will likely support the CSS3
rule.
>
> Do you think it would make sense to include those in a test right away
> (as an intelligent guess)?
Not at this time.
>
> It feels sloppy and it's not clear when to "stop". It's quite a mess
> with all these proprietary CSS3 patching that browser vendors rush to
> implement but are cautious to mess with currently draft CSS3 names.
So why are you trying to mess with it in script? Opacity I can see
(for animations.) Just put the CSS3 rule in your style sheet (along
with the Opera rendition if you must.)
>
> var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
> var docEl = document.documentElement, s;
> if (docEl && (s = docEl.style)) {
> return typeof s.textOverflow == 'string' // CSS3
> || typeof s.OTextOverflow == 'string' // opera
> || typeof s.MozTextOverflow == 'string' // mozilla
> || typeof s.WebkitTextOverflow == 'string' // webkit
> || typeof s.KhtmlTextOverflow == 'string'; // khtml
> }
> return null;
>
> })();
>
> Isn't there also "-ms" and "-icab"? :)
Not that I know of.
No, I was referring to a specific case where the absence of
documentElement.style would result in FoUC and that would be the only
effect on the behavior.
>
> I was also thinking about a more compatible alternative of getting a
> "dummy" element for inspection:
>
> function getElement(){
> var el = document.documentElement;
> if (el) return el;
> if (document.createElement) {
> el = document.createElement('div');
> if (el) return el;
> }}
>
If you absolutely must get a reference to an arbitrary element before
the body is ready, you should use createElement. It is the best bet
anyway as you don't know what documentElement might hold (could have
been modified by other scripts.)
> ...
> var el = getElement();
> if (el && el.style) {
> ...
>
> }
>
> or maybe a more specific `getStyle` helper -
>
> function getStyle(){
> var el = document.documentElement, s;
> if (!el && document.createElement) {
> el = document.createElement('div');
> }
> if (el && (s = el.style)) return s;}
Of course, you don't normally need such information until the body is
ready, so you could just use the body instead of the documentElement.
The only common case I can think of is preventing FoUC.
>
> ...
> var style = getStyle();
> if (style) {
> ...
>
>
>
> }
> > document.documentElement.style.) I can certainly live with that, so I
> > wouldn't consider adding a call to createElement.
>
> >> var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
> >> if (/^(?:function|object|unknown)$/i.test(document.createElement)) {
> >> var el = document.createElement('div'), s;
> >> if (el && (s = el.style)) {
> >> return typeof s.textOverflow == 'string' ||
> >> typeof s.OTextOverflow == 'string';
> >> }
> >> }
> >> return null;
>
> >> })();
>
> > Why not wait until the body is ready to test this. The only
> > conceivable reason for this that I can see is to emulate text overflow
> > with script for browsers that don't support those rules. You wouldn't
> > do that until the body is ready.
>
> That's an option, of course. I just don't like to use `body` when not
> absolutely needed (for the reason of making it more compatible and
> portable).
How does that make it more compatible or portable? Do you mean
portable to other parts of the document (e.g. the head?)
> On the other hand, it's all about context, as you said. If
> I'm writing this test inline and body is already available, i would
> probably use it.
A load (or DOMContentLoaded) listener is the more likely place to
inspect styles.
>
>
>
> > Also, the flag doesn't tell you much. You should create a function
> > (like setOpacity) rather than a flag.
>
> Which flag are you talking about?
IS_TEXT_OVERFLOW_SUPPORTED tells me that one of the two styles is
present. What do I do now?
kangax
> On May 3, 4:10 pm, kangax <kan...@gmail.com> wrote:
>> David Mark wrote:
>>> On May 2, 11:46 pm, kangax <kan...@gmail.com> wrote:
>> [...]
>>>> I suggested to remove silly inference by testing style of an element and
>>>> an author actually did remove an inference from the script (which made
>>>> it compatible with new jQuery :))
>>> Please don't help jQuery. As with Prototype, it doesn't deserve your
>>> help.
>> I don't explicitly help jQuery. In this case, I saw a misconception, as
>> well as a trivial solution and I thought it made sense to point out more
>> or less robust replacement. I don't care if it's jQuery or Mootools that
>> this misconception is employed into; The same way any of us would
>> recommend a best practice to someone asking for advice in this newsgroup.
>
> I was half-kidding. But you do work on Prototype, which seems like
> masochism to me.
I had to make our apps work in IE8. Removing sniffing from Prototype
worked a magic (no surprise there). It was also a fun and useful
exercise that taught me about feature detection a bit more. I made some
mistakes of course but the result is probably better than parsing poor
userAgent string for no apparent reason.
[...]
>> The problem I see here is that if Mozilla decides to implement
>> text-overflow via its proprietary version, e.g. - "MozTextOverflow" -
>> the code would need to be changed. Same could happen with Webkit,
>> Konqueror or whatever else. This kind of sucks.
>
> I doubt it. The next browser versions will likely support the CSS3
> rule.
But there's a chance that CSS3 does not become final before Mozilla (or
any other browser) decides to implement it, isn't there?
>
>> Do you think it would make sense to include those in a test right away
>> (as an intelligent guess)?
>
> Not at this time.
Ok.
>
>> It feels sloppy and it's not clear when to "stop". It's quite a mess
>> with all these proprietary CSS3 patching that browser vendors rush to
>> implement but are cautious to mess with currently draft CSS3 names.
>
> So why are you trying to mess with it in script? Opacity I can see
> (for animations.) Just put the CSS3 rule in your style sheet (along
> with the Opera rendition if you must.)
To emulate it in Javascript, as I understand it.
>
>> var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
>> var docEl = document.documentElement, s;
>> if (docEl && (s = docEl.style)) {
>> return typeof s.textOverflow == 'string' // CSS3
>> || typeof s.OTextOverflow == 'string' // opera
>> || typeof s.MozTextOverflow == 'string' // mozilla
>> || typeof s.WebkitTextOverflow == 'string' // webkit
>> || typeof s.KhtmlTextOverflow == 'string'; // khtml
>> }
>> return null;
>>
>> })();
>>
>> Isn't there also "-ms" and "-icab"? :)
>
> Not that I know of.
IE8 switched to vendor-specific names for some names, like infamous
filter <http://msdn.microsoft.com/en-us/library/ms530752(VS.85).aspx>. I
think they actually recommended using "-ms-" prefixed names instead of
their non-standard versions.
It appears that there's "-ms-text-overflow" as well
<https://developer.mozilla.org/en/CSS/text-overflow>
[...]
>>> Depends on the context. A recent project I worked on would have FoUC
>>> in IE4 (or browsers that don't support
>> Interesting. So FoUC would occur when `style` property of a
>> `document.documentElement` was accessed?
>
> No, I was referring to a specific case where the absence of
> documentElement.style would result in FoUC and that would be the only
> effect on the behavior.
I see.
>
>> I was also thinking about a more compatible alternative of getting a
>> "dummy" element for inspection:
>>
>> function getElement(){
>> var el = document.documentElement;
>> if (el) return el;
>> if (document.createElement) {
>> el = document.createElement('div');
>> if (el) return el;
>> }}
>>
>
> If you absolutely must get a reference to an arbitrary element before
> the body is ready, you should use createElement. It is the best bet
> anyway as you don't know what documentElement might hold (could have
> been modified by other scripts.)
Good point, although it again depends on a context, of course. In this
case, for example, it seems unlikely that one of the style properties
was removed or replaced with another value, as in:
document.documentElement.style.textOverflow = 'muahaha';
Although the fact that some browsers allow an arbitrary property to be
assigned to a style object proves that it's a good idea to create a
dummy element from the scratch. Too bad even dummy element can be "evil":
// in Firefox 3.0.10
HTMLDivElement.prototype.filter = 'alpha(opacity=50)';
document.createElement('div').filter; // "alpha(opacity=50)"
I had a rule about creating an element dynamically only when it (or one
of its properties/attributes) needed to be modified and used
`documentElement` for any "read-only" test.
[...]
>>> Why not wait until the body is ready to test this. The only
>>> conceivable reason for this that I can see is to emulate text overflow
>>> with script for browsers that don't support those rules. You wouldn't
>>> do that until the body is ready.
>> That's an option, of course. I just don't like to use `body` when not
>> absolutely needed (for the reason of making it more compatible and
>> portable).
>
> How does that make it more compatible or portable? Do you mean
> portable to other parts of the document (e.g. the head?)
Yes, I often don't use "onload" at all (so body is not available), but
assign event handlers globally and use event delegation. This way you
avoid any problems that arise from load/DOMContentLoaded.
>
>> On the other hand, it's all about context, as you said. If
>> I'm writing this test inline and body is already available, i would
>> probably use it.
>
> A load (or DOMContentLoaded) listener is the more likely place to
> inspect styles.
>
>>
>>
>>> Also, the flag doesn't tell you much. You should create a function
>>> (like setOpacity) rather than a flag.
>> Which flag are you talking about?
>
> IS_TEXT_OVERFLOW_SUPPORTED tells me that one of the two styles is
> present. What do I do now?
You know that it's not supported and emulate it with
jQue^H^H^H^HJavascript, I suppose :)
--
kangax
David Mark
> David Mark wrote:
> > On May 3, 4:10 pm, kangax <kan...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On May 2, 11:46 pm, kangax <kan...@gmail.com> wrote:
> >> [...]
> >>>> I suggested to remove silly inference by testing style of an element and
> >>>> an author actually did remove an inference from the script (which made
> >>>> it compatible with new jQuery :))
> >>> Please don't help jQuery. As with Prototype, it doesn't deserve your
> >>> help.
> >> I don't explicitly help jQuery. In this case, I saw a misconception, as
> >> well as a trivial solution and I thought it made sense to point out more
> >> or less robust replacement. I don't care if it's jQuery or Mootools that
> >> this misconception is employed into; The same way any of us would
> >> recommend a best practice to someone asking for advice in this newsgroup.
>
> > I was half-kidding. But you do work on Prototype, which seems like
> > masochism to me.
>
> I had to make our apps work in IE8. Removing sniffing from Prototype
> worked a magic (no surprise there). It was also a fun and useful
> exercise that taught me about feature detection a bit more. I made some
> mistakes of course but the result is probably better than parsing poor
> userAgent string for no apparent reason.
Virtually anything is better than parsing the UA string. The fact
that Prototype still does that, long after IE8 was released (and ten
years since IE changed significantly) should tell you it is over. You
can't keep it up, certainly not if you have to confine your changes to
the needs of whatever is left of the community.
>
> [...]
>
> >> The problem I see here is that if Mozilla decides to implement
> >> text-overflow via its proprietary version, e.g. - "MozTextOverflow" -
> >> the code would need to be changed. Same could happen with Webkit,
> >> Konqueror or whatever else. This kind of sucks.
>
> > I doubt it. The next browser versions will likely support the CSS3
> > rule.
>
> But there's a chance that CSS3 does not become final before Mozilla (or
> any other browser) decides to implement it, isn't there?
It's possible. I just don't see them adding MozTextOverflow without
textOverflow. You could write one generic function to use for all
such on-the-fence styles (e.g. opacity, rounded corners.)
>
>
>
> >> Do you think it would make sense to include those in a test right away
> >> (as an intelligent guess)?
>
> > Not at this time.
>
> Ok.
>
>
>
> >> It feels sloppy and it's not clear when to "stop". It's quite a mess
> >> with all these proprietary CSS3 patching that browser vendors rush to
> >> implement but are cautious to mess with currently draft CSS3 names.
>
> > So why are you trying to mess with it in script? Opacity I can see
> > (for animations.) Just put the CSS3 rule in your style sheet (along
> > with the Opera rendition if you must.)
>
> To emulate it in Javascript, as I understand it.
Oh, the OP. I thought you were working on a patch for Prototype.
>
>
>
>
>
> >> var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
> >> var docEl = document.documentElement, s;
> >> if (docEl && (s = docEl.style)) {
> >> return typeof s.textOverflow == 'string' // CSS3
> >> || typeof s.OTextOverflow == 'string' // opera
> >> || typeof s.MozTextOverflow == 'string' // mozilla
> >> || typeof s.WebkitTextOverflow == 'string' // webkit
> >> || typeof s.KhtmlTextOverflow == 'string'; // khtml
> >> }
> >> return null;
>
> >> })();
>
> >> Isn't there also "-ms" and "-icab"? :)
>
> > Not that I know of.
>
> IE8 switched to vendor-specific names for some names, like infamous
> filter <http://msdn.microsoft.com/en-us/library/ms530752(VS.85).aspx>. I
> think they actually recommended using "-ms-" prefixed names instead of
> their non-standard versions.
Never used them.
>
> It appears that there's "-ms-text-overflow" as well
> <https://developer.mozilla.org/en/CSS/text-overflow>
Fair enough. That I would use as there is certainly no text-overflow
in IE.
Simple enough. Throw out all scripts featuring such patterns (just
like the ones that make inferences based on navigator.userAgent.)
>
> I had a rule about creating an element dynamically only when it (or one
> of its properties/attributes) needed to be modified and used
> `documentElement` for any "read-only" test.
>
> [...]
>
> >>> Why not wait until the body is ready to test this. The only
> >>> conceivable reason for this that I can see is to emulate text overflow
> >>> with script for browsers that don't support those rules. You wouldn't
> >>> do that until the body is ready.
> >> That's an option, of course. I just don't like to use `body` when not
> >> absolutely needed (for the reason of making it more compatible and
> >> portable).
>
> > How does that make it more compatible or portable? Do you mean
> > portable to other parts of the document (e.g. the head?)
>
> Yes, I often don't use "onload" at all (so body is not available), but
> assign event handlers globally and use event delegation. This way you
> avoid any problems that arise from load/DOMContentLoaded.
I didn't follow that exactly. When do you attach listeners?
>
>
>
>
>
> >> On the other hand, it's all about context, as you said. If
> >> I'm writing this test inline and body is already available, i would
> >> probably use it.
>
> > A load (or DOMContentLoaded) listener is the more likely place to
> > inspect styles.
>
> >>> Also, the flag doesn't tell you much. You should create a function
> >>> (like setOpacity) rather than a flag.
> >> Which flag are you talking about?
>
> > IS_TEXT_OVERFLOW_SUPPORTED tells me that one of the two styles is
> > present. What do I do now?
>
> You know that it's not supported and emulate it with
> jQue^H^H^H^HJavascript, I suppose :)
Right. I forgot what the OP was doing. Still a function makes
sense. One branch sets style properties, the other trims the text
content and adds an ellipsis when needed. ISTM I had to do something
similar recently. I'll have to look into -ms-text-overflow.
Would be nice if they had -ms-border-radius or -ms-transition (instead
of filter.) But what I would really like to see is -moz-transition.
kangax
> On May 3, 7:57 pm, kangax <kan...@gmail.com> wrote:
[...]
>> But there's a chance that CSS3 does not become final before Mozilla (or
>> any other browser) decides to implement it, isn't there?
>
> It's possible. I just don't see them adding MozTextOverflow without
> textOverflow. You could write one generic function to use for all
> such on-the-fence styles (e.g. opacity, rounded corners.)
That's a good idea.
[...]
>> Although the fact that some browsers allow an arbitrary property to be
>> assigned to a style object proves that it's a good idea to create a
>> dummy element from the scratch. Too bad even dummy element can be "evil":
>>
>> // in Firefox 3.0.10
>> HTMLDivElement.prototype.filter = 'alpha(opacity=50)';
>> document.createElement('div').filter; // "alpha(opacity=50)"
>
> Simple enough. Throw out all scripts featuring such patterns (just
> like the ones that make inferences based on navigator.userAgent.)
No doubt about that, but I was talking about an uncontrolled
environment. The same way you make your scripts work with augmented
`Object.prototype` (if I'm not mistaken) even though scripts that
augment it should be considered dangerous as well.
[...]
>> Yes, I often don't use "onload" at all (so body is not available), but
>> assign event handlers globally and use event delegation. This way you
>> avoid any problems that arise from load/DOMContentLoaded.
>
> I didn't follow that exactly. When do you attach listeners?
To a `document.documentElement` at any time and use event delegation
(for any event that bubbles, of course).
[...]
>> You know that it's not supported and emulate it with
>> jQue^H^H^H^HJavascript, I suppose :)
>
> Right. I forgot what the OP was doing. Still a function makes
> sense. One branch sets style properties, the other trims the text
> content and adds an ellipsis when needed. ISTM I had to do something
> similar recently. I'll have to look into -ms-text-overflow.
>
> Would be nice if they had -ms-border-radius or -ms-transition (instead
Yeah, I can't even predict when we might see something like that from MS :)
> of filter.) But what I would really like to see is -moz-transition.
You're certainly not the only one who wants them.
<https://bugzilla.mozilla.org/show_bug.cgi?id=435441> with 19 votes (I
just voted as well)
--
kangax
Thomas 'PointedEars' Lahn
> David Mark wrote:
>> On May 3, 7:57 pm, kangax <kan...@gmail.com> wrote:
> [...]
>>> But there's a chance that CSS3 does not become final before Mozilla (or
>>> any other browser) decides to implement it, isn't there?
>> It's possible. I just don't see them adding MozTextOverflow without
>> textOverflow. You could write one generic function to use for all
>> such on-the-fence styles (e.g. opacity, rounded corners.)
>
> That's a good idea.
JFTR: The Test Suites[1] show that Gecko has partial CSS3 support already
(CSS3 Selectors in particular). As for what is required before CSS3 can
become a Recommendation please see the "Status of this document" sections of
the respective CSS3 modules and the W3C Process Document.
[1] <http://www.w3.org/Style/CSS/Test/>
>>> Although the fact that some browsers allow an arbitrary property to be
>>> assigned to a style object proves that it's a good idea to create a
>>> dummy element from the scratch. Too bad even dummy element can be "evil":
>>>
>>> // in Firefox 3.0.10
>>> HTMLDivElement.prototype.filter = 'alpha(opacity=50)';
>>> document.createElement('div').filter; // "alpha(opacity=50)"
>> Simple enough. Throw out all scripts featuring such patterns (just
>> like the ones that make inferences based on navigator.userAgent.)
>
> No doubt about that, but I was talking about an uncontrolled
> environment.
You mean "controlled"?
> The same way you make your scripts work with augmented `Object.prototype`
The same way?
> (if I'm not mistaken)
Probably you are.
> even though scripts that augment it should be considered dangerous as well.
Not dangerous (there is no danger in a runtime error), but inappropriate
(because either it breaks for-in iteration or it makes it considerably less
efficient), and therefore to be avoided.
>>> Yes, I often don't use "onload" at all (so body is not available), but
>>> assign event handlers globally and use event delegation. This way you
>>> avoid any problems that arise from load/DOMContentLoaded.
>> I didn't follow that exactly. When do you attach listeners?
>
> To a `document.documentElement` at any time and use event delegation
> (for any event that bubbles, of course).
I don't think that is a reasonable or compatible approach.
>> [..] But what I would really like to see is -moz-transition.
>
> You're certainly not the only one who wants them.
> <https://bugzilla.mozilla.org/show_bug.cgi?id=435441> with 19 votes (I
> just voted as well)
Thanks for the pointer.
PointedEars
kangax
> kangax wrote:
>> David Mark wrote:
>>> On May 3, 7:57 pm, kangax <kan...@gmail.com> wrote:
>> [...]
>>>> But there's a chance that CSS3 does not become final before Mozilla (or
>>>> any other browser) decides to implement it, isn't there?
>>> It's possible. I just don't see them adding MozTextOverflow without
>>> textOverflow. You could write one generic function to use for all
>>> such on-the-fence styles (e.g. opacity, rounded corners.)
>> That's a good idea.
>
> JFTR: The Test Suites[1] show that Gecko has partial CSS3 support already
> (CSS3 Selectors in particular). As for what is required before CSS3 can
> become a Recommendation please see the "Status of this document" sections of
> the respective CSS3 modules and the W3C Process Document.
>
> [1] <http://www.w3.org/Style/CSS/Test/>
Good to know. Thanks.
>
>>>> Although the fact that some browsers allow an arbitrary property to be
>>>> assigned to a style object proves that it's a good idea to create a
>>>> dummy element from the scratch. Too bad even dummy element can be "evil":
>>>>
>>>> // in Firefox 3.0.10
>>>> HTMLDivElement.prototype.filter = 'alpha(opacity=50)';
>>>> document.createElement('div').filter; // "alpha(opacity=50)"
>>> Simple enough. Throw out all scripts featuring such patterns (just
>>> like the ones that make inferences based on navigator.userAgent.)
>> No doubt about that, but I was talking about an uncontrolled
>> environment.
>
> You mean "controlled"?
I mean "uncontrolled"; an environment where you don't "control" all (or
a subset) of the scripts running on a page (i.e. scripts authored by
someone else).
>
>> The same way you make your scripts work with augmented `Object.prototype`
>
> The same way?
Yes.
By using `Object.prototype.hasOwnProperty`, for example; or, more
likely, some form of its emulation. "My Library" uses `isOwnProperty` in
loops, which is implemented as -
var isOwnProperty = function(o, p) {
return typeof o.constructor.prototype[p] == 'undefined';
};
I'm not sure if accessing a property off of `constructor` without first
testing for its existence (given that host objects might not implement
it) is the safest way to go, but apparently it works as it is.
>
>> (if I'm not mistaken)
>
> Probably you are.
>
>> even though scripts that augment it should be considered dangerous as well.
>
> Not dangerous (there is no danger in a runtime error), but inappropriate
There's no danger in runtime error? Isn't the main reason for employing
`isHost*` methods is to prevent runtime errors and return silently?
> (because either it breaks for-in iteration or it makes it considerably less
> efficient), and therefore to be avoided.
>
>>>> Yes, I often don't use "onload" at all (so body is not available), but
>>>> assign event handlers globally and use event delegation. This way you
>>>> avoid any problems that arise from load/DOMContentLoaded.
>>> I didn't follow that exactly. When do you attach listeners?
>> To a `document.documentElement` at any time and use event delegation
>> (for any event that bubbles, of course).
>
> I don't think that is a reasonable or compatible approach.
Why?
[...]
--
kangax
David Mark
That's the old one. I updated it recently.
>
> I'm not sure if accessing a property off of `constructor` without first
> testing for its existence (given that host objects might not implement
> it) is the safest way to go, but apparently it works as it is.
You definitely don't use isOwnProperty with *host* objects. Should be
documented of course.
>
>
>
> >> (if I'm not mistaken)
>
> > Probably you are.
>
> >> even though scripts that augment it should be considered dangerous as well.
>
> > Not dangerous (there is no danger in a runtime error), but inappropriate
>
> There's no danger in runtime error? Isn't the main reason for employing
> `isHost*` methods is to prevent runtime errors and return silently?
Thomas is talking about augmenting the prototypes of Object objects,
not host objects.
>
> > (because either it breaks for-in iteration or it makes it considerably less
> > efficient), and therefore to be avoided.
>
> >>>> Yes, I often don't use "onload" at all (so body is not available), but
> >>>> assign event handlers globally and use event delegation. This way you
> >>>> avoid any problems that arise from load/DOMContentLoaded.
> >>> I didn't follow that exactly. When do you attach listeners?
> >> To a `document.documentElement` at any time and use event delegation
> >> (for any event that bubbles, of course).
>
> > I don't think that is a reasonable or compatible approach.
>
> Why?
It is a bit odd.
kangax
>> By using `Object.prototype.hasOwnProperty`, for example; or, more
>> likely, some form of its emulation. "My Library" uses `isOwnProperty` in
>> loops, which is implemented as -
>>
>> var isOwnProperty = function(o, p) {
>> return typeof o.constructor.prototype[p] == 'undefined';
>>
>> };
>
> That's the old one. I updated it recently.
Ok. I just downloaded latest version and it does indeed differ a bit.
[...]
>> There's no danger in runtime error? Isn't the main reason for employing
>> `isHost*` methods is to prevent runtime errors and return silently?
>
> Thomas is talking about augmenting the prototypes of Object objects,
> not host objects.
Understood.
>
>>> (because either it breaks for-in iteration or it makes it considerably less
>>> efficient), and therefore to be avoided.
>>>>>> Yes, I often don't use "onload" at all (so body is not available), but
>>>>>> assign event handlers globally and use event delegation. This way you
>>>>>> avoid any problems that arise from load/DOMContentLoaded.
>>>>> I didn't follow that exactly. When do you attach listeners?
>>>> To a `document.documentElement` at any time and use event delegation
>>>> (for any event that bubbles, of course).
>>> I don't think that is a reasonable or compatible approach.
>> Why?
>
> It is a bit odd.
An advantage of this approach, as I see it, is that I don't have to wait
for "load" event (which could happen relatively late) or fiddle with
"DOMContentLoaded" peculiarities across browsers.
<head>
...
<script type="text/javascript">
(function(){
var docEl = document.documentElement;
if (docEl) {
addEvent(docEl, function(e) {
var target = getTarget(e || window.event);
// branch based on what target is
})
}
})();
</script>
</head>
What are the downsides?
--
kangax
kangax
[...]
> <head>
> ...
> <script type="text/javascript">
> (function(){
> var docEl = document.documentElement;
> if (docEl) {
> addEvent(docEl, function(e) {
addEvent(docEl, 'click', function(e) {
// ...
});
[...]
--
kangax
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> kangax wrote:
>>> David Mark wrote:
>>>> On May 3, 7:57 pm, kangax <kan...@gmail.com> wrote:
>>>>> Although the fact that some browsers allow an arbitrary property to be
>>>>> assigned to a style object proves that it's a good idea to create a
>>>>> dummy element from the scratch. Too bad even dummy element can be "evil":
>>>>>
>>>>> // in Firefox 3.0.10
>>>>> HTMLDivElement.prototype.filter = 'alpha(opacity=50)';
>>>>> document.createElement('div').filter; // "alpha(opacity=50)"
>>>> Simple enough. Throw out all scripts featuring such patterns (just
>>>> like the ones that make inferences based on navigator.userAgent.)
>>> No doubt about that, but I was talking about an uncontrolled
>>> environment.
>> You mean "controlled"?
>
> I mean "uncontrolled"; an environment where you don't "control" all (or
> a subset) of the scripts running on a page (i.e. scripts authored by
> someone else).
The cause of our misunderstanding is that you assume that this possibility
exists. However, IMO it doesn't; neither are you required to run such
scripts nor are you required, if you run them, to keep going with their
augmentation should it turn out that it hinders the efficiency or
effectiveness of your scripts. As David said, when you encounter this
pattern (relying solely on the augmentation of the prototypes of host
objects), you better throw the script out.
Therefore, I understood "controlled" with regard to the user agents that may
be used in that environment: One would use the above code (as it is) only in
a controlled environment, if that; that is, where there are two groups of
UAs: one group that does not support Microsoft filters but supports the
augmentation of the prototypes of host objects, and another group that
supports the augmentation of the prototypes of host objects *and* implements
Microsoft filters. In an uncontrolled environment (AIUI), though, there is
at least a third group to which none of the above applies.
>>> The same way you make your scripts work with augmented `Object.prototype`
>> The same way?
>
> Yes.
>
> By using `Object.prototype.hasOwnProperty`, for example;
That is hardly "the same way" in any sense of the word. You were talking
about the augmentation of the prototypes of host objects, not about how to
deal with it.
> or, more likely, some form of its emulation. "My Library" uses
> `isOwnProperty` in loops, which is implemented as -
>
> var isOwnProperty = function(o, p) {
> return typeof o.constructor.prototype[p] == 'undefined';
> };
>
> I'm not sure if accessing a property off of `constructor` without first
> testing for its existence (given that host objects might not implement
> it) is the safest way to go, but apparently it works as it is.
"Apparently" jQuery < 1.3 "worked" before IE 8. This should give you pause.
>>> even though scripts that augment it should be considered dangerous as well.
>> Not dangerous (there is no danger in a runtime error), but inappropriate
>
> There's no danger in runtime error?
Mind your words. What possible *danger* is there? A runtime error is an
avoidable inconvenience, but it poses no danger in and of itself.
> Isn't the main reason for employing `isHost*` methods is to prevent runtime
> errors and return silently?
Non sequitur.
>> (because either it breaks for-in iteration or it makes it considerably less
>> efficient), and therefore to be avoided.
>>
>>>>> Yes, I often don't use "onload" at all (so body is not available), but
>>>>> assign event handlers globally and use event delegation. This way you
>>>>> avoid any problems that arise from load/DOMContentLoaded.
>>>> I didn't follow that exactly. When do you attach listeners?
>>> To a `document.documentElement` at any time and use event delegation
>>> (for any event that bubbles, of course).
>> I don't think that is a reasonable or compatible approach.
>
> Why?
Proprietary DOM implementations may not consider the root element an event
target for an event, and AIUI even standards-compliant DOM implementations
do not need to. Insofar the "weirdness" of this approach constitutes an
argument against it.
<http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTypes-complete>
PointedEars
Thomas 'PointedEars' Lahn
> kangax wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> kangax wrote:
>>>> even though scripts that augment it should be considered dangerous as well.
>>> Not dangerous (there is no danger in a runtime error), but inappropriate
>> There's no danger in runtime error?
>
> Mind your words. What possible *danger* is there? A runtime error is an
> avoidable inconvenience, but it poses no danger in and of itself.
JFTR: As I can see now that several English idioms starting with "Mind your
..." are intended to be rather impolite, let it be clear that no offense was
meant. Instead, I meant to say "you should take more care of which words
you are using, for they have a certain meaning attached."
PointedEars
kangax
> kangax wrote:
>> I mean "uncontrolled"; an environment where you don't "control" all (or
>> a subset) of the scripts running on a page (i.e. scripts authored by
>> someone else).
>
> The cause of our misunderstanding is that you assume that this possibility
> exists. However, IMO it doesn't; neither are you required to run such
> scripts nor are you required, if you run them, to keep going with their
> augmentation should it turn out that it hinders the efficiency or
> effectiveness of your scripts. As David said, when you encounter this
> pattern (relying solely on the augmentation of the prototypes of host
> objects), you better throw the script out.
The "possibility" was mentioned in a conversation. I didn't assume its
existence ;)
David said:
| If you absolutely must get a reference to an arbitrary element before
| the body is ready, you should use createElement. It is the best bet
| anyway as you don't know what documentElement might hold (could have
| been modified by other scripts.)
So his point, as you can see, is that a `documentElement` or
`documentElement.style` (which we might want to analyze) could have been
*modified by other scripts*
This is a reasonable precaution of course. My point was merely to point
out that if *other script* was able to modify `documentElement`, there's
no guarantee that it hasn't modified, say, `HTMLElement.prototype`,
making `createElement`-based testing just as unreliable as
`documentElement` one.
Having said that, I do agree that creating a new element is safer when
it comes to ensuring "purity" of an element or any of its properties.
I'm just not sure *how much safer* it is and whether the difference is
large enough for us to care about it. What are the chances of someone
assigning a string value to a "textOverflow" property of a
`document.documentElement`'s style object and so "breaking" `typeof
document.documentElement.style.textOverflow == 'string'` test? Are the
chances lower than someone assigning to `HTMLElement`'s prototype -
`HTMLElement.prototype.textOverflow = <string-type value>`?
It's just good to understand that even testing new elements can lead to
false positives.
As to whether the possibility exists, I can imagine a script such as
google maps one augmenting host object's prototype (of course, google
maps script doesn't augment prototypes, afaik) and me being assigned to
integrate such script into our app. Unless there's a viable alternative,
I won't have much choice.
Does this explain my line of thinking better?
>
> Therefore, I understood "controlled" with regard to the user agents that may
> be used in that environment: One would use the above code (as it is) only in
> a controlled environment, if that; that is, where there are two groups of
> UAs: one group that does not support Microsoft filters but supports the
> augmentation of the prototypes of host objects, and another group that
> supports the augmentation of the prototypes of host objects *and* implements
> Microsoft filters. In an uncontrolled environment (AIUI), though, there is
> at least a third group to which none of the above applies.
Fair enough, but that's not what I meant.
[...]
>> I'm not sure if accessing a property off of `constructor` without first
>> testing for its existence (given that host objects might not implement
>> it) is the safest way to go, but apparently it works as it is.
>
> "Apparently" jQuery < 1.3 "worked" before IE 8. This should give you pause.
Apparently `typeof` function/object/unknown is a reliable indication of
something being a host method. This is the kind of "apparently" I had in
mind. Of course, it appears that `isOwnProperty` is used exclusively
with native objects, so my concern is irrelevant.
>
>>>> even though scripts that augment it should be considered dangerous as well.
>>> Not dangerous (there is no danger in a runtime error), but inappropriate
>> There's no danger in runtime error?
>
> Mind your words. What possible *danger* is there? A runtime error is an
> avoidable inconvenience, but it poses no danger in and of itself.
That makes sense. I think I misunderstood you.
[...]
>>> I don't think that is a reasonable or compatible approach.
>> Why?
>
> Proprietary DOM implementations may not consider the root element an event
> target for an event, and AIUI even standards-compliant DOM implementations
> do not need to. Insofar the "weirdness" of this approach constitutes an
> argument against it.
>
> <http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTypes-complete>
Interesting. I'll try to create a minimal test case and test it across
any browsers I have an access to.
--
kangax
David Mark
wrote:
[snip]
>
> "Apparently" jQuery < 1.3 "worked" before IE 8. This should give you pause.
>
I do want to point out that jQuery 1.3x (they are on the third
iteration now) does not work in IE8, IE7, IE6, ... IE3, AOL IE, Mac
IE, IE spoofs or anything that even looks like IE. Not any mode, not
even close and apparently not in this lifetime. Oh well, we never
needed it anyway.
Mozilla could kill these miserable things off for good if they would
just add mozTransition to Firefox. Without (bad) animations, nobody
would have ever heard of jQuery. Somebody tell their evangelist.
[snip]
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>
> I do want to point out that jQuery 1.3x (they are on the third
> iteration now) does not work in IE8, IE7, IE6, ... IE3, AOL IE, Mac
> IE, IE spoofs or anything that even looks like IE. Not any mode, not
> even close and apparently not in this lifetime. Oh well, we never
> needed it anyway.
I do know you have been posting a lot about jQuery issues, but I have not
found the time to read all of your postings thoroughly (they are rather long
and it is difficult to find the technical facts among the bickering, even if
justified, now), and I certainly don't remember all of them.
Therefore, would you be so kind to try pointing out and maybe explaining
*concisely*, if possible, why exactly what you describe above is so? That
could provide those who are forced by their uninitiated bosses to use jQuery
for certain graphical gimmicks (because they "look great") a big enough LART
to abandon jQuery eventually. Thank you very much in advance.
> Mozilla could kill these miserable things off for good if they would
> just add mozTransition to Firefox. Without (bad) animations, nobody
> would have ever heard of jQuery. Somebody tell their evangelist.
ACK :)
PointedEars
David Mark
wrote:
> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> "Apparently" jQuery < 1.3 "worked" before IE 8. This should give you pause.
>
> > I do want to point out that jQuery 1.3x (they are on the third
> > iteration now) does not work in IE8, IE7, IE6, ... IE3, AOL IE, Mac
> > IE, IE spoofs or anything that even looks like IE. Not any mode, not
> > even close and apparently not in this lifetime. Oh well, we never
> > needed it anyway.
>
> I do know you have been posting a lot about jQuery issues, but I have not
> found the time to read all of your postings thoroughly (they are rather long
> and it is difficult to find the technical facts among the bickering, even if
> justified, now), and I certainly don't remember all of them.
Well, as for their length, there were a lot of issues. If you just
read mine, you will skip the follow-up "bickering" which is really
more like endless, repetitive blithering.
>
> Therefore, would you be so kind to try pointing out and maybe explaining
> *concisely*, if possible, why exactly what you describe above is so?
With respect to IE?
There's too much to explain concisely. Suffice to say that the
culture revolves around a method called "attr." That method's purpose
is undocumented. The method's code is pure gibberish that adds ten
million (approx.) additional complications to the already complicated
task of cross-browser scripting and its behavior changes across IE
versions (as well as jQuery versions.) That's one critical, low-level
method (most are of similar quality.) Another observation is that
disabling ActiveX in IE causes Ajax calls to unceremoniously throw
exceptions.
If that is not enough, go back and read the rest of it. I'll publish
a summary at some point in the future.
> That
> could provide those who are forced by their uninitiated bosses to use jQuery
> for certain graphical gimmicks (because they "look great") a big enough LART
> to abandon jQuery eventually. Thank you very much in advance.
I've received a lot of queries for more evidence. There's only one of
me, so I tell most of them to do their own homework.
[snip]