Whimsical.nu

Welcome to a Whimsical Blog~

Hi, I'm Angela, a girl with a blog on five different psyches:
girl, geek, reader, writer, gamer
Choose your poison ♥

Resolution week: a geeky thing for 2011

Studying aheadI’ve realized only recently that everything I’m using right now to create websites and in my day-to-day work, I’ve learnt on my own, from scratch.

I learned HTML in 1998, by viewing source code and trying to replicate what I’ve seen. I built on that knowledge by making my own websites: about myself, about books and series that I loved, communities like the long-forgotten web rings and those cute little adoptable graphics. (Which brings me to another point: I learned to make graphics and some pixel art from those days, too.)

I learned CSS shortly after, as I made websites, starting from the shiny that is absolute positioning and continuing on to learn about fluid layouts, floating, the box model, etc. as I went along. My shrines and cutesy sites made way to personal journals and blogs.

I learned PHP on my own in 2002 or 2003, after I started liking Python for web apps but found it difficult to find an affordable web host with Python–PHP was much more available. I used it for small websites–directories, cliques, and making my own little script to manage fanlistings, which were becoming a big part of what I did online. (I wish I could say I learned SQL on my own, but not really–I took up database courses in college.)

JavaScript, ah JavaScript. I learned bits and pieces, but generally disliked it, until I needed to learn for work; I think a framework certainly makes it easier to wrap your head around, and while JavaScript won’t be in my list of top languages, I do find that I enjoy working with it nowadays–it’s an ongoing process, and I learn more and more as I continue to use it in what I build.

I think it speaks a lot of how learning for yourself, and using it as you learn, is one of the best ways to learn. And this year, I think it’s high time I learn something new again, and use it in something I build while I learn.

I haven’t decided what the new tool will be–a new framework? a new language?–nor the product, for that matter. But I do know that making time for pet projects opened me up to much more than just the enjoyment of creating and building for myself, that it’s something I want to do for myself this year.

So in 2011, I’ll learn and create something new.

0 Comments

Trying out HTML5 local storage

I decided I’d try out HTML5′s local storage after reading Christian Heilmann’s Smashing Magazine article on local storage. (Check it out, it’s worth it.) It’s always looked very intriguing, and the article reminded me to give it a whirl.

I’ve always wanted to have the slide-out tray menu on the left retain the visitor’s “setting”, but had no way of doing so reliably. One might say that using local storage is far from reliable, but it actually made sense: it would provide enhanced experience for those with newer browsers, but degrade with older browsers (read: just ignored). And I set off on making it work.

The end result is as you see it on the left, with the following piece of relevant code:

    var expanded = true;
    if( localStorage && localStorage.getItem('whimsical-tray') == 0 ) {
        expanded = false;
    }

    // some initializing of the animations and events

    if( !expanded ) {
        toggleCollapse();
    }

    Y.on( 'click', function(e){
        var storeVal = ( box.fx.get('reverse') ) ? 1 : 0;
        localStorage && localStorage.setItem( 'whimsical-tray', storeVal );
        toggleCollapse();
    }, '#nav-site-tab' );

Crazy simple, it’s almost too good to be true.

0 Comments

Playing with rotation animation in YUI3

I'm talking about: adding a custom animation type to YUI3, and IE's Matrix filter

A long time ago in a galaxy far, far away–well, actually, it was just during the Yahoo! Open Hack SEA held in Jakarta, Indonesia–one of the things I got caught up on was working with animations in YUI3–specifically adding a rotation animation. I was high on tea latte and from lack of sleep.

I’ve always meant to come back to it, make it work across browsers, package it up prettily sometime, but I’ve never been able to. This entry has been in the database ever since the hack day, actually. But never put up because I just couldn’t finish it.

But it feels like a waste to let the code (as hackish, and likely useless as it is) fade away, so I’m pushing on and publishing this post anyway.

Animating the element

I wanted to follow as closely as possible whatever convention was used in YUI3, and as such I wanted the code to animate go something like:

YUI().use( 'anim-rotate', function(Y){
    var rotateAnim = new Y.Anim({
        node     : '#rotate',
        from     : { 'rotate' : '0' },
        to     : { 'rotate' : '180' } // we turn #rotate upside down
    });
    rotateAnim.run();
});

The question was, how? It was actually pretty straightforward after I’d taken a look at some code. I needed to add a “rotate” behavior to Y.Anim. Y.Anim.behaviors contain functions that determine what styling changes happen on each “stage” of the animation via the set() function.

Firefox and Safari have -moz-transform and -webkit-transform and they work well, accepting numeric inputs which is pretty much what I needed in order to have Y.Anim calculate the steps needed.

However, Internet Explorer’s BasicImage just doesn’t play nice; it rotates only in 90-degree steps. *throws random stuff at IE* This article discusses an IE implementation that works in increments, but when I tried porting over to the script, it ended up doing rather odd (funny!) things. You can observe the funny sample here, and see for yourself.

I spent two nights trying to figure out exactly why IE was doing this weird flipping out thing: the math was correct if I used a calculator. Rotating the image manually in increments using DXImageTransform.Microsoft.Matrix was working without any of the weird flipping.

Finally, I tried looking at the exact values that were coming out of Math.cos() and Math.sin(). It was usually correct–until the animation gets to 90degrees, 180 degrees, etc.

The culprit

Math.cos() and Math.sin() accepts values in radians, not degrees. So I needed to convert them (degree * Math.PI/180) and then perform the appropriate function. And Math.cos(90*Math.PI/180) is not 0, but rather, 6.123233995736766e-17.

And no, there is no way to round it up to a more moderate value. Math.round() rounds to the nearest integer, not some-decimal-place-I-want.

Yep, boys and girls, they are splitting hairs somewhere.

So apparently, it wasn’t an IE issue. This value came up in all the browsers I tested. IE’s “mistake” was in not giving us rotate() like the other browsers, but I suppose they have better things to do in their time than make things rotate (which is likely for the best…).

In any case, here’s the code I used. Maybe some IE developer will see this and make things work somehow ;)

A quick disclaimer: it’s a hack, and not even cross-browser.

YUI.add( 'anim-rotate', function (Y) {
    Y.Anim.behaviors.rotate = {

        // this function changes the style of the node/element
        set: function(anim, att, from, to, elapsed, duration, fn) {

            // get the actual degrees to rotate the element
            var v = fn(elapsed, Number(from),  Number(to) - Number(from), duration);

            // now set the styling
            anim._node.setStyle( 'transform', 'rotate(' + v + 'deg)' );
            anim._node.setStyle( 'webkitTransform', 'rotate(' + v + 'deg)' );
            anim._node.setStyle( 'MozTransform', 'rotate(' + v + 'deg)' ); // FF 3.1+ only :(

            // IE stuff; doesn't work as intended :P
            var deg2radians = Math.PI / 180;
            var rad = v * deg2radians ;
            var costheta = Math.cos(rad);
            var sintheta = Math.sin(rad);

            var m11 = costheta;
            var m12 = -sintheta;
            var m21 = sintheta;
            var m22 = costheta;

            var str = "progid:DXImageTransform.Microsoft.Matrix(sizingMethod='auto expand' M11="+m11+" M12="+m12+" M21="+m21+" M22="+m22+")";
            anim._node.setStyle( 'filter', str );
        }
    };
}, '0.0.1', { requires: ['anim'] });

Again, I have the full code I used up here, if you wanted to check out the oddness of IE as well ;)

0 Comments

Implementation focus: quick spoiler hiding

I'm talking about: W.nu's hide spoiler JavaScript

I’d like to share a very nifty, quick-to-whip-up piece of code I use for the book reviews I will be doing from here on out, in my Reader category: a short JavaScript snippet to hide spoilers (you can see it in action in my Mockingjay review). You see, I suck at making book reviews: I always inevitably talk about things that is best left to be discovered by a reader. So to help myself and anyone who might chance upon my reviews, a spoiler protection feature for my blog sounds just about right.

Why I didn’t go with the “More” tag route

WordPress has a feature that lets you force users to click through to the post’s dedicated page: essentially, hiding anything under the “More” tag when viewing in the blog index/posts list.

Insert More tag WP button

This works as a quick solution: but this didn’t really feel very “bright” to me. That’s an extra click and page load, and it means that I can’t have multiple spoilery sections in a single post. I don’t exactly know why I will need multiple separate spoilery sections, but far be it from me to set limitations on my writing style!

My solution

I went and used JavaScript to hide spoilers in the page. I did so for a couple reasons:

  1. Users won’t need to wait before seeing the hidden content: one click to surface it, and it’s there already.
  2. There is minimal break in the experience and tone of the entry.
  3. I could have as many spoilery sections in my entry, but the entry will still read as expected: you could just skip the spoilery sections easily.
  4. Users get the same experience whether they’re reading the entry on its own page or on the blog index page: spoilers will still be marked.
  5. Presentational text (show/hide spoilers) is not included in the content of the post.

The implementation

My library of choice is YUI3, but the same should also be relatively easy to do in other libraries, or even just plain JavaScript.

The script basically retrieves any and all tags with a class name of “spoiler” and hides everything inside that by lowering the opacity to 10%. This way, the user has a tantalizing, indistinct view of just how much they’re missing out by not reading the book/watching the movie! ;)

The script also adds its own text to the entry via JavaScript, saying that there are spoilers ahead and they can click on the text to toggle visibility. It’s not an actual link, but I wanted to style it slightly like a link–but you really have full freedom as to how you’d like the spoiler toggle warning to look like.

(As always, the best place to put the code below would be at the end of your page.)

<script type="text/javascript" src="http://yui.yahooapis.com/3.2.0/build/yui/yui-min.js"></script>
<script language="javascript">
YUI().use( "anim", function(Y){
    Y.all('.spoiler').each(function(o, i){
        var id = 'spoiler-' + i;
        var spoilerToggle = '<div id="spoiler-toggle-'+i+'" class="spoiler-toggle">Warning! Spoilers ahead! Click here to toggle spoiler visibility.</div>';
        Y.on( 'click', function(e){
            var opacityValue = ( o.getStyle('opacity') >= 0.9 ) ? 0.1 : 1;
            var anim = new Y.Anim({
                node: o,
                duration: 0.25,
                to : { opacity: opacityValue }
            });
            anim.run();
        }, '#spoiler-toggle-'+i );
        o.insert( spoilerToggle, o );
        o.setStyle('margin','20px').setStyle('opacity','0.1').setStyle('padding','10px');
    });
});
</script>

Without any HTML tags with the class “spoiler”, the script will not run unnecessarily, so you’re pretty free to use it for any page or post type.

To add styles specific to the spoiler toggle, you can use:

.spoiler-toggle { /* style for whole warning */ }
.spoiler-toggle span { /* style for toggle "link" */ }

Customizing the code

You can use the above code for almost any other similar purpose. You can change the element it hides by changing “.spoiler” at this line:

Y.all('.spoiler').each(function(o, i){

making sure that what you put in is a valid CSS selector (i.e., #some-id .some-class element or similar). It will then apply fading in/out to the whole element.

You can also well as change the wording of your toggle, or completely change it out to a different element (an image, or what-have-you) by changing the HTML at:

var spoilerToggle = '<div id="spoiler-toggle-'+i+'" class="spoiler-toggle">Warning! Spoilers ahead! Click here to toggle spoiler visibility.</div>';

making sure that you leave the outermost div with its ID intact.

Hope it’s useful, or helps you think of other ways to improve your site. Website improvement never needs to be a full-blown affair: a couple low-hanging fruit, small details here and there, makes the work worthwhile. ♥

0 Comments

Frontend Friday: Too much AJAX

Alex asked in last week’s Frontend Friday:

I just wanted to know how you decide how much AJAX is too much AJAX? You don’t seem to use much (if any) on this website.

It’s a good question, but the answer isn’t too straightforward: it will always depend on a large number of factors. For me, an indication of a developer/team getting too AJAX-happy would be when the site becomes unusable when JavaScript is turned off or isn’t working. For example,

  1. a website that loads all (or most) of its content via AJAX, therefore rendering the page content-less without JavaScript; or
  2. a website whose navigation is inaccessible without JavaScript.

JavaScript should enhance websites and applications, no doubt about that. Most, if not all, of the well-loved web apps of today are due to the snazzy-ness of AJAX. But we can’t always rely on JavaScript being present: even if users have it turned on, spotty connections and unexpected data returns can result in JavaScript being pretty much nonexistent. Progressive enhancement and/or graceful degradation should be important when working with JavaScript–whether or not you’re doing asynchronous calls or not.

However, like I said, the answer isn’t straightforward. Some applications really do rely on the existence of JavaScript, and for good reasons. Graceful degradation can be prohibitively difficult when you’re dealing with some specialized web applications, like mail: Yahoo! Mail and GMail come to mind. User interactions with both of these are so fine-tuned and uses a lot of convoluted interlocking parts, and degrading gracefully would be a pain. That’s why both apps have a no-JavaScript version as well (Mail Classic and Basic HTML view, respectively).

As for the second part of the question–no, Indiscripts doesn’t use any AJAX :) Mostly because I don’t see a need for it, or the “need” to use AJAX is lower than the time I have budgeted for designing and coding up my tech blog ;)

0 Comments

Frontend Friday: Tools of the trade

I’m finally pushing through with an idea I’ve had for a while: Frontend Friday! Every Friday, I will be posting an entry about frontend development work, which includes topics on HTML, CSS, JavaScript, and basically anything related to the implementation of designs and UI on the web. These may be simple solutions you might know about, or weird experiments and topics that concern those who code layouts, whether done as a hobby or as part of work.

For the first Frontend Friday post, I’ve decided to write about a topic that’s rather central for all web developers: the tools that we use. We all use different programs and extensions and scripts to help us code up a nice layout for our websites. I wanted to share some of mine, and I hope you find them useful.

My top 7 tools:

  1. Aptana Studio

    I’ve been using Aptana well over a year now, and in fact I wrote a review about the web IDE before. Because it stems from Eclipse, and Java, it suffers a bit of lag especially when working with large files; I wouldn’t recommend using it for that quick 30-second style fix on your website.

    But working on websites that contains quite a few bells and whistles, I find Aptana to be quite helpful. The Project pane stores all ongoing projects, the Validation tab is quick to look up typos which result in syntax errors, the Outline pane makes jumping between functions and HTML nodes a breeze, and Code Suggest is always great to have around. (You should take a look at my review if you want to know more; while that was for the beta version, it’s still relevant.)

  2. Firefox

    Yes, Firefox just had to be there. I will admit that as of late I’d been very frustrated with Firefox’s memory-hogging practices and annoying lag, and if it weren’t for Firefox being insanely great for web development, I might have dropped it for the faster Safari. Firefox is a great standards-compliant browser, plus it provides an avenue for a plethora of web-developer-friendly tools, some of which are…

  3. Web Developer Toolbar

    Chris Pederick’s Web Developer Toolbar is impossible to live without. It’s lightweight and contains a lot of helpful tools: disabling cache to make sure you see your CSS updates, cookie manipulation, CSS lookups, markup and style tools for debugging, browser resizer, viewing generated source (for all those whizzy JS things), and more. If you’re a developer and you don’t have this on Firefox yet… what cave have you been living in?!

  4. Firebug

    Actually, Firebug vied with the Web Developer Toolbar for the “must have” spot, with the toolbar winning simply because it’s lighter and more mainstream: even if you’re a hobbyist making personal websites during your free time, the toolbar is useful. Firebug is also a must-have, but mainly for more heavy duty stuff, and especially for debugging purposes: completely clueless what styles are messing things up on a certain element? Lost as to what is happening to your variables when running JS? Firebug makes digging into code easy. I can’t count the number of times Firebug has saved me hours of trawling through CSS or numerous alert() calls.

  5. Multiple Internet Explorer installations

    There are numerous multiple IE tools out there, but the one I personally use on my Windows test machine is TredoSoft’s Multiple IE. I really only test for IE6 and IE7, though (I should install IE8 soon, too…). It’s a bit of a pain, but that’s the way life rolls. The IE Developer Toolbar is also a must-have for IE-proofing your website. I hope they update the toolbar to include a debugger soon.

    Naturally, you will also need other browsers installed, according to what you wish to test with. I test according to Yahoo!’s list of A-grade browsers, even for my personal work (well, in varying degrees, as I don’t have multiple images of Windows sitting in my personal machine, for instance).

  6. YSlow

    YSlow analyzes my pages’ load times. I typically only use this nearer to the end of development, to check if I need to combine more images into sprites, chunk together CSS and JS, etc. It’s definitely a good guideline checker for webdev best practices, which may or may not be critical for you, depending on what you are working on.

    YSlow takes into consideration Yahoo!’s rules for high performance websites, which every web geek into making websites should read through at least once.

  7. Fiddler and/or Tamper Data

    These two are mostly useful for deeper digging into the communication between your website and the server, and may or may not be applicable for the type of work you do. I find it highly useful for verifying form submissions’ raw data and AJAX requests — you can stop the data transmission, fudge up the content, and release it, which helps you trap bugs and issues.

    Tamper Data is a nifty Firefox extension for this purpose, and Fiddler is an HTTP debugger tool, much more robust than Tamper Data. Unfortunately, Fiddler is not available on Mac OSX — I’ve been looking for a good alternative for a while now (Paros looks like an interesting alternative, but for some reason I can’t get it to start monitoring traffic).

So those are the top 7 tools I use for working with code. What are yours?

4 Comments

Badass JavaScript

I came across this one today: JavaScript in StarGate. Man, it’s fun to see code you know on TV, but I love the comments on that post the best:

“The aliens are trying to open a new browser window a synchronize it with our screen size…..bloody bastards!!” –OndraM

“Wow, and we thought XSS Injection was a security vulnerability. In the future, h4ckers actually inject evil robot bugs into your lair via XSS.” –tj111

;)

Makes me want to seriously watch this show now.

3 Comments