blog@tomauger.com

Development news, browser quirks, design factoids. Good stuff.

Archive for category Web Development

Reclaiming the

Apr 9

Posted by admin in Browser Bugs and Fixes, HTML, Tips and Tricks, Web Development, XHTML | No Comments

Have you discovered the <button> tag yet? It’s actually pretty cool, making it easy(er) to style submit buttons and the like to do things like, say, put pretty icons in front of the button text and so forth.

The button tag looks like this:

<button type=”submit” name=”action” value=”delete_123″>Delete This Item</button>

You can even put other cool HTML inside the button:

<button type=”submit” name=”submit” value=”resetPwd”><span class=”resetIcon”>Reset Your Password</span></button>

This gives you a lot of control, which otherwise might need to be done with one or more (non-semantic) wrappers outside of an <input type=”submit” /> tag.

The real beauty (for me) of the <button> tag, is that the value that is send to your server-side (PHP, Perl whatever) can be different from the message that is displayed to the user. In the first example shown, you could imagine a list of products, each of which has a “Delete This Item” button. The User sees “Delete This Item”, but the server gets “delete_123″ and, with some very simple string splitting, can figure out what action you want it to do (delete) and what item to delete (123).

Cool.

Well, well, well, this is probably the first time I’ve seen IE break the server-side of things, but they’ve managed to cock that up too. Note that this has supposedly been addressed in IE8, but we’re not just targeting IE8 when we write RIAs are we?

The issue is that IE 6, 7 contravene the HTML 4.0 standard, and send the <button> tag’s innerHTML rather than the value!

Can you imagine that?

So what the server gets (when submitted from IE only) is:

<SPAN class=resetIcon>Reset Your Password</SPAN>

(do note that IE converts to upper case AND removes quotes from attributes as well. Awesomeness.)

All other browsers submit:

resetPwd.

Read the rest of this entry »

IE DOM Elements don’t support hasOwnProperty()

Apr 7

Posted by admin in Browser Bugs and Fixes, JavaScript, Technology, Web Development, XHTML | No Comments

Couldn’t find anything really definitive on this, so here it is. Object.hasOwnProperty() is defined by EMACS and is supposed to be present on any (and all) objects in JavaScript.

So this would (normally) make a good way to make sure that a DOM element has a certain method before calling it (particularly to be safe if the DOM object for some reason doesn’t exist as expected)

For example:

elem = document.getElementById("someDOMElement");
if (elem.hasOwnProperty("innerHTML")){
  // ... do something cool with the innerHTML of this element
}

Unfortunately, this technique fails out of hand in IE because, although native Objects do support this method, for some reason DOM objects do NOT. So it will always fail, and more likely give you the dreaded “object does not support this property or method”, which is precisely the reason you wanted to use this method in the first place!

IE can go to hell. What’s wrong with these people?

JavaScript: Unobtrusive Script Execution onLoad or on DOMReady that Plays Nice with Legacy BODY onLoad

Jun 29

Posted by admin in HTML, JavaScript, Tips and Tricks, Web Development, XHTML | No Comments

It’s been documented quite a bit on the web already: proper use of  unobtrusive JavaScript in your web pages to achieve not only behavioural separation (keeping content, style and functionality separated into HTML, CSS and JavaScript documents respectively) but also degrade gracefully, to support browsers or platforms where JavaScript is not available. These two concepts form the heart of the development ethic in New Web development:

  • Keep your HTML markup completely free of all inline styles and inline JavaScript (in essence, try to use only those attributes inside your HTML tags that are absolutely necessary
  • Do not make JavaScript a requirement to be able to access content / functionality on your sites (anticipate the user who is not using JavaScript during the browsing experience)

Using DOM traversal methods such as getElementsByTagName() and regular expressions on the class attribute, you can fairly easily parse through your markup and unobtrusively add in your behavioural JavaScript, eliminating the need to add onClick=”" or onMouseOver=”" attributes inline. However, this is all still done with JavaScript so at some point, the JavaScript code to do this unobtrusive replacement must be executed. Since it can only be executed once all the relevant DOM elements have been loaded, this has been traditionally done using the (inline) onLoad=”" attribute within the <BODY> tag.

For the purists, this represents an issue since we’re not achieving total separation. One migh argue that even putting the <script> tag in the head of the document is too tight of a coupling, but I don’t know of anyone who has cracked that chestnut yet, nor does it seem likely that we’re even going to go there.

Regardless of whether you’re that die-hard, there’s a certain elegance in letting your scripts execute themselves without any further dependencies in the HTML – you include the external .js file in your HTML’s header tag and it takes care of itself from then on. Set it and forget it.

Read the rest of this entry »

Updates Gone Bad: Adobe Acrobat 9 and Mozilla Firefox 3

Jan 9

Posted by admin in Software, Technology, Web Development | No Comments

 I don’t like wasting people’s time (what few readers I may have) with rants and raves, but I got hit in the gut twice recently by unfortunate updates.

Being the progressive guy that I am, I upgraded my Adobe Acrobat Reader software (upon ceaseless prompting by Adobe Updater) to Acrobat Reader 9. I also installed Adobe Acrobat (the full version) 8 within a short timeframe. At some point in that flurry of acrobatic upgrades, I lost my ability to display PDFs in my browser window. Explorer, Firefox, Safari, Opera – nada, zilch, bubkus, zeeero. Like so many other busy (lazy) computer professionals, I ignored it and did the Ctrl-click Save As… workaround.

Then today, after having been adamantly refusing to upgrade Firefox 2.0.0.19 to 3 (for a host of reasons – though it is installed on my web development testing laptop), I caught, out of the corner of my eye, Firefox unashamedly installing FF 3.0.5 without my consent. I cancelled, went to my prefs, ensured that “automatic updates” was OFF(!!) and happily went about my business. In due course I shut down Firefox, and later re-opened. To be greeted by the message “Firefox is installing updates.” And that was all there was to it. No choice in the matter – bend over this won’t hurt a bit. Of course that meant that my plugins stopped working (what would I do without Firebug??) and since then Firefox has been crashing like Amtrak in winter. Thanks.

So naturally, the next time I was trying to open up a PDF in a browser and got the friendly error message to the effect of “error – The Adobe Acrobat/Reader that is running can not be used to view PDF files in a Web Browser. Please exit Adobe Acrobat/Reader and try again.” I LOOOOOSE it. I grabbed my computer in a figure 4 headlock, deaked it out with a headfake to the GPU and slammed an uppercut right up the USB.  “Is that ‘can not be used to view PDF files in a Web Browser’ enough for ya?” I gloated.

Solutions, Tom, not problems please. This is a constructive blog.

Right. So, after reassembling my GPU and rubbing some vaseline on my USB ports, I did some research. Many complains, some very bizarrre solutions (from Adobe) involving clearing out some registry keys, everything quite suspect. The most promising option was to open the Reader Software, go to Preferences > Internet and make sure “View in browser” was turned on. It was – so I turned it off, quit the app, relaunched, turned it on and tried again. Nothing. Not even re-loading the browser solved it.

So I uninstalled, and re-installed Acrobat 8. I found a very helpful Adobe Acrobat 8 standalone installer which has worked without a hitch. So until Adobe gets their act together (I’m completely flabbergasted that their Acrobat 9 for Windows is so crippled and hasn’t been fixed yet), do yourself the favour and do not upgrade. If you have, and are experiencing the same issues, do uninstall Acrobat 9 and then install Reader 8.

Happy surfing!

SELECT Tag Cuts Off Text in Firefox (2.0)

Dec 18

Posted by admin in CSS, HTML, Tips and Tricks, Web Development | No Comments

Well, I’ve been delinquent again with my regular posts here. Partially because I’m starting a new blog over at blog.zeitguys.com along with my other co-conspirators. But that’s no excuse.

Partially due to the encouragement of people who’ve stumbled upon some of my other tips and tricks, here’s a quickie that had me stumped for quite some time. I hope it’s of help.

The Issue:

When styling a SELECT tag using CSS and increasing the font size, in Explorer (7) the visual display area of the drop-down menu increases correspondingly. In Firefox, the form SELECT tag does not scale correctly – it cuts off some of the text. The larger the font size, the more the text gets cut off. This is the case regardless of whether you’re using pixels, points or ems. Line-height also has no bearing on it.

It turns out after some experimentation, and a completely random Google hit to some obscure Java CSS reference pages that gave me the idea, that in Firefox you also need to set the same font size in your OPTION tags.

So…

select, option {
	font-size:1.4em;
}

Will do the trick…

So remember, if you’re setting font-size in a SELECT tag, set the same font-size in your OPTIONs as well (unless you’re using a fixed width for the tag, in which case it doesn’t matter).