My Library update
David Mark
Safari. A typo was causing it fail.
Looks good in Safari 4.0 and Chrome. I'm not saying there aren't
mistakes to be found, but the code has withstood FF3, FF3.5, Safari 3,
Safari 4, three versions of Opera, Chrome, Netscape back to 6.2 and IE
back to 5 (and 4 is not out of the question, just never tested it).
Never tried Safari 2, but I think most of it should work (and the rest
should degrade). And I know I tested a build on the PS3 at one point
too.
Not too bad for something that has sat on the shelf for years. ISTM
that's the measure of a cross-browser script is the length of time
between major rewrites. Other than some typos and a few silly 2007
mistakes corrected over the years (thanks again Kangax), nothing's
changed. Feature testing allows for such a "Write Once, Do Nothing"
approach.
It also seems to me that Google is wasting everyone's time releasing
an all-sniff library in 2009 (and they are known for script errors,
even in major browsers) and jQuery still can't figure out attributes.
Is it cool to swap scripts out constantly? Seems like an enormous
waste of time and money to me, but the misconceptions about the
language are so deeply rooted at this point that most people believe
Resig (and the like) when they claim they are solving some impossible
problem (and please bear with them forever).
Also, somebody (RobG?) mentioned they'd been working on updating the
documentation (sorely needed). Send it and I'll put it up... What's
up there now is pretty skeletal (and untouched since 2007), but at
least it doesn't describe delusions. ;)
kangax
No problem.
Out of curiosity, I checked few older browsers I have here on my mac and
noticed few more issues.
Safari 2.0, for example, always opens dialog in what appears to be the
middle of a document, rather than middle of screen; similarly, when
maximizing dialog, its (dialog's) bottom ends up all the way at the
bottom of a document.
In (rather ancient) Opera 8.54 few things seem to be defunct: image
scroll via drag; mousewheel event handling; innerHTML on select element
makes its contents disappear; when maximizing, dialog resizes not from
center, but somewhere from the right (and off) of the screen; opaque
text is not opaque.
Firefox 1.5 works wonderfully, but 1.0 has some issues with dialog
positioning (its bottom also ends up being on the bottom of a document)
and in some cases it doesn't seem to be possible to resize it.
--
kangax
David Mark
Cool! :)
>
> Safari 2.0, for example, always opens dialog in what appears to be the
> middle of a document, rather than middle of screen; similarly, when
> maximizing dialog, its (dialog's) bottom ends up all the way at the
> bottom of a document.
Well, that's obviously broken. Sounds similar to the old Opera bug
with documentElement.clientHeight being equal to
documentElement.scrollHeight (though that one is covered). Standards
mode and quirks? Of all the older browsers I tested, that one was
definitely not on the list as I didn't have a Mac at the time. I will
have a look at the function that measures the viewport. I've been
working on a much simplified version of that as well.
>
> In (rather ancient) Opera 8.54 few things seem to be defunct: image
> scroll via drag; mousewheel event handling; innerHTML on select element
> makes its contents disappear; when maximizing, dialog resizes not from
> center, but somewhere from the right (and off) of the screen; opaque
> text is not opaque.
Hmm. ISTM I tested in Opera 8. Of course, not on Mac. No idea
there. You sure it wasn't just the cursor missing on scroll by drag?
I know that's a (not really needed) custom cursor and Opera never
liked those.
>
> Firefox 1.5 works wonderfully, but 1.0 has some issues with dialog
> positioning (its bottom also ends up being on the bottom of a document)
> and in some cases it doesn't seem to be possible to resize it.
Never tested any of it in 1.0. But there seems to be a common thread
in ancient (and one not so ancient) Mac browsers with regard to the
centering/maximizing. Could be my feature testing for the broken
Opera (and like) implemenations is inadequate. I'll have to look at
that. Will post a simplified version of the getViewportDimensions
function when I get a chance. Will be easier to spot the mistake(s).
Completely avoids the documentElement.clientHeight issue if it can
determine the scroll bar width (and it is better than the old one at
that) and innerHeight is available.
As mentioned, not perfect. As I have a slightly improved set of
attribute wrappers now too (in that test page I posted), I will likely
put up some unit tests (at the very least for attributes and viewport
dimensions). I want to (perhaps optionally) yank out the unload
cleanup too as it should be unnecessary.
Also, as mentioned a while back, relying on the viewport height for
anything is a mistake. Put "dialogs" at the top (like the Mac OS) and
avoid the issue.
Thanks again.
optimistx
> Also, somebody (RobG?) mentioned they'd been working on updating the
> documentation (sorely needed). Send it and I'll put it up... What's
> up there now is pretty skeletal (and untouched since 2007), but at
> least it doesn't describe delusions. ;)
Have you a non-minified version available also, and if yes, where?
David Mark
Yes, you can build your own library a la carte with the builder.
You'll want to at least strip the comments before deployment.
Hans-Georg Michna
>Out of curiosity, I checked few older browsers I have here on my mac and
>noticed few more issues.
Where would be your guess for a sensible cutoff for very old
browsers? For example, I don't believe that it makes sense any
more now to waste time on IE 5.x, because (a) its market share
is small and dropping, and (b) the effort to support it would be
out of proportion in relation to the smaller effort for newer
browsers.
I think a sensible cutoff time span lies somewhere between 5 and
10 years, meaning that it makes no sense to support a browser
that is more than so many years old. At 10 years you're leaving
the timespan of JavaScript's existence anyway.
Hans-Georg
David Mark
georgNoEmailPle...@michna.com> wrote:
> On Fri, 20 Nov 2009 23:37:21 -0500, kangax wrote:
> >Out of curiosity, I checked few older browsers I have here on my mac and
> >noticed few more issues.
>
> Where would be your guess for a sensible cutoff for very old
> browsers? For example, I don't believe that it makes sense any
> more now to waste time on IE 5.x, because (a) its market share
> is small and dropping, and (b) the effort to support it would be
> out of proportion in relation to the smaller effort for newer
> browsers.
I think that 2005 era Safari and Opera and IE5.5 are fairly irrelevant
today (certainly IE5.0). Still little things going wrong in such
browsers may indicate assumptions made in feature tests are too broad.
>
> I think a sensible cutoff time span lies somewhere between 5 and
> 10 years, meaning that it makes no sense to support a browser
> that is more than so many years old. At 10 years you're leaving
> the timespan of JavaScript's existence anyway.
>
IE6 came out around ten years ago and we'll have to deal with it for
quite a while longer due to corporate use. I wouldn't worry too much
about IE5.5, though Windows 2000 users may still be stuck with it.
But you should try to follow graceful degradation paths in any event,
considering each feature in context (i.e. is it critical or an
enhancement). I think it is easiest to test as many features as
practical, rather than trying to remember the exact drop off from IE6
to IE5.5, Safari 3.x to 2.x, etc.
Michael Haufe ("TNO")
> IE6 came out around ten years ago and we'll have to deal with it for
> quite a while longer due to corporate use. I wouldn't worry too much
> about IE5.5, though Windows 2000 users may still be stuck with it.
> But you should try to follow graceful degradation paths in any event,
> considering each feature in context (i.e. is it critical or an
> enhancement). I think it is easiest to test as many features as
> practical, rather than trying to remember the exact drop off from IE6
> to IE5.5, Safari 3.x to 2.x, etc.
A couple times in my work I've had to support NS6 as well. (Apparently
there are still people running around with some form of an AOL
browser).
David Mark
IIRC, 6.0 is very problematic. I don't think they got it quite
"right" until 6.2, which is fairly workable. Also IIRC, one of the
keys was avoiding designs that fetch computed styles (something I do
anyway).
Erwin Moller
> IE6 came out around ten years ago and we'll have to deal with it for
> quite a while longer due to corporate use. I wouldn't worry too much
> about IE5.5, though Windows 2000 users may still be stuck with it.
Hi,
I use W2K Prof(SP4) at home on an older PC, but it runs IE6 just fine.
Version: 6.0.2800.1106
If memory serves me well the Windows Update service even demanded IE6 to
function well.
Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
David Mark
<Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
> David Mark wrote:
> > IE6 came out around ten years ago and we'll have to deal with it for
> > quite a while longer due to corporate use. I wouldn't worry too much
> > about IE5.5, though Windows 2000 users may still be stuck with it.
>
> Hi,
>
> I use W2K Prof(SP4) at home on an older PC, but it runs IE6 just fine.
> Version: 6.0.2800.1106
>
> If memory serves me well the Windows Update service even demanded IE6 to
> function well.
ISTM that had something to do with the problem. If you start with
IE5.5 and need to update to upgrade to IE6, but the update requires
IE6...
Erwin Moller
Yes, correct.
That is quite annoying to say the least. ;-)
I happened to reinstall W2K a few months ago, and this is what I remember:
1) You CAN use IE 5.5 to run the windows updates, only not in 'normal'
mode, but something simpler. I think (not 100% sure) that things like
'optional updates' or 'hardware updates' are not working correctly, and
the funky userinterface fails, but you can run the critical updates.
2) Now I am not sure how I got IE6 on my W2K machine. It could be via a
SP4 separate download, or it was included in one of the security
updates. (Possibly SP4 was offered via security updates).
Anyway: After Sp4 + security updates W2K runs IE6.
(Not that I want to use IE6, I rather use FF.)
kangax
>> Safari 2.0, for example, always opens dialog in what appears to be the
>> middle of a document, rather than middle of screen; similarly, when
>> maximizing dialog, its (dialog's) bottom ends up all the way at the
>> bottom of a document.
>
> Well, that's obviously broken. Sounds similar to the old Opera bug
> with documentElement.clientHeight being equal to
> documentElement.scrollHeight (though that one is covered). Standards
> mode and quirks? Of all the older browsers I tested, that one was
Yep, I see that quirks is affected in the very same way (originally,
I've been testing everything in standards).
> definitely not on the list as I didn't have a Mac at the time. I will
> have a look at the function that measures the viewport. I've been
> working on a much simplified version of that as well.
>
>> In (rather ancient) Opera 8.54 few things seem to be defunct: image
>> scroll via drag; mousewheel event handling; innerHTML on select element
>> makes its contents disappear; when maximizing, dialog resizes not from
>> center, but somewhere from the right (and off) of the screen; opaque
>> text is not opaque.
>
> Hmm. ISTM I tested in Opera 8. Of course, not on Mac. No idea
> there. You sure it wasn't just the cursor missing on scroll by drag?
I saw that image was not changing at all as it was being dragged
(contrary to every other browser).
> I know that's a (not really needed) custom cursor and Opera never
> liked those.
>
>> Firefox 1.5 works wonderfully, but 1.0 has some issues with dialog
>> positioning (its bottom also ends up being on the bottom of a document)
>> and in some cases it doesn't seem to be possible to resize it.
>
> Never tested any of it in 1.0. But there seems to be a common thread
> in ancient (and one not so ancient) Mac browsers with regard to the
> centering/maximizing. Could be my feature testing for the broken
That's what I thought as well.
> Opera (and like) implemenations is inadequate. I'll have to look at
> that. Will post a simplified version of the getViewportDimensions
> function when I get a chance. Will be easier to spot the mistake(s).
> Completely avoids the documentElement.clientHeight issue if it can
> determine the scroll bar width (and it is better than the old one at
> that) and innerHeight is available.
>
> As mentioned, not perfect. As I have a slightly improved set of
> attribute wrappers now too (in that test page I posted), I will likely
> put up some unit tests (at the very least for attributes and viewport
> dimensions). I want to (perhaps optionally) yank out the unload
> cleanup too as it should be unnecessary.
It definitely needs unit tests. It's rather painful to perform manual
testing of every single component in dozens of browsers.
>
> Also, as mentioned a while back, relying on the viewport height for
> anything is a mistake. Put "dialogs" at the top (like the Mac OS) and
> avoid the issue.
Yes, that's an elegant solution.
Btw, I also noticed that something is off in latest Konqueror. I don't
have time to investigate at the moment, but the whole thing appears to
be broken in it; IIRC, an error was with `isHostMethod(body,
'getBoundingClientRect')` due to `body` being `null` at that moment.
--
kangax
kangax
> On Fri, 20 Nov 2009 23:37:21 -0500, kangax wrote:
>
>> Out of curiosity, I checked few older browsers I have here on my mac and
>> noticed few more issues.
>
> Where would be your guess for a sensible cutoff for very old
> browsers? For example, I don't believe that it makes sense any
As usual, the answer is � it depends.
My employer's public website, for example, still gets ~150-200 visitors
of Safari 1.3.x every month; browser that's considered rather ancient
and extinct (its capabilities are pretty horrible too).
At the same time, there are usually only 5-7 users of IE5.5 for the same
period of time (one month).
In such case, it would make sense to "support" Safari 1.3.x, but not
IE5.5 (even though, in reality, they decided to go as far as drop
support for IE6, not talking about Safari 2.x or 1.3.x).
Or it might not make sense to support Safari 1.3.x at all, since
overall, its share is less than 0.1% (total number of visitors a month
is ~250,000).
[...]
--
kangax
RobG
I did a W2k reinstall recently too. Windows update wouldn't work with
IE 5.5, neither would the IE download site. I had to install Firefox
so I could download IE 6 (ironic, but there you go) so I could get
Windows Update to work.
--
Rob
David Mark
kangax wrote:
> David Mark wrote:
> > On Nov 20, 11:37 pm, kangax <kan...@gmail.com> wrote:
> [...]
> >> Safari 2.0, for example, always opens dialog in what appears to be the
> >> middle of a document, rather than middle of screen; similarly, when
> >> maximizing dialog, its (dialog's) bottom ends up all the way at the
> >> bottom of a document.
> >
> > Well, that's obviously broken. Sounds similar to the old Opera bug
> > with documentElement.clientHeight being equal to
> > documentElement.scrollHeight (though that one is covered). Standards
> > mode and quirks? Of all the older browsers I tested, that one was
>
> Yep, I see that quirks is affected in the very same way (originally,
> I've been testing everything in standards).
That is odd. You'd think one of them would have the right height.
I'll post a simplified version of getViewportDimensions some time
soon. Should be easy enough to figure out what is going on.
>
> > definitely not on the list as I didn't have a Mac at the time. I will
> > have a look at the function that measures the viewport. I've been
> > working on a much simplified version of that as well.
> >
> >> In (rather ancient) Opera 8.54 few things seem to be defunct: image
> >> scroll via drag; mousewheel event handling; innerHTML on select element
> >> makes its contents disappear; when maximizing, dialog resizes not from
> >> center, but somewhere from the right (and off) of the screen; opaque
> >> text is not opaque.
> >
> > Hmm. ISTM I tested in Opera 8. Of course, not on Mac. No idea
> > there. You sure it wasn't just the cursor missing on scroll by drag?
>
> I saw that image was not changing at all as it was being dragged
> (contrary to every other browser).
I figured. Just wanted to clarify. I assume the rest of DnD is okay,
so that makes me think that setting scrollTop/Left isn't working in
those older Operas.
>
> > I know that's a (not really needed) custom cursor and Opera never
> > liked those.
> >
> >> Firefox 1.5 works wonderfully, but 1.0 has some issues with dialog
> >> positioning (its bottom also ends up being on the bottom of a document)
> >> and in some cases it doesn't seem to be possible to resize it.
> >
> > Never tested any of it in 1.0. But there seems to be a common thread
> > in ancient (and one not so ancient) Mac browsers with regard to the
> > centering/maximizing. Could be my feature testing for the broken
>
> That's what I thought as well.
I'm sure of it for Opera < 9. Not particularly concerned about it,
but it should be very simple to diagnose. Not that I trust the
GoogClosure developers to document anything accurately, but their time
capsule indicates that the ancient Operas use body.clientHeight/Width
in both modes (which makes no sense). If that were the case, quirks
mode should have worked. The new simplified version sidesteps these
issues.
>
> > Opera (and like) implemenations is inadequate. I'll have to look at
> > that. Will post a simplified version of the getViewportDimensions
> > function when I get a chance. Will be easier to spot the mistake(s).
> > Completely avoids the documentElement.clientHeight issue if it can
> > determine the scroll bar width (and it is better than the old one at
> > that) and innerHeight is available.
> >
> > As mentioned, not perfect. As I have a slightly improved set of
> > attribute wrappers now too (in that test page I posted), I will likely
> > put up some unit tests (at the very least for attributes and viewport
> > dimensions). I want to (perhaps optionally) yank out the unload
> > cleanup too as it should be unnecessary.
>
> It definitely needs unit tests. It's rather painful to perform manual
> testing of every single component in dozens of browsers.
No question. That's the biggest hole. It does have an automated test
for the query engine, but nothing else. I just don't have the time to
do much on that project (never did).
>
> >
> > Also, as mentioned a while back, relying on the viewport height for
> > anything is a mistake. Put "dialogs" at the top (like the Mac OS) and
> > avoid the issue.
>
> Yes, that's an elegant solution.
Thank you. Doesn't this stuff always come down to avoiding what you
know is unreliable? Granted, time affects the decision-making (i.e.
older browsers eventually become irrelevant).
>
> Btw, I also noticed that something is off in latest Konqueror. I don't
> have time to investigate at the moment, but the whole thing appears to
> be broken in it; IIRC, an error was with `isHostMethod(body,
> 'getBoundingClientRect')` due to `body` being `null` at that moment.
Thanks. That's this line in the Offset module:-
if (isHostMethod(body, 'getBoundingClientRect')) {
But that's definitely not run until the DOM is ready, so the body
should not be null at that point. Could just as easily test the
documentElement, but I can't see why that would be necessary at that
point. It sounds like the code is running before the head finishes
parsing. Perhaps DOMContentLoaded has a bug in this new Konquerer.
Or perhaps it doesn't support that event at all and is using the
simulation found at the end of the body, but certainly the body
shouldn't be null at that point either. I have since stopped relying
on such simulations as I don't think they are based in reality.
Thanks for looking at it. Let me know if you can figure out what is
going on in that browser.
David Mark
>
> Thanks. That's this line in the Offset module:-
>
> if (isHostMethod(body, 'getBoundingClientRect')) {
>
> But that's definitely not run until the DOM is ready, so the body
> should not be null at that point. Could just as easily test the
> documentElement, but I can't see why that would be necessary at that
> point. It sounds like the code is running before the head finishes
> parsing. Perhaps DOMContentLoaded has a bug in this new Konquerer.
> Or perhaps it doesn't support that event at all and is using the
> simulation found at the end of the body, but certainly the body
> shouldn't be null at that point either. I have since stopped relying
> on such simulations as I don't think they are based in reality.
>
> Thanks for looking at it. Let me know if you can figure out what is
> going on in that browser.
if (attachDocumentReadyListener) {
attachDocumentReadyListener(function() {
var body, containerElement;
getBodyElement = function(docNode) {
docNode = docNode || global.document;
if (isRealObjectProperty(docNode, 'body')) { return
docNode.body; }
if (typeof getEBTN == 'function') { return getEBTN('body',
docNode)[0] || null; }
return null;
};
API.getBodyElement = getBodyElement;
body = getBodyElement();
...
That's the start of it. Looks good to me. I suppose there may be
some browser out there that will fail the isRealObjectProperty test
(should really allow for more than "object"), but then there is the
gEBTN fallback (put in for such cases). I know some XHTML DOM's do
not support document.body as well.
David Mark
You thought right. I tried with Opera 9.27 (probably the first time
ever) and found it to have the documentElement.scrollHeight ==
documentElement.clientHeight mix-up (as originally spotted in 9.0).
That was being detected, but they apparently changed some other things
from 9.0 > 9.2x that exposed the test as too specific.
I fixed it (for now) with a fairly ugly feature test/inference
hybrid. The test may still be too specific for really ancient Operas,
but shouldn't affect other browsers. Re-tested in quirks and
standards mode in IE8 (compatibility mode too), Chrome, FF3.5 as
well. The sidebar feature is the acid test as it involves no size
animation. I have noticed that the animated dialog sizing causes a
horizontal scroll bar in IE8 when maximized (5/6/7 never did that).
Let me know if that fixes the ancient Operas too. If not, I'll have
to make the test a bit more generalized. I just don't like to expose
browsers to unnecessary "quirkarounds" like this unless I am sure it
is necessary.
Really need to finish the simplified version of this. It's gotten a
bit ugly at this point. Another reason to avoid this question
altogether (history says it is a bear). For centering, using
window.innerHeight/Width (when present) is accurate enough (or just
center at the top).
Thanks again!
David Mark
[...]
>
> You thought right. I tried with Opera 9.27 (probably the first time
> ever) and found it to have the documentElement.scrollHeight ==
> documentElement.clientHeight mix-up (as originally spotted in 9.0).
> That was being detected, but they apparently changed some other things
> from 9.0 > 9.2x that exposed the test as too specific.
I knew that body.clientHeight myth was bullshit. :) And as I
remembered, documentElement.clientWidth is fine. If you look at the
bottom you will see that there is a gap (because the test page has a
margin on the body). No such gap on the right. So the problem is
that without the scrollbar dimensions and a test for whether
window.innerWidth/Height includes them, it has to use a BS workaround
(body.clientHeight). Opera 9.0 didn't have to go that route IIRC.
I'll fix this in the simplified version when I get a chance.
Hans-Georg Michna
>Hans-Georg Michna wrote:
>> Where would be your guess for a sensible cutoff for very old
>> browsers? For example, I don't believe that it makes sense any
>As usual, the answer is — it depends.
>[...]
>Or it might not make sense to support Safari 1.3.x at all, since
>overall, its share is less than 0.1% (total number of visitors a month
>is ~250,000).
I guess most web site operators would not care much about a 0.1%
loss. I wouldn't even care much about a 1% loss of visitors.
Then there may be cases where visitors with very old browsers
are not favored anyway.
Hans-Georg
David Mark
georgNoEmailPle...@michna.com> wrote:
> On Mon, 23 Nov 2009 13:56:56 -0500, kangax wrote:
> >Hans-Georg Michna wrote:
> >> Where would be your guess for a sensible cutoff for very old
> >> browsers? For example, I don't believe that it makes sense any
> >As usual, the answer is — it depends.
> >[...]
> >Or it might not make sense to support Safari 1.3.x at all, since
> >overall, its share is less than 0.1% (total number of visitors a month
> >is ~250,000).
>
> I guess most web site operators would not care much about a 0.1%
> loss. I wouldn't even care much about a 1% loss of visitors.
But a high-volume e-commerce site would decry either of those losses.
>
> Then there may be cases where visitors with very old browsers
> are not favored anyway.
>
Favored?