Since my job is mainly PHP and MySQL development, I don’t do a lot of theming. I actually like coding CSS, but we have a design team for that. For this blog, it’s actually something I need to think about. I’ve done a lot of CSS coding, but recent events at work have left me frustrated with legacy code, thus sparking this post. So getting to the point: CSS is not an art. Cross-browser CSS is not something one intuitively picks up and starts playing with, it is a language, and to be successful at it you need to know what you are doing.

The key concept is the possibility of writing unsuccessful or bad CSS. The art is drawing up what the page is to look like—concept art, or as some call it “mocking up” a page. CSS is the tool used to get the page to actually look and function as intended, and in every browser. I believe a lot of amateur web developers do not realize the importance of understanding both the CSS specifications themselves and how each CSS command will affect each web browser.

To further my point, this week I’ve been working with more legacy code which has CSS sprinkled all over, and always as an afterthought. This itself is not necessarily bad, as sometimes the importance of getting something semi-functional (or to a state where your boss stops yelling at you) necessitates ignoring certain parts of the process. In this, Internet Explorer 7 was forgotten about and somehow hovering over a certain set of <span> tags makes large parts of the page shift a few pixels back and forth. In an extreme case, it would hinder someone from using the application and potentially cost the company money—again an unacceptable outcome.

Having been dealing with CSS for a number of years now, I feel like I’ve learned quite a bit about how each browser treats different CSS attributes, but new web technology is embraced at a quick pace, and I still find new awkward Internet Explorer rendering engine bugs on a consistent basis. But at the least, having an understanding of what CSS was built to do goes a long way.

Those three little words are very powerful, and are fundamental constructs of programming languages. I don’t know what I would do if I couldn’t iterate over an array. I also don’t know what to do with myself when I forget how each is used in the current language I’m writting in.

For example: If I’m writting in PHP, it’s foreach ($array as $val => $key), in Python it’s for $i in range(10):, in Perl for and foreach are actually the same thing and can be used interchangably (I did a bunch of Perl stuff while at my last job), and I’m pretty sure JavaScript doesn’t have an object iterator construct—probably because JavaScript implements objects in the most terrible way.

What about whiles? They are just strange. I never know when I can use do or when the truth statement is processed. Plus, sometimes the thought of an infinite loop scares me a little. Of course in Perl 6, you can form a lazy infinite loop out of a for statement.

After assessing my options, I’ve concluded Python is the language I need to master. On top of fulfilling all my requirements, Google uses it, and if it’s good enough for Google to use for applications that millions of people rely on every day, then it’s good enough for me. Besides that, it makes a great calculator in Windows.

I’ve looked at Python before, and it didn’t look too amazing. But now that I live in a different world and have a new perspective, Python is awesome. Some people frown on the forced indentation, lack of end-line symbols, and non-dollar-sign-prepended variables. After writing a few “hello world” programs, I believe these are not failures but perks. If you are among a team of people writing a massive application, these qualities might keep you on this side of sanity. However, the “batteries-included” philosophy of Python and its hyper-extendability really push it over the top.