R.Wieser
4/19/2016 3:09:00 PM
Stefan,
> I would probably keep the index in a closure, but
> that would require a completely different approach.
Hmm ... Instead of storing the counter in the element it is ment for, its
stored in the script. To be honest, I'm not so sure I would like that.
And even if that approach does work for the current script, I think that
calling a function using the "this" argument would than throw a big wrench
into the machinery.
> 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:
Possible, but not nessesarily. The first image could be collage of what the
slides would offer, or even an animated GIF with just a few slides. Yes, I
did put some tought into it :-).
> <img src="slide1.png" data-slides="slide2.png|slide3.png|..."
Thought about that too. But than I would need to "explode" that
"data-slides" string into an array before usage. Every time any of the
images slides would change, as each image could have its own slides (and
ammount thereof).
Also, it would make it rather unreadable if someone uses images from another
host (using full URLs).
> The interpreter has no problem with it, my eyes do ;)
To be honest, so did mine.
I did however defer looking into it until I had the other problems nailed.
Maybe just placing a set of brackets around the pre-incremented property
would solve the readability problem.
> The value of the "type" attribute is supposed to be the MIME
> type of the contained (or referenced) script.
Yes, I recognised it as a MIME type.
But I have no clue to why it is used in an HTML environment. If there is
only a single way to include JavaScript into a HTML page and there is no
fall-back available for it its... rather superfluous. Its different for
email, where the fallback could be to (just) display the the contents as the
primary type (in this case, text).
Ofcourse, this would not work for an "image" primary type ...
> I fully expect our resident standards expert to chime in with
> some invaluable corrections and ridicule concerning the last
> few paragraphs.
Hmmm ... I'm not really theoretically inclined. I normally take such
commitee-generated documents as informational, and than look at how its
implemented in the real world. 'Cause *thats* what I have to work with.
Regards,
Rudy Wieser
-- Origional message:
Stefan Weiss <krewecherl@gmail.com> schreef in berichtnieuws
nf5ckn$b6k$1@news.albasani.net...
> 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