Prev: keyboard commands?
Next: FAQ Topic - What is a function statement? (2010-05-24)
From: DL on 24 May 2010 09:49
On May 23, 8:19 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> DL wrote:
> > For a short follow-up I'll just do top post, bear with me.
>
> Why?
>
> > With regard to "contentWindow vs.
> > It is preferable to use contentDocument", are you saying
> > contentDocument is supported by IE7/IE8, FF3.x and the new FF4.x and
> > possibly Chrome as well?
>
> AFAIK it is, but that's beside the point.  One of the wonderful things
> about feature testing is that you let the code do the work and forget
> about memorizing and endless empirical data gathering.  Anyway, it is a
> standard, whereas the other is not.  When faced with a choice between a
> standard and a non-standard, you generally choose the former.
>
>
>
> > Thanks.  FYI, yeah, "accidentially" I've made it working across two
> > browsers so far and no, not intended to support all browsers and all
> > versions.
>
> I presume you won't be putting it on the Web then.  And FYI, using
> UA-sniffing does not count as "working".  In fact, it is an admission
> that you could not make your design work.  Those who say otherwise seem
> to miss the fact that there's not time to go back and rewrite every
> project when the faulty inferences inevitably fall apart.  Working
> means, barring bizarre circumstances, a Web app should work virtually
> forever (particularly if it sticks to standards).
>
>
>
> >> On May 23, 2:28 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> >> DL wrote:
> >>> Hi,
> >>> I'm having a problem with iframe reload upon data saving with ie7
> >>> (tested on XP) or ie8 (tested on windows 7).
> >> Which one then?  :)  I'll assume both.
>
> >>> The flow of the page is:
> >>> a) automatically saving/updating data inside the iframe while a user
> >>> is typing... (no problem with Firefox 3.5.x or IE7/8)
> >> If your only clue to the veracity of your logic is that the application
> >> appears to work in three browsers (in whatever configuration you have
> >> them in), you haven't really got a leg to stand on.  In other words, if
> >> you don't *understand* the abstractions in play, how can you feel secure
> >> about IE8, FF4, etc.
>
> >>> b) upon clicking on the Save button, manually save/update and refresh
> >>> the screen including reloading the iframe (no problem with Firefox but
> >>> the iframe fails to resize per js instruction)
> >> So there is a problem with FF then?
>
> >>> More detail of the problem (I've omitted the automatic data saving
> >>> part for not cluttering the screen but will post more code if
> >>> necessary)
> >>> js within header
> >>> ----------------
> >>>    function setFrm() {
> >>>    var fh = document.getElementById('tb');
> >>>                    fh.style.width = (screen.width * 0.85)+"px";
> >>>                    fh.style.height = (screen.height - 350)+"px";
> >> Don't use screen.* as you have no idea how those dimensions relate to
> >> the browser window.  What is it you are trying to do here?
>
> >>>    }
> >>>    if (navigator.appCodeName == 'Mozilla') {
> >> Clearly my initial presumption was correct.  You are simply rearranging
> >> code until it appears to "work" and using browser sniffing to boot.
> >> Such strategies are doomed to fail.
>
> >>http://www.jibbering.com/faq/notes/detect-browser/
>
> >>>    var Editor1 = document.getElementById('tb').contentWindow.document;
> >> It is preferable to use contentDocument where available as there is no
> >> standard for contentWindow.  You've made a bad assumption based on a bad
> >> inference and concluded it "works" due to empirical evidence gathered
> >> from three browsers
>
> >>>    }
> >>>    else
> >>>            var Editor1 = document.frames['tb'].document;
> >> And why did you do this at all?  IE supports contentWindow.  I can only
> >> assume you copied it from a Website.  That's usually the kiss of death
> >> as 99.9% of the JS floating around out there is junk code (as we see here).
>
> >>> html body
> >>> ---------
> >>> <body bgcolor="##ECECFF" onload="setFrm();">
> >> Don't use the deprecated bgcolor attribute.  Use a style sheet.  And you
> >> forgot to set the foreground color as well.  Good job using the onload
> >> attribute though (that's the first thing you did right and I assume it
> >> was accidental).
>
> >>> <form...>
> >> Huh?
>
> >>> <iframe id="tb" name="tb" src="getData.html"
> >>> onload="document.frames['tb'].document.designMode='on';"
> >>> contenteditable="true"></iframe>
> >> Where's the sniff?  Above you only used that pattern for IE.  :)  And
> >> why the contenteditable attribute?  The designMode property set will do
> >> fine.
>
> >>> <input type="hidden" id="nt" name="nt"/>
> >> The slash is an error.  This is clearly not XHTML.
>
> >>> <input name="SaveEditing" type="submit" value=" Save " onclick=<cfif
> >>> CGI.HTTP_USER_AGENT contains "MSIE">"var Editor1 =
> >>> document.frames['tb'].document;var nt =
> >>> document.getElementById('nt');nt.value =
> >>> Editor1.body.innerHTML;"<cfelse>"var Editor1 =
> >>> document.getElementById('textbox').contentWindow.document;var nt =
> >>> document.getElementById('nt');nt.value = Editor1.body.innerHTML;"</
> >>> cfif> style="background-color:##BDD3FF;color:black">
> >> Don't post server side directives in your example code.  It makes it
> >> difficult to read.  Post the results of the server side script.
>
> >>> </form>
> >>> Thanks in advance.
> >> NP, but you've given me nothing useful to work with.  I don't even see
> >> where you've described the problem.
>
> >>http://www.jibbering.com/faq/notes/posting/#ps1DontWork
>
> >> And a word of advice.  Creating a cross-browser rich text editing
> >> application appears to be well outside your current range.  I'd
> >> seriously consider farming this out.  I just built something like this
> >> for a client last week.  Drop me a line if you have a budget allocated
> >> (it won't be cheap).  The alternative is tons of frustration and misery
> >> that will ultimately end in failure.  I've seen it happen many times
> >> (and to much more advanced developers than yourself).  ;)
>
>

The app isn't for public use, hence, we have a slightly controlled
environment (browser choices or recommendations).

Changed the the following code
(from contentWindow to contentDocument):
/* Editor1 =
document.getElementById('textbox').contentWindow.document;
*/
Editor1 = document.getElementById('textbox').contentDocument.document;

And it still failed FF3.5.9 (Vista) as with FF3.6.2.(Windows 7), that
is, both failed to recognize the "Editor1" var. How come?
Or possibly something else?

Thanks.
From: David Mark on 24 May 2010 10:20
DL wrote:

[...]

>
> The app isn't for public use, hence, we have a slightly controlled
> environment (browser choices or recommendations).

And you never intend to change them?

>
> Changed the the following code
> (from contentWindow to contentDocument):
> /* Editor1 =
> document.getElementById('textbox').contentWindow.document;
> */
> Editor1 = document.getElementById('textbox').contentDocument.document;
>
> And it still failed FF3.5.9 (Vista) as with FF3.6.2.(Windows 7), that
> is, both failed to recognize the "Editor1" var. How come?

Because you are just guessing. Google for "contentDocument". It would
have saved some time if you'd done that before posting again.


From: DL on 24 May 2010 11:11
On May 24, 10:20 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> DL wrote:
>
> [...]
>
>
>
> > The app isn't for public use, hence, we have a slightly controlled
> > environment (browser choices or recommendations).
>
> And you never intend to change them?
>
>
>
> > Changed the the following code
> > (from contentWindow to contentDocument):
> > /* Editor1 =
> > document.getElementById('textbox').contentWindow.document;
> > */
> > Editor1 = document.getElementById('textbox').contentDocument.document;
>
> > And it still failed FF3.5.9 (Vista) as with FF3.6.2.(Windows 7), that
> > is, both failed to recognize the "Editor1" var.  How come?
>
> Because you are just guessing.  Google for "contentDocument".  It would
> have saved some time if you'd done that before posting again.

Previous experience of googling with this sort of problem wasn't
always productive... Anyway, the following code, which seems to cover
"all the bases" still fails Firefox 3.5.9 (on Vista box), I'm really
baffled:

var f = document.getElementById('textbox');
var Editor1 = (f.contentDocument.document || f.contentWindow.document
|| f.contentDocument);
// the Editor1 var is on one line

Thanks.
From: David Mark on 24 May 2010 11:19
DL wrote:
> On May 24, 10:20 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>> DL wrote:
>>
>> [...]
>>
>>
>>
>>> The app isn't for public use, hence, we have a slightly controlled
>>> environment (browser choices or recommendations).
>> And you never intend to change them?
>>
>>
>>
>>> Changed the the following code
>>> (from contentWindow to contentDocument):
>>> /* Editor1 =
>>> document.getElementById('textbox').contentWindow.document;
>>> */
>>> Editor1 = document.getElementById('textbox').contentDocument.document;
>>> And it still failed FF3.5.9 (Vista) as with FF3.6.2.(Windows 7), that
>>> is, both failed to recognize the "Editor1" var. How come?
>> Because you are just guessing. Google for "contentDocument". It would
>> have saved some time if you'd done that before posting again.
>
> Previous experience of googling with this sort of problem wasn't
> always productive...

I asked you to Google a property name (contentDocument) so you would see
the obvious mistake you made.

> Anyway, the following code, which seems to cover
> "all the bases" still fails Firefox 3.5.9 (on Vista box), I'm really
> baffled:
>
> var f = document.getElementById('textbox');

What is that? An IFRAME or a text input?

> var Editor1 = (f.contentDocument.document || f.contentWindow.document
> || f.contentDocument);
> // the Editor1 var is on one line
>

What makes you think contentDocument has a "document" property? That's
why I asked you to look up the documentation (or any example that uses
that property successfully).

First hit:-

http://msdn.microsoft.com/en-us/library/cc196985(VS.85).aspx

Also, you should really learn to use a debugger (e.g. Firebug). That
would have clued you in to at least one mistake. Are you starting to
realize you are in over your head?


From: DL on 24 May 2010 12:58
On May 24, 11:19 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> DL wrote:
> > On May 24, 10:20 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> >> DL wrote:
>
> >> [...]
>
> >>> The app isn't for public use, hence, we have a slightly controlled
> >>> environment (browser choices or recommendations).
> >> And you never intend to change them?
>
> >>> Changed the the following code
> >>> (from contentWindow to contentDocument):
> >>> /* Editor1 =
> >>> document.getElementById('textbox').contentWindow.document;
> >>> */
> >>> Editor1 = document.getElementById('textbox').contentDocument.document;
> >>> And it still failed FF3.5.9 (Vista) as with FF3.6.2.(Windows 7), that
> >>> is, both failed to recognize the "Editor1" var.  How come?
> >> Because you are just guessing.  Google for "contentDocument".  It would
> >> have saved some time if you'd done that before posting again.
>
> > Previous experience of googling with this sort of problem wasn't
> > always productive...
>
> I asked you to Google a property name (contentDocument) so you would see
> the obvious mistake you made.
>
> > Anyway, the following code, which seems to cover
> > "all the bases" still fails Firefox 3.5.9 (on Vista box), I'm really
> > baffled:
>
> > var f = document.getElementById('textbox');
>
> What is that?  An IFRAME or a text input?
>
> > var Editor1 = (f.contentDocument.document || f.contentWindow.document
> > || f.contentDocument);
> > // the Editor1 var is on one line
>
> What makes you think contentDocument has a "document" property?  That's
> why I asked you to look up the documentation (or any example that uses
> that property successfully).
>
> First hit:-
>
> http://msdn.microsoft.com/en-us/library/cc196985(VS.85).aspx
>
> Also, you should really learn to use a debugger (e.g. Firebug).  That
> would have clued you in to at least one mistake.  Are you starting to
> realize you are in over your head?

Please see below.

> > var f = document.getElementById('textbox');
>
> What is that? An IFRAME or a text input?
Sorry, too lazy.. should have named it something like "frm" something.

Yes, I used the firebug for FF3.5 on the dev box. Just install it to
my Vista box, and it found that the FORM element of "subject" not
found... and bump out.

More info:
The page has a form named "edit" with id also "edit" with fields
include "subject".

And on the js side, as posted before, has
....
d.setForm('edit'); // set form name
d.setHTTPMethod('POST'); // specify form submission method
d.doUpdate(); // call a function

Odd stuff:
How come IE7 or IE8 can submit the form correctly with all fields
intact including "Subject" while Firefox (3.5 or 3.5.9) failed to
include field of "Subject"? a reserved word? if so it would be
weird...

And the key part of the current code look like this:
var f = document.getElementById('frm');
var Editor1 = f.contentDocument;
if (Editor1 && document.getElementById('subject'))
{
document.getElementById('notes').value = Editor1.body.innerHTML;
if (document.getElementById('subject').value !== '' ||
document.getElementById('notes').value !== '') {
d.setForm('edit');
d.setHTTPMethod('POST');
d.doUpdate();
}
}

Thanks.
First  |  Prev  | 
Pages: 1 2
Prev: keyboard commands?
Next: FAQ Topic - What is a function statement? (2010-05-24)