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

Groups > comp.lang.javascript > #30300

Re: A few problems with looping thru a set of elements withthesame"name" specifier.

Show all headers | View raw

R.Wieser wrote:
>> * It augments host objects (adds a `slideIndex` property to the image
>> objects). While the current major browsers all support this, it has
>> historically led to problems that were hard to debug. In general, it's
> best
>> avoided, and there are other ways to associate custom values with objects.
> 
> A guess: using the above mentioned "data-*" attributes ?

That's one possibility. I would probably keep the index in a closure, but
that would require a completely different approach.

Since `slideIndex` only holds an integer number, it's very unlikely to cause
trouble, even in older browsers. The potential for naming conflicts should
probably be mentioned - e.g., image objects getting a native "slideIndex"
property in the future. This is equally unlikely, but it's one more reason
why augmenting host objects is usually avoided.

>> * The original image (in the "src" attribute) is loaded, but then
>> immediately switched out for slide1. This is unnecessary.
> 
> Not quite:  That first image will be visible for anyone having JS blocked.
> It was a consious decision to have it behave that way.

I see, that makes sense. It may cause some duplication ("src" will probably
contain the same URL as "slide1"). In that case, I would use something like
this:

  <img src="slide1.png" data-slides="slide2.png|slide3.png|..."

>> * The original code uses `a+ ++b`, which I personally think is a
>> capital offense in coding ;) What this does:
>>   - use ++ to put `undefined` in a numeric context, giving 0
>>   - use ++ to pre-increment that value, giving 1
>>   - use + for string concatenation, giving "slide1"
>> All that in the conditional expression in an `if` statement.
> 
> Well, I also thought about that (being an offence).  But as I have worked
> with other languages where non-existing variables where simply
> created-on-use and given the value Zero, I did not see anything strange in
> JS doing the same.
> 
> As for it being part of a conditional expression, the language C{something}
> does not seem to have any troubles with it, so I did/do not see a problem
> here either.

The interpreter has no problem with it, my eyes do ;)
It works as intended. My issue is that it's hard to read: it requires
knowledge about operator precedence and two different type conversions, and
it creates and initializes the `slideIndex` property in the conditional.
There's just too much going on for this line to be easily understood by
another programmer.

>> * <script language="JavaScript"> is quite obsolete now. Use
>> <script type="text/javascript"> or just <script> instead.
> 
> Thanks for the suggestion.   I assume that "script" now just defaults to JS
> (as opposed to Microsofts own VBS) ?
> 
> By the way, any idea why a script type should be "*text*/javascript" ?   Are
> there any other types of JS available (precompiled (semy-)binary blobs
> perhaps?) ?   In other words, that "text" seems to be rather superfluous ...

That's a very good question. The value of the "type" attribute is supposed
to be the MIME type of the contained (or referenced) script. Official MIME
types are published by IANA and consist of a top level type ("text",
"application", "image", "video", ...) and a subtype. A script is program
source code, not text, so it should theoretically be in the "application"
category. According to RFC 4329 (2006), the proper MIME type is either
"application/javascript" or "application/ecmascript" (and the two are not
exactly the same). That RFC also officially defined "text/javascript" and
"text/ecmascript" but immediately marked them as obsolete.

So much for theory. In practice, "text/javascript" has been used in the
overwhelming majority of cases, while any of the mentioned alternatives
caused some browsers (notably IE) to ignore the script completely, making
them technically correct but useless. Conversely, scripts without any "type"
or "language" attributes have always been interpreted by browsers as
JavaScript. HTML5 has now codified this behavior, defining that the absence
of type/language attributes defaults to the type "text/javascript", and
defining JavaScript as the default scripting language (with some side notes
about the naming of the language).

Recently, another use for the "type" attribute has been added to define
scripts as modules. This is an interesting new development, but irrelevant
for you if you want broad browser support.

I fully expect our resident standards expert to chime in with some
invaluable corrections and ridicule concerning the last few paragraphs.


- stefan

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

A few problems with looping thru a set of elements with the same "name" specifier. "R.Wieser" <address@not.available> - 2016-04-17 13:22 +0200
  Re: A few problems with looping thru a set of elements with the same "name" specifier. Stefan Weiss <krewecherl@gmail.com> - 2016-04-17 15:30 +0200
    Re: A few problems with looping thru a set of elements with the same"name" specifier. "R.Wieser" <address@not.available> - 2016-04-17 18:54 +0200
      Re: A few problems with looping thru a set of elements with the same"name" specifier. Stefan Weiss <krewecherl@gmail.com> - 2016-04-18 19:46 +0200
        Re: A few problems with looping thru a set of elements with thesame"name" specifier. "R.Wieser" <address@not.available> - 2016-04-18 20:28 +0200
          Re: A few problems with looping thru a set of elements with thesame"name" specifier. Stefan Weiss <krewecherl@gmail.com> - 2016-04-18 22:54 +0200
            Re: A few problems with looping thru a set of elements withthesame"name" specifier. "R.Wieser" <address@not.available> - 2016-04-19 11:24 +0200
              Re: A few problems with looping thru a set of elements withthesame"name" specifier. Stefan Weiss <krewecherl@gmail.com> - 2016-04-19 15:42 +0200
                Re: A few problems with looping thru a set of elements withthesame"name" specifier. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-19 20:08 +0200
  Re: A few problems with looping thru a set of elements with the same "name" specifier. Stefan Weiss <krewecherl@gmail.com> - 2016-04-17 15:36 +0200

csiph-web