Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #30667 > unrolled thread

Failing to get DIV content to flip between initial and alternate version

Started by$Bill <news@todbe.com>
First post2016-06-16 23:18 -0700
Last post2016-06-25 19:02 +0200
Articles 10 on this page of 30 — 8 participants

Back to article view | Back to comp.lang.javascript


Contents

  Failing to get DIV content to flip between initial and alternate version $Bill <news@todbe.com> - 2016-06-16 23:18 -0700
    Re: Failing to get DIV content to flip between initial and alternate version "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-06-17 11:32 +0200
      Re: Failing to get DIV content to flip between initial and alternate version $Bill <news@todbe.com> - 2016-06-17 19:00 -0700
        Re: Failing to get DIV content to flip between initial and alternate version "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-06-18 11:35 +0200
          Re: Failing to get DIV content to flip between initial and alternate version $Bill <news@todbe.com> - 2016-06-18 19:16 -0700
            Re: Failing to get DIV content to flip between initial and alternate version Doc O'Leary  <droleary@2015usenet1.subsume.com> - 2016-06-19 14:23 +0000
              Re: Failing to get DIV content to flip between initial and alternate version $Bill <news@todbe.com> - 2016-06-20 04:13 -0700
                Re: Failing to get DIV content to flip between initial and alternate version $Bill <news@todbe.com> - 2016-06-20 04:16 -0700
                  Re: Failing to get DIV content to flip between initial and alternate version "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-06-26 12:53 +0200
                    Re: Failing to get DIV content to flip between initial and alternate version $Bill <news@todbe.com> - 2016-06-26 16:22 -0700
                      Re: Failing to get DIV content to flip between initial and alternate version "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-06-27 10:49 +0200
                      Re: Failing to get DIV content to flip between initial and alternate version Doc O'Leary  <droleary@2015usenet1.subsume.com> - 2016-06-27 13:58 +0000
                  Re: Failing to get DIV content to flip between initial and alternate version Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-06-27 05:43 +0200
                    Re: Failing to get DIV content to flip between initial and alternate version John Harris <niam@jghnorth.org.uk.invalid> - 2016-06-27 09:38 +0100
                      Re: Failing to get DIV content to flip between initial and alternate version "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-06-27 11:00 +0200
                        Re: Failing to get DIV content to flip between initial and alternate version John Harris <niam@jghnorth.org.uk.invalid> - 2016-06-28 10:04 +0100
                          Re: Failing to get DIV content to flip between initial and alternate version "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-06-28 12:13 +0200
                            Re: Failing to get DIV content to flip between initial and alternate version John Harris <niam@jghnorth.org.uk.invalid> - 2016-06-29 16:16 +0100
                              Re: Failing to get DIV content to flip between initial and alternate version "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-06-29 19:48 +0200
            Re: Failing to get DIV content to flip between initial and alternate version "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-06-25 16:40 +0200
      Re: Failing to get DIV content to flip between initial and alternate version "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-18 10:59 -0700
        Re: Failing to get DIV content to flip between initial and alternate version Stanimir Stamenkov <s7an10@netscape.net> - 2016-06-18 22:32 +0300
          Re: Failing to get DIV content to flip between initial and alternate version "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-18 13:50 -0700
            Re: Failing to get DIV content to flip between initial and alternate version Stanimir Stamenkov <s7an10@netscape.net> - 2016-06-19 09:40 +0300
              Re: Failing to get DIV content to flip between initial and alternate version "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-19 12:21 -0700
              Re: Failing to get DIV content to flip between initial and alternate version Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-06-25 18:37 +0200
      Re: Failing to get DIV content to flip between initial and alternate version Stanimir Stamenkov <s7an10@netscape.net> - 2016-06-18 22:17 +0300
        Re: Failing to get DIV content to flip between initial and alternate version "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-06-25 16:45 +0200
          Re: Failing to get DIV content to flip between initial and alternate version "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-25 17:17 +0200
            Re: Failing to get DIV content to flip between initial and alternate version "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-06-25 19:02 +0200

Page 2 of 2 — ← Prev page 1 [2]


#30679

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2016-06-18 10:59 -0700
Message-ID<9f7327d0-11b9-4ff1-98aa-e8f55701d962@googlegroups.com>
In reply to#30669
On Friday, June 17, 2016 at 4:32:20 AM UTC-5, Evertjan. wrote:

> then you can set the <script> inside the <head>, where it belongs.

No.

It should be placed right before </body> to make the onload redundant, and to allow the page to render faster. Also an explicit type attribute should be provided.

[toc] | [prev] | [next] | [standalone]


#30681

FromStanimir Stamenkov <s7an10@netscape.net>
Date2016-06-18 22:32 +0300
Message-ID<nk47km$81a$1@dont-email.me>
In reply to#30679
Sat, 18 Jun 2016 10:59:03 -0700 (PDT), /Michael Haufe (TNO)/:
> On Friday, June 17, 2016 at 4:32:20 AM UTC-5, Evertjan. wrote:
>
>> then you can set the <script> inside the <head>, where it belongs.
>
> No.
>
> ... Also an explicit type attribute should be provided.

As someone else has written in this thread, <script> will do in the 
21 century.  If the type is "text/javascript" specifying it is 
pretty much redundant, and all examples I'm seeing in latest 
specifications do not use 'type' attribute, if not necessary:

https://www.w3.org/TR/html5/scripting-1.html#the-script-element

(search for "<script" w/o quotes on the page)

-- 
Stanimir

[toc] | [prev] | [next] | [standalone]


#30683

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2016-06-18 13:50 -0700
Message-ID<85fe3ea5-5a7f-4ae3-ba26-ee72c9ef9604@googlegroups.com>
In reply to#30681
On Saturday, June 18, 2016 at 2:32:43 PM UTC-5, Stanimir Stamenkov wrote:
> Sat, 18 Jun 2016 10:59:03 -0700 (PDT), /Michael Haufe (TNO)/:
> > On Friday, June 17, 2016 at 4:32:20 AM UTC-5, Evertjan. wrote:
> >
> >> then you can set the <script> inside the <head>, where it belongs.
> >
> > No.
> >
> > ... Also an explicit type attribute should be provided.
> 
> As someone else has written in this thread, <script> will do in the 
> 21 century.  If the type is "text/javascript" specifying it is 
> pretty much redundant, and all examples I'm seeing in latest 
> specifications do not use 'type' attribute, if not necessary:
> 
> https://www.w3.org/TR/html5/scripting-1.html#the-script-element
> 
> (search for "<script" w/o quotes on the page)

I would agree with you in principle only if the following is no longer considered valid and is ignored in HTML5:

<https://www.w3.org/TR/html4/interact/scripts.html#h-18.2.2>

Also, contingent on downrev browser behavior. For instance, even though older IE versions would trigger strict mode when seeing the new doctype, they may indeed still follow the legacy algorithm for determining script type. 

How many browsers are considered 100% HTML5 compliant right now anyway? Not that they would need to be of course, but in this particular case I haven't seen any stats one way or another on whether this is implemented.

[toc] | [prev] | [next] | [standalone]


#30690

FromStanimir Stamenkov <s7an10@netscape.net>
Date2016-06-19 09:40 +0300
Message-ID<nk5ep5$hc5$1@dont-email.me>
In reply to#30683
Sat, 18 Jun 2016 13:50:58 -0700 (PDT), /Michael Haufe (TNO)/:
> On Saturday, June 18, 2016 at 2:32:43 PM UTC-5, Stanimir Stamenkov wrote:
>
>> As someone else has written in this thread, <script> will do in the
>> 21 century.  If the type is "text/javascript" specifying it is
>> pretty much redundant, and all examples I'm seeing in latest
>> specifications do not use 'type' attribute, if not necessary:
>>
>> https://www.w3.org/TR/html5/scripting-1.html#the-script-element
>>
>> (search for "<script" w/o quotes on the page)
>
> I would agree with you in principle only if the following is no
> longer considered valid and is ignored in HTML5:
>
> <https://www.w3.org/TR/html4/interact/scripts.html#h-18.2.2>

"As HTML does not rely on a specific scripting language, document 
authors must explicitly tell user agents the language of each script."

I suspect this has never been true in reality.  JavaScript has ever 
been the only scripting language on the Web.

> Also, contingent on downrev browser behavior. For instance, even
> though older IE versions would trigger strict mode when seeing
> the new doctype, they may indeed still follow the legacy
> algorithm for determining script type.

If one has to support older browser versions it would need to be 
tested, and adjusted if not really working there.  Have you 
experienced a case/browser where it is not working?

> How many browsers are considered 100% HTML5 compliant right now
> anyway? Not that they would need to be of course, but in this
> particular case I haven't seen any stats one way or another on
> whether this is implemented.

I'm speculating it is implemented in all recent version browsers, 
and probably supported by older version browsers, but I would like 
to see some representative stats, also.

-- 
Stanimir

[toc] | [prev] | [next] | [standalone]


#30694

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2016-06-19 12:21 -0700
Message-ID<761b79a1-3fef-407d-957a-e78860617e4e@googlegroups.com>
In reply to#30690
On Sunday, June 19, 2016 at 1:40:42 AM UTC-5, Stanimir Stamenkov wrote:

> "As HTML does not rely on a specific scripting language, document 
> authors must explicitly tell user agents the language of each script."
> 
> I suspect this has never been true in reality.  JavaScript has ever 
> been the only scripting language on the Web.

That is just simply false. Internet Explorer versions below 11 support type="text/vbscript" and IE 11 also supports it in compatibility mode. This support is extensible and on a number of Windows machines you can find other languages added (such as Perl). Usually for use in *.hta applications, but once registered, the functionality is available for the regular browser as well. (Both leverage mshtml.dll)

In Firefox, you can trigger different versions of JavaScript explicitly (incompatible with the ECMAScript standard), for example:

type="application/javascript;version=1.8"

Mozilla also experimented with Python embedding for a short period. There is also the skulpt project which tries to do the same.

Let's also not forget the existence of 3D on the web which utilizes:

type="x-shader/x-vertex"

and

type="x-shader/x-fragment"

So while yes, it will PROBABLY be JavaScript if you leave the type attribute implicit, Wouldn't you prefer to have a guarantee by being explicit about your intent?

> If one has to support older browser versions it would need to be 
> tested, and adjusted if not really working there.  Have you 
> experienced a case/browser where it is not working?

Do you only develop for an evergreen browser? If not than you are always supporting an older browser.

Have I experience issues with this behavior? Yes, perhaps a dozen times. Often this has been due to upgrading a website while still leveraging existing server infrastructure (which will send unexpected headers to the client), other times due to the necessity of developing larger enterprise applications which extend across intranets and extranets, which gives you a very large range of browsers you have to support.

This is one less thing to test if you are explicit, and is also future proof when the standards change again.

> I'm speculating it is implemented in all recent version browsers, 
> and probably supported by older version browsers, but I would like 
> to see some representative stats, also.

Explicit Is Better Than Implicit (EIBTI) in this case. I don't need to test for edge cases, and don't need to see statistics.

[toc] | [prev] | [next] | [standalone]


#30726

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2016-06-25 18:37 +0200
Message-ID<8292076.eNJFYEL58v@PointedEars.de>
In reply to#30690
Stanimir Stamenkov wrote:

> Sat, 18 Jun 2016 13:50:58 -0700 (PDT), /Michael Haufe (TNO)/:
>> I would agree with you in principle only if the following is no
>> longer considered valid and is ignored in HTML5:
>>
>> <https://www.w3.org/TR/html4/interact/scripts.html#h-18.2.2>
> 
> "As HTML does not rely on a specific scripting language, document
> authors must explicitly tell user agents the language of each script."
> 
> I suspect this has never been true in reality.

It has been.

> JavaScript has ever been the only scripting language on the Web.

No, nor is it the only scripting language now (even the fact aside that 
there is not only one “JavaScript”, nor does “JavaScript” refer to all 
ECMAScript implementations in use in browsers).  The supported ECMAScript 
implementation is only the default scripting language since HTML5
(2014-10-28).

<https://www.w3.org/TR/2014/REC-html5-20141028/scripting-1.html#scriptingLanguages>
<https://www.w3.org/TR/2014/REC-html5-20141028/scripting-1.html#attr-script-type>

There is no harm in specifying the default scripting language in HTML5 
explicitly, though.
 
>> Also, contingent on downrev browser behavior. For instance, even
>> though older IE versions would trigger strict mode when seeing
>> the new doctype, they may indeed still follow the legacy
>> algorithm for determining script type.
> 
> If one has to support older browser versions it would need to be
> tested, and adjusted if not really working there.  Have you
> experienced a case/browser where it is not working?

Yes.
 
>> How many browsers are considered 100% HTML5 compliant right now
>> anyway? Not that they would need to be of course, but in this
>> particular case I haven't seen any stats one way or another on
>> whether this is implemented.
> 
> I'm speculating it is implemented in all recent version browsers,
> and probably supported by older version browsers, but I would like
> to see some representative stats, also.

There are a test case and some (old) results at 
<http://wayback.archive.org/web/20100904140711/http://pointedears.de/scripts/test/mime-types/> whose revival and update is still on my to-do list.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]


#30680

FromStanimir Stamenkov <s7an10@netscape.net>
Date2016-06-18 22:17 +0300
Message-ID<nk46oh$50b$1@dont-email.me>
In reply to#30669
Fri, 17 Jun 2016 11:32:18 +0200, /Evertjan./:
> $Bill wrote on 17 Jun 2016 in comp.lang.javascript:
>
>> <!-- button to test FlipType -->
>> <FORM>
>>     <!-- for some reason FlipType is executed twice when I click it ???
>>     maybe the body is re-loading from onload ??? -->
>>     <BUTTON onclick="FlipType()">Flip View</BUTTON>
>
> The form is executed, so the page reloads and the javascript execution is
> lost, so do a "return false" to prevent the form from executing:
>
> <button onclick='flipType();return false;'>Flip View</button>
>
> or set the <button> outside a <form>

Or use <button type="button" onclick="filtType()">Flip View</button>.

-- 
Stanimir

[toc] | [prev] | [next] | [standalone]


#30721

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2016-06-25 16:45 +0200
Message-ID<XnsA632AA7BF5375eejj99@194.109.6.166>
In reply to#30680
Stanimir Stamenkov <s7an10@netscape.net> wrote on 18 Jun 2016 in 
comp.lang.javascript:

> Fri, 17 Jun 2016 11:32:18 +0200, /Evertjan./:
>> $Bill wrote on 17 Jun 2016 in comp.lang.javascript:
>>
>>> <!-- button to test FlipType -->
>>> <FORM>
>>>     <!-- for some reason FlipType is executed twice when I click it ???
>>>     maybe the body is re-loading from onload ??? -->
>>>     <BUTTON onclick="FlipType()">Flip View</BUTTON>
>>
>> The form is executed, so the page reloads and the javascript execution is
>> lost, so do a "return false" to prevent the form from executing:
>>
>> <button onclick='flipType();return false;'>Flip View</button>
>>
>> or set the <button> outside a <form>
> 
> Or use <button type="button" onclick="filtType()">Flip View</button>.

Right you are, but it does not "feel" right 
that a button inside a form is not a button by default.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]


#30722

From"Christoph M. Becker" <cmbecker69@arcor.de>
Date2016-06-25 17:17 +0200
Message-ID<nkm79g$pf7$1@solani.org>
In reply to#30721
On 25.06.2016 at 16:45, Evertjan. wrote:

> Stanimir Stamenkov <s7an10@netscape.net> wrote on 18 Jun 2016 in 
> comp.lang.javascript:
> 
>> Or use <button type="button" onclick="filtType()">Flip View</button>.
> 
> Right you are, but it does not "feel" right 
> that a button inside a form is not a button by default.

The default value of the type attribute of a button is submit.  IMO,
that's particularly useful, if the button is a child of a form.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]


#30727

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2016-06-25 19:02 +0200
Message-ID<XnsA632C1C8A7F38eejj99@194.109.6.166>
In reply to#30722
"Christoph M. Becker" <cmbecker69@arcor.de> wrote on 25 Jun 2016 in 
comp.lang.javascript:

> On 25.06.2016 at 16:45, Evertjan. wrote:
> 
>> Stanimir Stamenkov <s7an10@netscape.net> wrote on 18 Jun 2016 in 
>> comp.lang.javascript:
>> 
>>> Or use <button type="button" onclick="filtType()">Flip View</button>.
>> 
>> Right you are, but it does not "feel" right 
>> that a button inside a form is not a button by default.
> 
> The default value of the type attribute of a button is submit.  IMO,
> that's particularly useful, if the button is a child of a form.

Quite, if you think/feel error-proneness equals usefulness.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript


csiph-web