This is hilarious. I can't help but wonder who negotiated this deal. Someone had pictures of somebody doing something they shouldn't. That's the only logical explanation. :)
This blog entry contains spoilers regarding the movie. Don't read any further if you don't want your enjoyment of the movie spoiled.
Well, here is my belated blog regarding The Matrix Reloaded. First of all, I don't get what all the fuss was about regarding the quality of this movie. I thought it was awesome. Sure, the Burly Brawl went on a bit too long and you could tell Neo was fake in places, but it was still a brilliant idea. I actually thought the much-maligned Zion rave scene was just fine.
The freeway chase was 14 minutes of the most mind-blowing action I've ever seen on film. It was just frickin' awesome, and the shot of the two trucks crumpling was just plain cool.
I think people who are complaining about the story itself should withhold judgment until the third movie has been released. I firmly believe that the true nature of the story is only going to really become clear once we've all seen the last film.
On to my beliefs regarding what the heck is going on... I am certainly not the first to present these ideas, so if you've been reading other Web sites you may have heard this stuff before, but I've gathered together bits and pieces of various theories to string together a consistent idea that makes sense to me at least.
To quote Trinity, "Let me tell you what I believe." It's probably all totally wrong, and I'm going to be horribly embarrassed when the third movie comes out, but here it goes anyway.
(1) I believe that the world containing Zion is also the Matrix. The Matrix world is actually a Matrix within a Matrix. It's all the Matrix. Whereever you go, there you are, and all that. :)
(2) I believe that what the Architect said is essentially correct. In order for the Matrix to function smoothly, dissident elements, i.e., those elements who do not accept the "reality" in which they are imprisoned must be controlled in some way in order to prevent the system from failing.
(3) Zion itself, therefore, is a control system. The system is designed to keep the segment of the population that cannot accept the programmed reality of the inner Matrix from bringing down the whole system. Zion is a deliberate ruse designed to keep the dissidents that could potentially learn to reject the system from rejecting the system.
(4) Neo was able to zap the Sentinels at the end of the movie because of the choice he made to save Trinity. By rejecting the Zion control system when offered the choice by the Architect, Neo is finally truly questioning the reality of the Matrix. He is the first person to do so. He is now on the path to becoming The One in the outer Matrix as well.
(5) Agent Smith is able to infect someone in "the real world", because it isn't the real world at all. It's all still the Matrix. He just moved from Level 2 to Level 1 as it were.
The knot I'm still trying to unravel is why the Architect offers Neo a choice. Why does he have to give Neo that choice?
Yikes, I seem to have violated my blog division rules and have been letting Web-related blog entries creep into my personal blog. Those are all supposed to stay over in the techie blog. I will try to do better at this in the future. :)
All this blog is supposed to contain is me talking about random television shows I watched, how good the meal I ate last night was, or what's wrong with me that makes me like Dawson's Creek.
Angel got renewed, and James Marsters is joining the cast next season! Woo hoo!
Erik Barzeski has done a redesign of his blog. I'm pointing it out because I think the fadeout effect at the top of the page is so cool. I'm assuming it's a fixed positioned block with a transparent PNG background?
Tantek writes in his blog:
After being beaten to a pulp by all manner of theoretical academicians, professionally inexperienced markup geeks and XML fascists (I don't need to link you, you know who you are), the voice of the professional and pragmatic web community and companies at large has won out (for now), and the style attribute is back.
Psst, Hixie. I think he's talking about you! Pass it on!
After struggling over Hixie's deliberately-malformed CSS on libpr0n.com, I'm not feeling terribly charitable. ;)
After my complaint about how ugly my blogs looked, I received a bunch of unsolicited designs (as well as offers to design). I was originally going to design my own new look, but I liked Stephane Curzi's awesome design so much that I decided to use it.
I found this thread on jwz's blog extremely interesting. The gist of it is that Jamie Zawinski tried to do something really simple with CSS and ran into all sorts of problems. I was also really amused by the fact that font tags don't apply to CSS point sizes. That's just hilarious that you can specify a size of -1 and get a bigger font.
I've also been following Dave Winer's comments on the subject of CSS vs. HTML. Dave has drawn the ire of numerous CSS geeks, and as far as I can tell, all he did was point out that CSS is harder to use because, well... it's complicated and exposes far more bugs in modern browsers than simpler alternatives like font tags and tables.
So here's the thing: while I love CSS and prefer designing my pages using CSS, I completely agree with Dave and Jamie. In many ways, I think the old-school way of building Web pages is actually simpler to understand. Mastering CSS is like making the leap from procedural to functional programming. It's like forcing a guy who has only coded in C his whole life to suddenly write programs using Standard ML. Sure, it's cool, but it's a heck of a lot harder to understand.
So you have this language that leads to much simpler markup but that is much harder to understand. Now add to this complexity by throwing in a pile of buggy browsers. In addition to trying to understand how CSS is supposed to work, you have the added burden of not being sure which browser is even rendering your page correctly anyway. Then you have to figure out some way of working around all of the bugs in the various browsers.
It's also trivially easy to run into ambiguous areas of the CSS specification that still haven't even been cleared up. There's no real agreement what constitutes overflow for example, or how z-index is even supposed to work. Where floats should position themselves is not 100% clear.
So, buggy, yes. Really complex, yes. Moreover, there are layouts that CSS in its current form simply cannot do. Of course, if you think about it, the fact that people want to keep adding to the layout capabilities of CSS is a testament to the success of CSS.
Back when we were first developing XUL, the goal was to use CSS2 layout primitives and properties to lay out the UI. For example, we tried to use CSS2 to lay out the Navigator window.
The Navigator window is an extemely simple layout. You have objects vertically stacked in a window: a menubar, two toolbars, a flexible content area, and a status bar.
This is the kicker: nothing in CSS2, and (I believe) nothing that is even in any CSS3 drafts enables you to achieve this completely simplistic vertical layout. Tables can't do it. Fixed positioning can't do it. All of these weapons in the CSS arsenal, and none of them are up to the task of simple vertical layout.
The problem is that you don't want to have to specify the height of the toolbars, status bar, or menu bar explicitly, because you don't know that height up front. All of the CSS vertical layout mechanisms (e.g., fixed positioning) depend on having this knowledge. There's no way (not even using tables) to mingle flexible and inflexible objects in a vertical layout while having the inflexible objects size intrinsically.
Another huge problem with CSS and HTML: why can't you make popups? People make these ridiculous 70-100K JS files just to do basic popups, and even then, the popup menus suffer from horrible usability. For example, a basic menu should allow you to move diagonally into submenus without dismissing the menu. Unless you try to write some insanely complex JS, you won't get this behavior in DHTML menus.
Web geeks like to write huge articles about how they took crappy building blocks and made something cool and clever, but so frickin' what? Points to you, buddy, you managed to mold some crappy clay into the shape of Michelangelo's David, but it's still just crappy clay.
The simple truth that is obvious to anyone coming at this with no prior experience is that there are fundamental building blocks that are completely missing from CSS and HTML.
How many years have we had HTML, and there still isn't a simple multi-column tree widget? Popups, trees, vertical layout control: these are all obviously needed on the Web, but they're nowhere to be found. We had to invent all of this for XUL, and that ultimately is what led to XUL being a completely new language built on new CSS layout primitives.
Hopefully these primitives will one day find their way into the CSS standard.
Which brings me to the main point of this blog entry. All of this massive work on CSS/XHTML/etc. is nothing more than a process of refinement. It's nothing revolutionary or new. The innovation already happened. We've got the 2-dimensional page-like layout with links and images, and even when we have 9000 CSS3 properties, and 4500 variants of XHTML all with their own tag sets that mean more or less the same thing, we're still just going to have a 2-dimensional page-like layout with links and images.
People spend hours arguing about how much better their site is now that it's "semantically clean" and 20K instead of 100K, but I can't help but wonder if, in 5-10 years, when bandwidth constraints have eased dramatically, there won't be some richer form of display available that will just render all the current CSS layout primitives obsolete, if all of this tinkering and polishing of HTML and CSS won't amount to a hill of beans once the "next big thing" comes along to sweep it aside.
In the mean time, I'll keep tinkering and polishing. :)
Two cute examples of abuses of the English language in everybody's favorite layout engines (KHTML and Gecko).
The first is from KHTML. When an object in HTML (e.g., a <p> tag) has had its dimensions determined and has been placed somewhere, the method that is invoked to indicate that the layout is complete is setLayouted. To ask if an object needs a layout or not, you call layouted.
The term layouted is so insidiously catchy that it actually crept into my vocabulary.
"I don't get why this isn't laying out right!"
"Well, try stepping through the code!"
"Oh look, it's already been layouted! I guess it doesn't need to be layouted again."
ARGH! :)
The second is from Gecko and is my favorite. The act of laying out objects in Gecko is called reflow. However, when you flow an object for the first time, it's called the initial reflow. That's my favorite.
"Yes, that's right, I'm flowing it again for the very first time!" Uhh, say what?
Oh well, it could have been worse. At least I haven't seen too many abuses of it's vs. its in either engine lately. ;)
You know, I really wish I had some skill at graphic design. I'd love to make my Safari blog and this blog really pretty, but I just don't have any artistic talent whatsoever. You'd think, being a "Mac person" now, I'd have made friends with some talented designers who could whip me up a beautiful Web site, but no. I am doomed to have ugly blogs for all eternity I think. :)
... Ruben in the bottom two?! I mean, what the hell? Now I'm actually going to have to start voting on American Idol in a vain attempt to counter the millions of half-wits who must be watching along with me. Hey... wait a minute... if only half-wits watch this show... and I watch this show... err... never mind.