DOWNLOAD: New Symphonic Movement I (free download for PERSONAL USE ONLY)

It remains unnamed at the moment, though its working title is “Humble Beginnings” simply because it arose from a single, late-night improvisation of a very unique and texture-rich instrument from the German company Native Instruments called ‘Massive‘. Add a little Orchestral percussion and you have something interesting.

Once I started to get into it, I decided to highlight some of the hidden textures and emergent melodies within the texture using standard orchestral instrumentation – cellos, violins, oboe and clarinet, a little french horn. All of this courtesy of Edirol’s Orchestral plug-in. Finally, the Steinberg Grand Piano (de rigueur, and frankly a little overdone in this version – I will be cutting it back with great prejudice: it’s sounding a lot like my old stuff and the ‘Auger Sound’ is getting on my nerves), and a really cool violin sample using my wife’s cheapo Chinese-made violin for an oriental violin solo melody near the end. I call this instrument the “Shing Jea” violin, after Jeremy Soule’s Guild Wars Factions soundtrack (click here for a little sample on YouTube).

Anyway, here’s the first, unmastered cut. Because of the intense dynamics, you have to be careful of your speakers – I will be running it through a compresser and equalizer and other things to get a better loudness ratio before it’s finalized.

Enjoy.

DF Forge

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.

One Solution: Hidden <span>

The first thing that comes to mind is: use JavaScript to intercept any form submissions coming from <button> tags and make sure we’re using the “value” attribute. But all my RIAs are use unobtrusive JavaScript – the first (and most important) principle of which is: “must degrade nicely”, which translates as: “must works without JavaScript”. JavaScript is decoration and icing, not the food. So we still need a server-side solution that does not rely on some sneaky last-minute JS bait-and-switch.

A solution that I have found helpful (and since discovered similar minds thinking as well) is to add some additional info to be sent in the innerHTML for IE only. On the server-side, if we receive this additional info, we parse it and use that value.

<button type=”submit” name=”ac” value=”showMail”>Cancel<span class=”ievalue”>showMail</span></button>

In this example, I want the user to see “Cancel”, but the action actually sent to the server is “showMail”. Most browsers handle this properly by just sending the value parameter. IE 7 sends the innerHTML.

On the server side I do the following:

1) did we get a <span class=”ievalue”>? (well actually, did we get a <SPAN class=ievalue>?)

2) grab the inner content of that <span>, ignoring anything else

To make this solution a little more workable, I’ve decided to make this <span class=”ievalue”> optional, in the case where your button text is the same (more or less) as the value text. For example:

<button type=”submit” name=”ac” value=”sendMail”>Send Mail</button>

Here we just need to concatenate the innerHTML, and convert to camelCase.

Putting it all together (the language in this example is Perl):

# assume that the user input is read in using CGI and put into a hash called %params
# (so $params{ac} would contain the value/innerHTML of the button named "ac")

# if the <button> input parameter is used to transmit the "ac" parameter,
# IN INTERNET EXPLORER, it sends the innerHTML of the button,
# which could contain HTML and all sorts of other garbage.
# in direct violation of HTML 4.0 standards. So what we do is
# for all other browsers we use the proper "value" attribute on the button;
# for IE < 8 we add a <span> that will contain an exact duplicate
# of the "value" attribute.

 my ($ie_ac) = $params{ac} =~ /<span\s+class\s*=\s*"?ievalue"?\s*>([^<]+)/i;
 if ($ie_ac){
 $params{ac} = $ie_ac;
 } else {
 # just in case we're still coming in from IE, but have decided
 # not to include an "ievalue" span (because the text is the same as the value)...
 # strip out HTML and convert to camel-case
 $params{ac} =~ s/<[^>]+>//g; # strip out HTML
 $params{ac} =~ s/[^a-zA-Z_ ]+//g; # strip out any non-words
 $params{ac} = lc $params{ac}; # set everything to lowercase
 $params{ac} =~ s/\s+(\w)/\U\1/g; # strip out whitespace and set the next letter to Upper Case
 }

This solution seems to work fairly well. The CSS to hide any <span class=”ievalue”> is trivial.

I hope this approach helps you in the server-side language of your choice.