Scripts.Indisguise.Org - a hobbyist's blog and scripts archive

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.

From the start of my “awakening” to the knowledge of web standards, accessibility, and the like, I’ve been coding in XHTML. I started with XHTML 1.0 Transitional, and then as I got more into web standards, XHTML 1.0 Strict. I treat this issue of web standards, accessibility, and validity more and more importantly as time goes by. But the question is, is XHTML is correct choice, or was HTML the right document type definition I should have been using all along?

Gasp! I can hear it now. I’ve been an avid XHTML supporter for quite some time, making sure my scripts chug out valid XHTML markup. A lot of my online friends feel the same about XHTML. But I’ve been hearing more and more about the arguments for and against XHTML, that I’ve decided to sit down and really think about it.

Here are my reasons for choosing XHTML waaaay back when, and what makes these reasons invalid:

1. False: HTML is parsed as tag soup, but since XHTML should be valid when parsed, it should be parsed faster and better, not in “quirks mode”.

   Unfortunately, almost all usage today of XHTML is as HTML, and not as XML. This means that they are parsed as “tag soup”:

   “XHTML is an XML format; this means that strictly speaking it should be sent with an XML-related media type (application/xhtml+XML, application/xml, or text/xml). However XHTML 1.0 was carefully designed so that with care it would also work on legacy HTML user agents as well. If you follow some simple guidelines, you can get many XHTML 1.0 documents to work in legacy browsers. However, legacy browsers only understand the media type text/html, so you have to use that media type if you send XHTML 1.0 documents to them. But be well aware, sending XHTML documents to browsers as text/html means that those browsers see the documents as HTML documents, not XHTML documents.” XHTML Frequently Asked Questions

   If you want your XHTML to be parsed as XML (and take advantage of the marginally-faster parser… and when they say “marginally”, apparently it is “marginally”!), you have to send it as XML. Unfortunately IE doesn’t support that — you will get a document tree instead of your website layout, unless you give it extra instructions to do so. (See here.) And since IE is still the dominating browser around (yes, I know you’re annoyed), one just can’t ignore it.

   If XHTML is parsed the way it should be parsed (as XML), once your document is found to be not well-formed, the browser is supposed to choke and stop parsing. Period.

   “To minimize the occurrence of nasty surprises when parsing the document, XML user agents are told to not be flexible with error handling: if a user agent comes upon a problem in the XML document, it will simply give up trying to read it. Instead, the user will be presented with a simple parse error message instead of the webpage. This eliminates the compatibility issues with incorrectly-written markup and browser-specific error handling methods by requiring documents to be “well-formed”, while giving webpage authors immediate indication of the problem. This does, however, mean that a single minor issue like an unescaped ampersand (&) in a URL would cause the entire page to fail, and so most of today’s public web applications can’t safely be incorporated in a true XHTML page.” Beware of XHTML

2. False: HTML is so old-school, it’s getting deprecated.

   Apparently not. I’ve heard of HTML 5 for a while now, but only fully realized recently what this means. The W3C renewed the HTML working group, and apparently, web browsers have leaned more towards HTML5 than XHTML2.

   Even more shocking, XHTML2 is not backwards-compatible!

   “XHTML 1.x is not “future-compatible”. XHTML 2, currently in the drafting stages, is not backwards-compatible with XHTML 1.x. XHTML 2 will have lots of major changes to the way documents are written and structured, and even if you already have your site written in XHTML 1.1, a complete site rewrite will usually be necessary in order to convert it to proper XHTML 2. A simple XSL transformation will not be sufficient in most cases, because some semantics won’t translate properly.

   “HTML 4.01 is actually more future-compatible. An HTML 4.01 document written to modern support levels will be valid HTML 5, and HTML 5 is where the majority of attention is from browser developers and the W3C.”

   Beware of XHTML

These are the most important arguments, arguments that I can’t ignore as a web developer. Obviously, the Beware of XHTML document is a good read, gives both the myths and benefits of using XHTML. What’s even more important is that the way XHTML is used, it’s just like “the new HTML”, when it shouldn’t be that way. XHTML is XML, and should be treated as XML. The extension shouldn’t be .html. Browsers should “give up” when there’s an error, and not try to repair the document — after all, that’s what browsers do with ill-formed XML documents, right?

What doctype declaration do you use? And why?

So last night, armed with my nifty new font, I decided I’d get a move on with the next top-level version of Enthusiast. (Yes, I’ve started working on Enthusiast 4.0.)

(For those of you interested in it, it will probably be slow going, as whatever free time I have needs to be spent juggling between rest/recreation/social/family/other hobbies… and because I’m putting in a lot more effort in the backbone, and in usability.)

One thing I’ve always believed in is that you only get as good as what you actually do. That one might read a lot of tech blogs, a lot of white papers, a lot of those hifalutin framework blueprints… but if you don’t get down and dirty with code, you can’t expect to get better. It’s a given that the first few codes you churn out will be riddled with flaws. That’s normal, but that’s better than never getting over that simply because “I can’t fully understand OOP yet, I need to read more about it”. Ugh, get a grip, and get on with playing with code.

My first PHP project, way back when I was doing self-studying, was actually the precursor to Enthusiast. It was the script that handled my then-fanlisting, Bubblegum Crisis. After it was working, I moved on to the first “system” — an admin tool for handling my directory for NeoPets galleries. I actually put up that site, got a pretty nice following for it, and then when I weaned off NeoPets, I shut it down.

And then I started working on Enthusiast (the single-fanlisting version).

Without these first projects, I’d never have learned PHP. And this time, with PHP4’s End of Life looming in the distance, Enthusiast will be bringing me forward to PHP5. OOP, Exceptions, and many newfangled stuff in PHP isn’t new to me, but it’s been a while since I’ve actually handled PHP code continuously (almost eight months–the same time I’ve been with Yahoo! as a frontend engineer). I will be getting personal with a lot of these new things, in order to do what I need for it to do. And that’s quite exciting.

For anyone who’s thinking of learning PHP, the best way to learn really is by doing something you’re passionate about using PHP. I was passionate about NeoPets galleries; I was passionate about fanlistings. The passion drives you forward, and that’s a great thing to have.

I will probably be blogging here occasionally about new things I find out while working with PHP, or thoughts on development in general — what would you like to hear about?

I was quite delighted to find out recently (via AJ) that Apache and PHP was available by default on my Mac. Before I got my Mac, I thought that was the case, and then I couldn’t find it and supposed there was none and got living-e’s MAMP instead.

I quickly got annoyed, because just logging off and shutting down my computer after a bit of dev tweaking meant typing in my account password. Sometimes I ended up forgetting I had it running, and Logout would stop because MAMP needed something from me. It was quickly set up, but after a few weeks of getting it (and ending up too lazy to go through the whole startup-type-password-work-shut-down-type-password cycle…go figure) I was ready to brave whatever UNIX source compiling wizardly people go through to get their machines ready for web development.

After all, I’ve never resorted to using WampServer or XAMPP (etc) when I was still on Windows. I’d always preferred installing and configuring each one by one. This shouldn’t be hard, right?

And nope, it wasn’t! I’d initially envisioned needing to compile the source and all that scary stuff, but apparently (like I said) Apache and PHP was already built in, and MySQL had a Mac OS X binary. Yay! I spent an afternoon tweaking to my heart’s content, after finding gems like these:

• Enabling PHP in Mac OS X 10.5
• Working with PHP 5 in Mac OS X 10.5 (Leopard) (also has information on setting up PEAR)
• Apache, MySQL, and PHP on Leopard (Mac OS 10.5)

Here’s what I did.

1. Set up Apache’s configuration file.

   Open up Terminal, and type sudo vim /private/etc/apache2/httpd.conf. You’ll need to enter your password, since you’re running as root. Line 114 (or thereabouts) will be where Apache loads the PHP5 module. Remove the hash/pound sign (#) (type i to enter insert mode, and escape to get out of insert mode when you’re done) at the start of the line.

   

   Optional: You can keep going and customize your httpd.conf file to your liking. For me, I did the following:

   1. Change DocumentRoot to my Sites folder (two lines to change).
   2. Add index.php in DirectoryIndex to automatically load index.php files ahead of index.html when requesting a directory.

   Save the file (type :wq when in command mode).

2. Setup PHP’s PHP.ini

   Leopard doesn’t have a PHP.ini by default, but the default one is still there, named PHP.ini.default. Make a copy of this by moving to the /private/etc folder and copying that file:

   $ CD /private/etc
   $ sudo cp PHP.ini.default PHP.ini

   You might need to enter your password again. After that, you can edit PHP.ini (again, sudo vim PHP.ini…this is read-only, so remember to override vim’s warning when you’re saving and use :wq!) to change error reporting and other things you like to have PHP do when you’re developing.

   

   Note: The mysql and mysqli extensions are not enabled by default. You probably want to change that. (See lines 625 and 626.)

3. Run Apache!

   Now it’s time to test your web server and PHP together. Fire up System Preferences, and under the Internet & Network section, click on Sharing. Check the check box next to Web Sharing. Once it’s on, you can go to the URL there, or try the ever-trusty http://localhost, to test if your settings are as they are.

   Of course, if you feel like you want to do it the geeky way, you can always run sudo apachectl start.

   

4. Now let’s get MySQL up and running.

   MySQL isn’t included, so we’ll have to install that. Download a binary package and install MySQL, the StartupItem, and the preference pane. I haven’t actually gotten the preference pane to actually stop and start the MySQL daemon, but I figure it will work eventually, and it’s always nice to see it in System Preferences.

   Once they’re installed, hit sudo /usr/local/mysql/support-files/mysql.server start to start the daemon. You can try doing this via the preference pane (and let me know if it works). The preference pane also lets you toggle if you want the daemon to start automatically when you log in (which is the whole point of this exercise…but again, for some reason it doesn’t like me ;( sob).

   

5. MySQL socket problems in PHP

   As of the time of this writing, just installing MySQL and enabling the appropriate extensions in PHP.ini isn’t enough. PHP won’t be able to find the MySQL socket and won’t be able to talk to your database server. This post has a good explanation why, but to summarize the fix for this:

   1. Create a my.cnf file in /etc:

      $ CD /etc
      $ sudo vim my.cnf

   2. Type the following in the file:

      [client]
      socket = /var/mysql/mysql.sock
      
      [mysqld]
      socket = /var/mysql/mysql.sock

   3. Save the file and exit to the shell (:wq in command mode).
   4. Type the following commands for the sock file’s directory:

      $ sudo mkdir /var/mysql
      $ sudo chown _mysql /var/mysql

   PHP should be able to connect to MySQL now. A word of caution:

   One drawback to this is that if you have installed the MySQL GUI tools, they will look for the mysql.sock file at the old location. You can enter the new socket in the connection dialog under More Options, there is a box labeled “connect using socket.” Just enter /var/mysql/mysql.sock.

   Another solution is to change the PHP.ini file to expect the socket in a different location. I’m going with the my.cnf option because I expect the MySQL will have a Leopard version out in a few days that changes the default location.

   - from Professional PHP

That’s all there was! You should be up and running in no time. I ended up taking a bit longer because of the following (which might help you):

• My files all had wrong permissions. They were all just readable and writable by myself (the owner) and hence my web server couldn’t read them. A quick recursive CHMOD 755 * helped, although of course I’m wondering if there’s an easier way to get this all done. (Let me know?)
• I installed CocoaMySQL for my database management needs. It looks pretty spiffy. I’ll give it a whirl and if it isn’t enough, I might try out Navicat, although I’d rather not need to pay for a management tool.

Edited to add: I found out that the MySQL preference pane really wasn’t working, and that MySQL is aware of this issue. I found a patch for it via Natron Designs; and yes, now, it works!

A while back, maybe three years back and from the time I started using CSS, I used to do a couple of markup quirks (that incidentally made it easier to spot copycats, but that’s another story). I used CSS classes all over the place, like below:

<div class="content">
<div class="divTitle">Some title</div>
<div class="divSubTitle">Some sub heading</div>
<p>My content went here, in ordinary P tags.</p>
</div>

It worked for me. But starting from around two years back, I finally weaned myself off of using the semantically-blank DIV tags (where appropriate) and use proper HTML markup. My biggest reason for this is lesser code, and my page is “prettier” when the CSS is turned off. Observe:

<div id="content">
<h1>Some title</h1>
<h2>Some sub heading</h2>
<p>My content went here, in still ordinary P tags.</p>
</div>

In terms of style control, it was easily done via CSS anyway; and if I wanted a completely blank stylesheet anyway, a nice CSS reset will do that for me. (A word of note though: CSS reset does have its pros and cons. Personally I’m still a bit on the fence as to whether I’d go for using one that reset all the native styles or not, above the paddings and margins.)

An interesting post on heading tags, including a possible system/technique on using them, was posted by Matt Snider: When to Use Heading Tags. It’s a good, interesting read.