You mean you don't want this:
// Ultimate client-side JavaScript client sniff.
// (C) Netscape Communications 1999. Permission granted to reuse and
distribute.
// Revised 17 May 99 to add is_nav5up and is_ie5up (see below).
// Everything you always wanted to know about your JavaScript cli
I don't beleive so. Because offsetHeight does not -always- equal
scrollHeight.
scrollHeight is the true content width. offsetHeight is the width of the
visble portion of content. When the content height is such that it
doesn't overflow (require scroll handling) offsetHeight and scrollHeight
are t
hmm.. I could step in here, and get back on some of my earlier mails...
... but I won't :)
Pascal Bestebroer ([EMAIL PROTECTED])
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com
-Oorspronkelijk bericht-
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Namens Mich
Some responses, clearification and spanning ideas below.
- Original Message -
From: "Richard Bennett" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 12, 2001 2:56 AM
Subject: Re: [Dynapi-Dev] KeyEvents working in NS6
> A few ideas that distilled from your response:
> *
does this mean that the getContentWidth / getContentHeight methods can now
read:
---
DynLayer.prototype.getContentWidth=function() {
if (this.elm==null) return 0;
else if (is.ns4) return this.doc.width;
else return par
I'm afraid I have to agree with Doug here.
The reason for detecting the various browsers is for COMPATIBILITY.
It is not intended to be used as a giant test to see which variant of a
spoofed AOL browser they are using.
If you can find an example of the API working on a specific platform
that req
I'm still tracking a bug that will keep most the Mac compatability in
the Yellow or Orange section. Specifically, after applying my fix, the
label now shows, but has top and left padding, before the inner table is
written. Also, for each line the 'wraps' in the table, a space (line) is
added at th
Based on the recent rash of NS6 and Mac IE5 patches we should intergrate
them and run a updated version of the Compatability Chart.
The Mac getHeight() fix should make for a good amount of new green on the
Mac side.
___
Dynapi-Dev mailing list
[EMAIL
I think Frank needs to be posted in our Mac Debugger Hall of Fame. For one
that bug has been around for 7 months and secondly, we need someone in that
Hall, it's empty.
- Original Message -
From: "Frank T. O'Connor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 12, 2001
In this article:
http://www.geocrawler.com/archives/3/7119/2000/11/0/4715441/
(fron last year)
Two people we're discussing a bug with getContentHeight in IE5 for the
mac.
Well, a partial work around was suggested, and then according to my
search nothing else was ever discussed. I just ran into
Yes, I must say that bugfixes and suggestions DO get a lot reaction if they
are posted to the patch section.
Whatever happens, this submission has certainly NOT been ignored!
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 12, 2001 10:02 PM
Subject:
Rants are excused as per section 309.575.696.8 of the 'unwritten' guide to
conversing with programmers which states "rant all you want, just don't
forget what the code is for". Not to mention that I always wear protective
gear when coding as to prevent injuries.
I can only test those component
Hey,
Traceroute these guys, and you'll end up in some forgotten strange asylum for
the mentally deranged... except 8tan, of course, he's just a puppy living with
his parents :)))
Hehe,
Dann
begin:vcard
n:Martens;Danny
tel;cell:+32(0)478.544.003
tel;fax:+32(0)2.706.52.01
x-mozilla-html:FALSE
On item 3, I reported recently finding an instance where code that bombs in
NS6 works fine in the latest Mozilla build. Should we be writing for the
latest Mozilla build instead of NS6? I think that's safer in the long run.
IMHO, Leland
> -Original Message-
> From: Doug Melvin [SMTP:[E
Current goals as I understand them:
1) Fix all know bugs in IE 4.x &5.x and NS 4.x
on PC and MAC (linux?)
2) Ensure that all code works (consistantly) with
IE 4.x &5.x and NS 4.x on PC and MAC (linux?)
3) Implement WC3 DOM support using NS6 as a test
basis
4) and THEN we tackle improving
Related to GC and destroy().
I see destroy being used in two ways.
1) The conventional method of "page based" navigation that requires
throwing more or less a DOM object tree of nodes in the trash.
and..
2) A more eloquent (like the arced flight of a well thrown rock) integrated
GUI that dy
From looking at the code that is in the current browser.js file we attempt to
do at least 2 things:
1. identify the browser
2. identify the platform
Here are the problems that I see. We only support MSIE or NS, so why do
allow for browsers that spoof, such as Opera, to get by? Why not expli
A few ideas that distilled from your response:
* Yes, it's nice to see Henrik and Cameron (and Robert of course) putting
some effort into the
website.
If anyone has time, would it be possible to make a kind of new-comer
introduction page, with all the relevant info grouped into a short faq.
there
> jobs and real lives. Or is that your secret... none of you have real jobs
> or real
> lives, do you)
Of course we do!!
(hey guys, I think we've been found out!!)
---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked
Talk about your bubble gum for the mind!!! Every time I think I'm edging
closer
to understanding this stuff, you guys come up with something even better,
and
back to the drawing boards I go...
That being said, you won't see any rocks coming from my direction... yet ;-)
(but
maybe a curse or tw
( Takes deep breath, puts helmet on, tells mom he loves her in case he doesn't
make it back )
Seeing that this list has lately been a very boring and quiet lake of peaceful
coding, allow me to throw a new disturbance focus.
For the last days/weeks we've been undergoing a very heavy rewrite of th
I'm not dissagreeing.
What I was origionally responding to was "browser.js should be changed
to..."
I have no problem with creating a browser.adv.js or some such.
What really set me off, was again, having people, start saying '2k don't
matter'
well, what happens when you mutiply that with 100 oth
>> Why is everyone wanting to detect browsers
we don't support?
Easy on the coffee there big guy. I think its quite
clear, for RIGHT NOW, this is the proper place in code to do so. Enough
said.
Why are people not more concerned with
making what we have NOW work NOW,
and stop fucki
>
I can't believe we're making an argument out of this but anyway... am I missing
something ? Is there any problem with supplying both files and let users decide
? Once one of the detection shows to be needed for proper functionality, we copy
it from the extended and place it into the basic one.
Who said 'too advanced' ?!?!
The issue isn't weather this shouldbe used in the
DynAPI,
MY concern was in adding it to
browser.js.
WE don't need it right now, altho, I'm sure some
people would like to see it in an extension.
We don't currently support opera, or very many
other browsers.
Hardy, har, har.
2 k may be no big deal..
BUT 33.6k is still low end.
2 k here, 2k there, and another 2k over there, it does add up.
code size isn't all either..
there is the time taken to execute the code.
I'm not saying that would be the case here, I am
simply against adding every-damned-idea
Some say its over the top, others complain because it's 3 times larger, when
it simply fits the purpose of the DynAPI.
From my point of view, btw its probably biased since I submitted the code,
there is no signifigant increase in execution time and it will fix several
bugs with detecting variou
Ok,
Since someone mentioned I don't mention what my email is replying to this is
a very big rock (maybe even a very very big rock) being tossed at Doug and
everyone else who is worried about 1 or 2 k. No one cares about 2 k if they
are important and needed. Avg. connection today isn't a 36 the min
This is not meant to replace browser.js but to be included in the distribution
as an option to those that need a more accurate browser detection. As it should
happen with all extensions.
Doug Melvin wrote:
> oh yes!!
> let's make broswer.js three time larger!!
> Why didn't I think of that..
>
>
Doug Melvin wrote:
> Yes, it's too bad people, dont volunteer to help out,
> Oh wait, I have, and so have many other people, with many other things.
>
> I'm getting sick of "only three people doing the work" when offers to help
> are ignored or belittled.
Ok, ok, let's calm down a little please.
Out of interest the 'advanced' Browser.js file is Netscape/Mozilla's:
'The Ultimate JavaScript Client Sniffer, Version 3.01 with
Object-Oriented Version with a Safety Check for IE3 for the Mac'
Available at:
http://www.mozilla.org/docs/web-developer/sniffer/browser_type_oo.html
As a compromis
oh yes!!
let's make broswer.js three time larger!!
Why didn't I think of that..
(note heavy sense of sarcasm)
- Original Message -
From: "nobody" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 12, 2001 3:34 AM
Subject: [Dynapi-Dev] [ dynapi-Patches-407882 ] Browser.js Rec
Yes, it's too bad people, dont volunteer to help out,
Oh wait, I have, and so have many other people, with many other things.
I'm getting sick of "only three people doing the work" when offers to help
are ignored or belittled.
- Original Message -
From: "Pascal Bestebroer" <[EMAIL PROTECT
A very valid point.
People, expect feed-back.
Without feed-back people tend to get fed-up and
find some other way to spend their
time..
- Original Message -
From:
Richard
Bennett
To: [EMAIL PROTECTED]
Sent: Sunday, March 11, 2001 8:05
AM
Subject: Re: [Dynapi-De
No offence intended, but I think having a DOM test that works on a platform
other than Mozilla/NS6 would be a lot more useful.
If you're not sure what I'm on about, the DOM check we currently use tests
for a non-standard method only supported by NS6/Mozilla.
Mac IE5 and Konqueror (sorry Pascal,
I think this isn't to much. Although I do agree we should make it compatible
8an
___
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
Woah! That was one advanced Browser class! I reckon it's abit over the top for
reglar usage, but it could be implemented as an alternative Browser class. (Eg.
browser_advanced.js). It should however be compatible with the original Browser
class...
Like this:
function Browser () {
var agt=nav
Patches #407367, was updated on 2001-03-09 11:04
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305757&aid=407367&group_id=5757
Category: DynAPI-Widget
Group: None
Status: Open
Priority: 5
Submitted By: David Zoll
Assigned to: Nobody/Anonymous
Summary: Fix Button.s
Patches #407882, was updated on 2001-03-12 03:34
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305757&aid=407882&group_id=5757
Category: DynAPI-Core
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Browser.
Hello,
i have a resizing problem with the following html code.
If you make inline div tags in your html page, and a DynLayer with a
image, then all Div tags become as background image the image of the
last DynImageLayer!!
What is wrong here?
Does someone know how i can solve the problem?
We used to have the last modified date in each js file, which was probably
useful when people were submitting patches for the API, you could see which
version the patch was against and whether or not the bug had been fixed in a
newer version. The date was removed because it was maintained by hand,
41 matches
Mail list logo
