experchange > javascript

Dr J R Stockton (10-13-18, 11:29 PM)
I have the following script fragment in a local HTML page.
FM is a <form>, IM is an unsized <img>. IM and a textarea
are position:absolute within a position:relative <div>.
The value of DocName names a local .PNG file of about 5kB,
image 640*800px.

Function NewDoc is called by <body onload="...">, and
not before.

In my Win7 PC, Wide and High get the hoped-for values
640 & 800 and function Draw shows the image - OK.

In my Win10 PCs, Wide and High are each about 35, and
no part of the image appears - NOT GOOD. Firefox logs
no detected errors.

I intend to replace, but not tonight, the setTimeout
with a setInterval of about 0.1 seconds, which will
repeatedly call code to test the .complete property
of the image element and, when that is true will
end the timer and call function Draw.

Any (useful) comment?

<script type="text/javascript">
var IM, Form0, Wide, High // Globals

function NewDoc() { // Just read the form and wait a bit
Form0 = document.getElementById('FM'),
IM = document.getElementById("IM")
IM.src = Form0.DocName.value // Get and show the Form
setTimeout(Next, 1500) // Short delay needed here
}

function Next() { // Just show and remember original image details
Form0.Iwh.value = Wide = IM.width
Form0.Iht.value = High = IM.height
Draw() }

// ...
Michael Haufe (TNO) (10-14-18, 05:40 AM)
Dr J R Stockton wrote:
[..]
> Form0.Iwh.value = Wide = IM.width
> Form0.Iht.value = High = IM.height
> Draw() }


My first comment is that images have 'onload' and 'onerror' methods you can override. This will eliminate the need for the setTimeout:

img.onload = next
img.onerror = fail

Second, try using the .elements property of the form:

myForm.elements.inputName
myForm.elements["input-name"]

Third, you can access the original image size by using the .naturalHeight and .naturalWidth properties.

Fourth, you should use the JavaScript coding conventions. PascalCase is reserved for classes and constructor functions.

[1]
Evertjan. (10-14-18, 11:11 AM)
"Michael Haufe (TNO)" <tno> wrote on 14 Oct 2018 in
comp.lang.javascript:

[..]
> .naturalHeight and .naturalWidth properties.
> Fourth, you should use the JavaScript coding conventions. PascalCase is
> reserved for classes and constructor functions.


John, you could play with this:

==============
<body>
<script>
'use strict';
document.body.onload = () => {
const myDiv = document.createElement("DIV");
document.body.appendChild(myDiv);

const myImg = document.createElement("IMG");
myImg.setAttribute("src", "abcde.jpg");
document.body.appendChild(myImg);

myImg.onload = () => myDiv.innerHTML = myImg.naturalHeight;
};
</script>
==============
John G Harris (10-14-18, 12:18 PM)
On Sat, 13 Oct 2018 20:40:59 -0700 (PDT), "Michael Haufe (TNO)"
<tno> wrote:

>Dr J R Stockton wrote:


<snip>
>Fourth, you should use the JavaScript coding conventions. PascalCase is reserved for classes and constructor functions.


Its proper name is the Java naming convention. Java programmers have
to use it because it's built into several important system utilities.

There are no ECMAScript system utilities to appease so development
teams can use any naming convention they want. However, they are urged
to use their chosen convention consistently.

John
Dr J R Stockton (10-14-18, 03:01 PM)
On Sunday, October 14, 2018 at 4:41:08 AM UTC+1, Michael Haufe (TNO) wrote:
> Dr J R Stockton wrote:


> My first comment is that images have 'onload' and 'onerror' methods
> you can override. This will eliminate the need for the setTimeout:
> img.onload = next
> img.onerror = fail


Much better, and solves the problem. Thanks yet again.
But why did a generous Timeout not suffice?

> Second, try using the .elements property of the form:
> myForm.elements.inputName
> myForm.elements["input-name"]


In what way is that better, as I have used it, than just
myForm.input-name ?
is the latter likely to be deprecated away?

> Third, you can access the original image size by using the .naturalHeight and .naturalWidth properties.


Good. Done.

> Fourth, you should use the JavaScript coding conventions.
> PascalCase is reserved for classes and constructor functions.


A declared identifier is in effect a Noun; as far as I
recall, for those of significance I have always used
an initial capital letter, except maybe for loop counters.
I'm too old to train my Shift finger into a new convention.

Anyway, what I really want, in all browsers, is
<script type="text/pascal"> .

> [1]


I see from the reference that .elements allows types of
action which I doubt that I ever knew I wanted!

What I'd like to have is, to supplement window.innerWidth ,
is printerpaper.innerWidth .

I use @media print { .NPR { display: none; } } /* SB CIWAS 20140116 */
in CSS for HTML; is there some property by which ECMAscript can tell
whether the output is to screen or printer?
Evertjan. (10-14-18, 03:29 PM)
Dr J R Stockton <J.R.Stockton> wrote on 14 Oct 2018 in
comp.lang.javascript:

> I use @media print { .NPR { display: none; } } /* SB CIWAS 20140116 */
> in CSS for HTML; is there some property by which ECMAscript can tell
> whether the output is to screen or printer?


You could use:

window.onbeforeprint
and
window.onbeafterprint

.... to set style values as you want,
but not, methinks, to read the actual printing values.
Michael Haufe (TNO) (10-15-18, 06:42 AM)
Dr J R Stockton wrote:
> Michael Haufe wrote:


> Much better, and solves the problem. Thanks yet again.
> But why did a generous Timeout not suffice?


Because using a timeout is not directly related to the loading of the image. You don't know how long to wait and have reduced your reasoning to probability where it isn't necessary.

Analogy: When you send a letter in the mail, you can assume a 3 week wait is sufficient for it to arrive -or- you can request a receipt and know for certain.

> > Second, try using the .elements property of the form:
> > myForm.elements.inputName
> > myForm.elements["input-name"]

> In what way is that better, as I have used it, than just
> myForm.input-name ?
> is the latter likely to be deprecated away?


The .elements property was introduced to prevent collisions with other propertes on the element. For example:

<form action="https://example.com">
<input type="hidden" name="action" value="https://example.org">
</form>

<script>
var form = document.forms[0]
form.action
</script>

What does form.action return? What should it return? Is that what you expected?

Better to use the elements property and remove all doubt

> > Fourth, you should use the JavaScript coding conventions.
> > PascalCase is reserved for classes and constructor functions.

> A declared identifier is in effect a Noun; as far as I
> recall, for those of significance I have always used
> an initial capital letter, except maybe for loop counters.
> I'm too old to train my Shift finger into a new convention.


If your code remains private and for personal use only, it's of course irrelevant but once you code for others in the JavaScript community, conventions are key for understanding.

> Anyway, what I really want, in all browsers, is
> <script type="text/pascal"> .


This exists, but I've never used it:

<http://p2js.gelicon.biz/en>

> What I'd like to have is, to supplement window.innerWidth ,
> is printerpaper.innerWidth .
> I use @media print { .NPR { display: none; } } /* SB CIWAS 20140116 */
> in CSS for HTML; is there some property by which ECMAscript can tell
> whether the output is to screen or printer?


You utilize the new API window.matchMedia('print'):

<script>
var mediaQueryList = window.matchMedia('print');
mediaQueryList.addListener(function(mql) {
if (mql.matches) {
console.log('onbeforeprint equivalent');
} else {
console.log('onafterprint equivalent');
}
});
</script>

Details:

<https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries>

but there still remains some cross-browser issues:

<https://www.tjvantoll.com/2012/06/15/detecting-print-requests-with-javascript/>
Michael Haufe (TNO) (10-15-18, 07:06 AM)
John G Harris wrote:
> "Michael Haufe (TNO)":
> >Fourth, you should use the JavaScript coding conventions. PascalCase is reserved for classes and constructor functions.


> Its proper name is the Java naming convention. Java programmers have
> to use it because it's built into several important system utilities.


Why do you believe that is the case? It is inconsistent with anything I've ever seen:

<https://en.wikipedia.org/wiki/Camel_case>

> There are no ECMAScript system utilities to appease so development
> teams can use any naming convention they want. However, they are urged
> to use their chosen convention consistently.


Indeed, within reason. There are limitations to the JavaScript grammar and semantics which influence what the conventions are though.

Following Allman style[1] for example will cause you pain with semicolon insertion for example, so would allowing whitespace after a return statement.There are also legacy conventions which are still used in an evolved form,such as Crockford's [2]

There are also ecosystem constraints built on the assumptions of these conventions. For example, if you've ever worked on or with a .NET project, you are highly likely to encounter a Newtonsoft.Json configuration set to read and generate JSON based on camelCase property names

[1]
[2]
Dr J R Stockton (10-15-18, 02:02 PM)
On Monday, October 15, 2018 at 5:43:07 AM UTC+1, Michael Haufe (TNO) wrote:
> Dr J R Stockton wrote:
> > Michael Haufe wrote:
> > Much better, and solves the problem. Thanks yet again.
> > But why did a generous Timeout not suffice?

> Because using a timeout is not directly related to the loading of the image. You don't know how long to wait and have reduced your reasoning to probability where it isn't necessary.


We have a misunderstanding. The test image is small and on the
local hard drive, so should load without perceptible delay. When,
in Win7, I first considered the need for a delay-until-loaded, I
put in a simple alert() . Not a good final solution, but
tolerable (I did not need to wait before dismissing the alert)
and proving that a moderately generous delay should work
adequately in Win7. I then constructed a Timeout of maybe 3
seconds, which worked in Win7. But, to my surprise, it did
not work in Win10, even after a significant increase - _it is
that _difference_ between Win7 & Win10 that I was wondering about_.

> Analogy: When you send a letter in the mail, you can assume a 3 week wait is sufficient for it to arrive -or- you can request a receipt and know for certain.


But if no receipt arrives, one cannot know for certain whether the
letter arrived...

> The .elements property was introduced to prevent collisions with other propertes on the element. For example:
> <form action="https://example.com">
> <input type="hidden" name="action" value="https://example.org">
> </form>
> <script>
> var form = document.forms[0]
> form.action
> </script>
> What does form.action return? What should it return? Is that what you
> expected?


I would have expected to be confused by that, sooner or later, and
therefore would have chosen name="akshun" (Thomas might have
used Wirkung). I have a strong tendency to avoid spelling my
identifiers in the same way as anything else in the script, the
page, or the file set...

> Better to use the elements property and remove all doubt


But I see your point.

> If your code remains private and for personal use only, it's of course irrelevant but once you code for others in the JavaScript community, conventions are key for understanding.
> This exists, but I've never used it:
> <http://p2js.gelicon.biz/en>


Ingenious; the page is worth looking at, if only for amusement.
Debugging one's Pascal source code might be rather difficult,
using a browser's view of the JavaScript - but I suppose the
source would normally have been well-debugged in a Pascal system.

A quick check suggests that the cited page is a Google
Translate of the original Russian, and that Russian-English
Translate has not been greatly changed since.

[..]
> <https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries>
> but there still remains some cross-browser issues:
> <https://www.tjvantoll.com/2012/06/15/detecting-print-requests-with-javascript/>


Seems rather fraught. I can already scale the stuff on-screen first,
and printing can be done with Print Preview - those will suffice.

OT:

Led there by one of your cites - have you any connection with, or
influence over,
?
There, section 4.10.1.8 Date, time, and number formats, paragraph 5,
last sentence, is objectionable. That format is, AIUI, in common
normal use in Japan (except when using pure Japanese) - and it is
probably preferred by many individuals, as well as by me.
Evertjan. (10-15-18, 04:06 PM)
Dr J R Stockton <J.R.Stockton> wrote on 15 Oct 2018 in
comp.lang.javascript:

> We have a misunderstanding. The test image is small and on the
> local hard drive, so should load without perceptible delay. When,
> in Win7, I first considered the need for a delay-until-loaded, I
> put in a simple alert() . Not a good final solution, but
> tolerable (I did not need to wait before dismissing the alert)
> and proving that a moderately generous delay should work
> adequately in Win7. I then constructed a Timeout of maybe 3
> seconds, which worked in Win7.


But what is wrong with 'image.onload'?
It should take care of any timing problem?

Or, you could build the onload yourself, as, [if my stipulation that the
measured width is either 0 or the true value is correct,] you could build a
a module testing for this zero and repeating that after a small timeout till
the value is nolonger zero.

> But, to my surprise, it did
> not work in Win10, even after a significant increase - _it is
> that _difference_ between Win7 & Win10 that I was wondering about_.


WeLl, you would have to specify the engine you are talking about,
so the browesr type and version. And perhaps the O.S. core functions could
be different.
Dr J R Stockton (10-16-18, 12:43 AM)
On Monday, October 15, 2018 at 3:07:09 PM UTC+1, Evertjan. wrote:
> Dr J R Stockton wrote on 15 Oct 2018 in
> comp.lang.javascript:
> But what is wrong with 'image.onload'?
> It should take care of any timing problem?


Indeed, but I was not aware of that method at the time.
ANYTHING that got the image loaded was a good TEMPORARY
solution, enabling me to make progress with handling the
later parts of the job.

> Or, you could build the onload yourself, as, [if my stipulation that the
> measured width is either 0 or the true value is correct,] you could build a
> a module testing for this zero and repeating that after a small timeout till
> the value is nolonger zero.


That stipulation is an assumption, and false; but a
test for image size>50 might have worked.
Similar Threads