Archive for category HTML

Reclaiming the

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 »

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

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 »

SELECT Tag Cuts Off Text in Firefox (2.0)

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).