Sure, this isn’t the complete picture. Why isn’t early MPEG on here? What about player technologies, like Flash Player? Where’s YouTube? Honestly, I left those things off because they dilute the minuscule amount of humor I’m working with here… but, I’ll justify it this way: the story of video quality on the web is mostly about the advancement (and adoption) of compression algorithms — the underlying mathemagic that squeezes video down to something less than than mammoth-magnitude. (I’m not kidding about the magic: one second of uncompressed standard-definition video is about 30MB. Compressed with h.264, it’s about 63KB. That’s a reduction of about 500:1!)

The point is, walk before you run. Know that h.264 and MPEG4 are the compressors that pass for ‘good’ on the web right now, and you won’t be left behind with Australopithecus and the other IE6 users. Then note this: that last guy in the diagram still has a way to go…

… Well, sorta, anyway.

My second take is that I can’t decide whether this is a positive commentary on iPhone users (i.e. they know useless crap once they’ve seen it and never look back), or a somewhat less flattering one (they have an endless and apparently purposeless appetite for the latest gimicky digital froth).

I dunno. You guys tell me what you think.

Full disclosure: The device in my pocket was purchased when you still called them “cell phones” and they all had hinges in the middle, so this post might just be my pent-up gadget-envy lashing out at my luddite wallet.

Since I started writing AS3 code, I’ve generally viewed the mouseChildren and mouseEnabled properties of the InteractiveObject class (and by extension the Sprite class) as relatively superfluous. They existed as little more than a recourse for when something accidentally got ‘in between’ the mouse and a button that needed to be pressed. And in a sense that is true. But I realized today that those crafty AS3 creators had bestowed upon me a much more substantial tool than I’d first realized.

Fundamentally, these two properties are straightforward. Setting a Sprite’s mouseEnabled property to false tells that Sprite to not bother interacting with the mouse. In other words, to stop dispatching MouseEvents such as MouseEvent.CLICK. Likewise, setting a Sprite’s mouseChildren property to false tells the children of that Sprite to stop dispatching MouseEvents. By default, both properties are set to true.

The magic comes by virtue of the fact that these two properties work independently of each other. If a Sprite has children, setting that Sprite’s mouseEnabled to false does not prevent the Sprite’s children from dispatching MouseEvents. Similarly, setting the Sprite’s mouseChildren to false doesn’t prevent the sprite itself from dispatching MouseEvents. Why is this cool? Let me count the reasons:

• Sprite ‘flattening’. It used to drive me nuts that that a button made of multiple sub-elements (label, hilight, border, icon, etc) would have an indeterminate MouseEvent ‘originator’. That is, the target property of the MouseEvent would be ‘label’ or ‘highlight’ or whatever depending on the exact pixel over which the mouse rested, rather than simply ‘myButton’. I found myself putting invisible ‘mousetrap’ layers in my buttons to sit on top of everything to fix this. It turns out I don’t need to. By setting myButton.mouseChildren = false all the button parts become a single unit, collectively dispatching MouseEvents with a target of ‘myButton’.
• Group disabling. Need to disable a whole group of buttons? Make them siblings and set the parent Sprite’s mouseChildren to false.
• Event-bubbling simplification. By setting a container Sprite’s mouseEnabled = false but leaving mouseChildren = true, you prevent the ‘middleman’ from sending unnecessary MouseEvents to high-level MouseEvent handlers. Imagine a calculator, with multiple keys, a display screen, a surrounding ‘case’, a nice little Texas Instruments logo, whatever. If I add a MouseEvent.CLICK listener to the high-level calculator object, I will receive all of the various key clicks, but I will also receive events from the other child elements… the display, the case, the logo. Even if I set those elements to mouseEnabled = false, the calculator Sprite itself will still trigger its own MouseEvents when I roll over them. By following up with calculator.mouseEnabled = false, the high-level listener will now only receive events from the children that matter, and will not be encumbered with ‘false positives’.

Given this greater understanding, I almost wonder why the AS3 creators chose to set the default of mouseEnabled to true. After all… aren’t there generally far more ‘passive’ display objects on the stage than interactive ones? I’m sure they had a reason, and it’s probably one that I could find by Googling around a bit… but enough is enough. Hardcore geek session over.