reptile7's JavaScript blog
Wednesday, April 26, 2017
Every <img> Tells a Story
Blog Entry #372

There hasn't been any new content to speak of at this blog for a while now but that doesn't mean I've been sitting around twiddling my thumbs. Over the past year or so I've been hard at work restoring the many images, demos, and code samples that vanished into the mist after I pulled the plug on my EarthLink subscription in April 2014, and I'm pleased as punch to report that I've redeployed those objects in their entirety and in all their former glory (more or less) as of this writing. The image part of my re-inclusion odyssey is recounted below.

Background notes before getting under way:
• I joined EarthLink in November 2000 and had therefore been with EarthLink for about 4½ years before I began blogging in March 2005.
• EarthLink provides as a benefit to its members some free server space: 6MB' worth back in the day, 10MB at present.
• I was spurred to begin blogging by a "Build Your Own Blog" article in Issue 48 of EarthLink's eLink newsletter.
• Shortly before I began blogging I purchased the Fetch FTP client for $25.

Prior to April 2014, all of the images of this blog were hosted by EarthLink, in a directory, vis-à-vis by Blogger itself.

Very early on I would just link to my images

<a href="">Web Content settings</a>

rather than actually display them (I was a rookie at that point, cut me some slack); starting with Blog Entry #20 I displayed them, initially with Blogger's help

<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href=""><img style="cursor:pointer; cursor:hand;" src="" border="0" alt="" /></a>

and then without.

<img name="img23" width="150" height="150" src="">

(I have no idea what the deselectBloggerImageGracefully( ) function was or did: if it were available, a parent.deselectBloggerImageGracefully.toString( ) command would return its source code, but it isn't.)

Fast-forward to the present. Hosting my images with Blogger was the cheapest, easiest, and quickest way to bring them back, so that's what I did. Here's how my image upload process goes:

Working in Blogger's HTML mode (I never work in Compose mode, its much larger toolbar notwithstanding, as I always like to see a post's HTML sitting right in front of me)

I click the

control (the one that gives an Insert image tooltip when you mouseover it) of the

The Blogger HTML mode toolbar

toolbar. Up pops an Add Images pane.

The Add Images pane before choosing any files

The pre-selected Upload option is the one we want; we click its control to open a File Upload window
The File Upload window before selecting any files
for navigating to an image file that we want to upload to Blogger. Selecting the Alli.jpg file in the Desktop/ directory previews the file and activates the button.
The File Upload window after selecting the Alli.jpg file
Clicking the button uploads the file and brings us back to the Add Images pane.

The Add Images pane after choosing the Alli.jpg file

Clicking the button takes us to a Choose a layout pane.

The Choose a layout pane

As shown above, I prefer None for the Image alignment and Original size for the Image size. Clicking the pane's button outputs the uploaded image code.

<a href="" imageanchor="1" ><img border="0" src="" /></a>

The img element is wrapped in an anchor element; the former's src attribute and the latter's href attribute point to a common, unintuitive, and irregular address.

The anchor element is equipped with an imageanchor="1" attribute. As you might guess, the imageanchor attribute isn't standard - cf. the Attributes table at W3Schools' HTML <a> Tag page - and I have no idea what purpose the imageanchor="1" setting serves, if any; if it is meant to be an identifier of some kind, we should replace it with a class="imageanchor" attribute given that the getElementsByClassName( ) method is now a standard member of the Core DOM's Element interface. (If anyone at the W3C is reading this, you should update the DOM4 section of the DOM Technical Reports portal, which incorrectly states that the W3C DOM4 specification is still at the Working Draft stage.)

But do we need the anchor parent in the first place? Not really - throw it out if you feel it's excess baggage.
(FYI: None of my images has an imgObject.oncontextmenu = function ( ) { return false; } listener: you are free to right-click and 'probe' them as you wish.)

Blogger no longer (vide supra) equips the img element with an alt attribute, which is #REQUIRED, so we'll need to add one if we want to run the page through a markup validator.

No width/height attributes are supplied for an Original size image, but I add them anyway because I like having the dimension data in the source (moreover, doing this would have been important once upon a time); we'd get them for a Small, Medium, Large, or X-Large image.

The img border attribute was deprecated by HTML 4, whereas in HTML5 the border="0" setting is an obsolete but conforming feature - I usually let this one be but for the purpose of validation you could just delete it given that the initial border-style value is none.

The None alignment gives an inline*, normal flow anchor-image. (*Most of my images seem to have a block-level rendering but that's because they're flanked by br elements.) I'm not going to detail the other alignments: in brief, the Left and Right alignments float the anchor parent left and right, respectively, whereas the Center alignment horizontally centers the anchor-image by putting it in a text-align:center;-ed div.

Putting it all together, I would code the Alli.jpg image with:

<br />
<img width="430" height="330" border="0" src="" alt="Alli, the sleeping kitty" />
<br />

Alli, the sleeping kitty
I'll address my lost demos and code samples in the next entry.

Powered by Blogger

Actually, reptile7's JavaScript blog is powered by Café La Llave. ;-)