Standards, and open-source v. closed-source

Recently, some people have made known to me their objection to the involvement of developers of propriety software, such as Microsoft, in the development and evolution of web standards. They see the actions of such companies as inherently detrimental to the promotion of open standards, and would rather see such development solely led by open-source communities.

There are two models of software development identified here – the proprietary model, where developers write code as intellectual property (IP) and license that IP to their customers, and the open-source one, where the code is kept in the public domain and contributed to by many people, and is freely available. Many more traditional companies have adopted the former model, while many newer entities have determined that open source is a better path for them. However, I do not see how this distinction limits the ability for either group to create and promote standards.


What is a "web designer"?

The field of website creation is a vast one, with many different skills needed to complete a single site, ranging from creative design, to imperative programming, to natural language content creation. With so many different skills needed, it is often hard to figure out what one should learn when trying to apply themselves to a certain role, for example that of a web designer.

Web designing is perhaps the broadest term that can be applied to such a person. It may cover both the creative design and technical sides, and indeed the entire process, of creating a website, from start to finish. But what does one actually need to know? It is necessary to be able to write HTML, or even code JavaScript, or does one only need to be a graphic designer? And in my opinion the answer is, well, it varies.

I do know of a few designers who are completely hopeless at any form of coding, and rely on developers or PSD to HTML services to convert their designs into reality. Of course, it helps a lot (if you are a web designer) to know the fundamentals of front-end development, but it really depends on the role you are taking – for example working as a designer in a large agency who may do web work versus working as a freelancer. Also, I really wouldn’t expect a web designer to know JavaScript beyond the very basics. That is very much in the realm of front-end development. But the more skills the better – if you are both a Cinema 4D geek and a JavaScript “ninja”, then good work! But it is very hard to focus on everything, and if you can produce brilliant designs but don’t know the difference between divisions and spans, I wouldn’t hold it against you.

In the end, every organisation has their own requirements, and each one may define the position “web designer” differently. There is no “one true” skill-set that such a person needs to know – one can focus on having a wide range of competencies, or focus on perfecting one skill, and each will open up different opportunities. So just study what you wish, and there is sure to be a place for you, somewhere.

The web development tools I use

There are a wide variety of web development applications available, from simple plain text editors, like Notepad, to all-in-one IDEs like Dreamweaver and Coda. Everyone has their own needs and preferences, but these are the tools I find myself using most of the time.

Editor – PSPad

A great text editor, lightweight, but still very capable. In particular, it has the ability to “multi-highlight” documents – that is, recognise areas of different languages within a single document, such as HTML and PHP, and highlight each area accordingly. The applications also has integrated project management and file transfer utilities, and a great set of plug-ins. The file browser could do with a bit of work, though.

FTP – FileZilla

Another very lightweight application. Simple to use, but it has all the features you would need for everyday FTP access. It also has solid secure FTP (SFTP) support, which everyone should be using.


Probably the only good graphical telnet and SSH client for Windows. Almost everything that you could need or want to do over SSH can be done from the PuTTY interface – it can handle port forwarding, proxies, numerous different encryption schemes, and even emulate different types of terminals. And, if you need even more than what PuTTY has to offer by itself, there are many, many forks available that add numerous new features.

Browser – Chrome (primary)

While of course websites should be tested in all user agents that your target audience may use (which, in some extreme cases, may be only IE6), I find that I tend to use Chrome more than any other as my primary browser. It’s fast and simple, and the Webkit Inspector (developer tools) is powerful enough to rival Firebug. Best of all, it has an extensive amount of extensions.

Of course, there are many other applications that I use for specific purposes, like TortoiseSVN for Subversion access, and grepWin for batch search-and-replace, but most of my time is spent in the above four programs.

What web development tools do you find yourself using?


HTML and XHTML are two markup languages used for describing web pages. They are based on two difference markup standards, the former the older SGML specification, while XHTML is based on XML. When writing up web pages, we (basically) have a choice between these languages – so which one?

On the surface, the languages are much the same, however there are many differences between the two languages, not just in terms is syntax, but also in terms of capacities. For example, XML allows the definition of namespaces, which allow multiple types, or “flavours”, of XML to exist within the one document, for instance not just XHTML but also SGML, etc. XML also has the xml: namespace, for semantic purposes. However, the vast majority of people hardly use, or even have a need for, any of these additional features.

Therefore, in the end, most of us are really just writing HTML with XML syntax, and, indeed, we are even serving it with the text/html MIME type. While this is technically allowed for XHTML, such documents must follow certain guidelines – so much so that we are basically reduced to writing HTML anyway, just with a few extra syntactic restrictions.

Indeed, one of the reasons why people do advocate XHTML is because of its stricter syntax, and this is true; formally, XML’s syntax is more restrictive than that of SGML, which can be written in very strange ways. However, there is nothing to stop us writing HTML in syntactically conservative manner as well – there is nothing in the language that stops us from doing that. The validator won’t pick it up, you say? Well, the validator doesn’t pick up many things, anyway, and one must not let writing in XHTML lure them into a false sense of security when they see that big “valid” sign. In my opinion, the extraneous syntactic additions of XHTML just make understanding the languages more difficult, and ultimately make the process of constructing valid documents more difficult, especially for beginners.

In the end, there are some cases in which the use of XHTML is advantageous, such as for more convenient parsing by other scripts. Nevertheless, in the vast majority of cases, writing in XHTML conveys no significant advantages over HTML, and remains by far the simpler and more compatible option. Even the W3C have given up on future separate versions of XHTML, preferring to focus on SGML in HTML5, and then serialize the language for XML afterwards.

Quick tip - CSS3 resize attribute

In Safari and other webkit browsers, the textareas are resizable – you can click-and-drag at their corners to change their dimensions. Ever wondered how you could turn that off, or even apply the behaviour to other elements?

Well, it’s simply an implementation of the CSS3 resize attribute, which is part of the new “user interface” section of the specification (which also includes some other pretty cool things, like the ability to change the box model).

But anyway, to disable resizing, simply set the resize attribute for textareas to none:

textarea { resize:none; }

There are several other possible values for the attribute, which can be found at the link above.

A simple implementation of byte-pair encoding

Byte pair encoding is a simple but (sometimes) effective algorithm for compressing data (especially textual data). Best of all, it is very easy to understand! Therefore, in this experiment I have created a simple Python script that implements byte pair encoding on files.

Basically, byte pair encoding works by finding the most common pair of bytes in a file, and replacing them with a single unused byte, at the same time storing that association in a dictionary. It then does this over and over again until there are either no pairs that occur more than two times or no unused characters left.

This script doesn’t implement all the concepts described in the original paper on the encoding method (Gage 1994), but should still provide a nice example of how it works.

Note that while this method of encoding may sound cool, it has its limitations. Think about binary files (e.g. images, programs, and pretty much all other files besides plain-text ones) – how much room would there be for additional compression through byte pairs? Try it!

A diagram of organic reaction pathways

Following on from part one of my series of chemistry visualisations is a useful diagram detailing the components of many common organic reactions, that typical high school students may come across in their work.

The chart is quite easy to follow – just trace the arrows from their start to end, adding together where there are addition symbols. If two arrows meet, the chemicals they originate from are to be combined. If there is a substance shown on a line in parenthesis, it is a catalyst for the reaction the arrow indicates.

Note: this table is primarily intended as a revision tool for High School chemistry students, particularly those studying the Victoria, Australian VCE Chemistry 3/4 syllabus. Complete accuracy is not guaranteed (and if you see any mistakes, please tell me), though it certainly got me through chemistry.

Apple machines a "walled garden"

For years, a dominant debate in the technology world has been the “Mac v PC”* question – that is, whether the products produced by Apple, or those made by Microsoft, are better, and in particular which company’s operating system is superior. While I don’t think there is an objective answer to this issue, I do believe there are some key differences between the two competing products.

The main of these differences is in the business models by which Apple and Microsoft distribute their two operating systems. While Microsoft works through a licensing model, making the software and then selling it to other manufacturers to place within their computers, Apple directly distribute their OS with their own small pool of hardware.

Users of Apple technology live in a walled garden, a little ecosystem of compatible Apple-approved hardware (and in some cases, like the iPhone’s, software) where everything can be said to be “perfect”. Components are carefully chosen for compatibility, and often single vendors (Intel, Nvidia) are exclusively selected, to aid the process. What the end-user finally gets is a nice package, that they can set up and use, and which “just works”. And that’s it.


Validation ensures correct parsing, not rendering

Many times I hear people say that their pages “validate, but still won’t display right”. However, it is important to remember that validation only checks a page’s adherence to a particular document type declaration, and whether they are syntactically well-formed as a markup document.

Validators don’t somehow also magically determine whether the page is actually constructed to display an aesthetically pleasing image, or the “correct” one that the developer expects to appear, and they definitely can’t tell how well a HTML document will display across various browsers. That is something that developers have to figure out themselves.

Nevertheless, if a page is invalid, then it is impossible to say how a certain user agent will interpret the content, and multiple quirks are likely to appear as the parser attempts to make sense of your technically mangled code – and by then, it’s not very easy to proceed to creating a correctly-rendered page, either. So validation does matter when you are creating markup documents, but it is entirely possible to create perfectly valid documents that still look really strange when actually rendered.

A chemistry table of everything

Wow, I never realised that the start of the year could be so busy! Anyway, while I look for new interesting things to post, here is something that I made a while ago – a table of “everything” for chemistry measures, detailing their relations to the mole.

Update: Find this useful? Maybe you’d like part two of our series: a diagram of organic reaction pathways.

The instructions are on the A4 document, but you basically just follow the symbols of one colour around the semi-triangular table, counting the thick lines as “equals” and the thin ones as “multiply”. So, if we want to find out the relationship between mass (m) and moles (n), we just look at pink, and following it around get m = M × n. Similarly, for the ideal gas law, we look at light blue, and get V × P = n × R × T. Simple, eh?

Find it confusing? Have a suggestion? Then post a comment, and I’ll see what I can come up with (though it’s a while since I gave up chemistry)!

Note: this table is primarily intended as a revision tool for High School chemistry students, particularly those studying the Victoria, Australian VCE Chemistry 3/4 syllabus.