Since web cookies were invented by Netscape all those years ago, they have had one large flaw which has gone unfixed for years on end. Now, you might think, if this flaw is that large, then why hasn’t it been fixed before? Well, it’s a story all about numerous RFCs, cookie implementations and the mess that is domain registration rules.
Basically, each domain registry gets to decide how people can register domain names under their top-level domain. Some have chosen to allow direct registration of second-level domains (e.g. .be for Belgium) while some have decided to only allow third-level registrations (e.g. .co.uk for the UK). What this means is that there is no algorithmic method of working out which top-level domains allow second-level registrations, which only allow third-level and which allow a combination of both. While this may not sound too important, it has an important side effect for cookie setting.
What it means is that the web browser cannot effectively decide at which level cookies are allowed to be set. Therefore, the rule followed is that no cookies can be set for top-level domains (such as .com). However, this means that people can actually set cookies for second-level domains where they shouldn’t be able to (such as .co.uk). PayPal actually does this, and it means that its cookie gets sent by the browser to every single .co.uk website. This is, of course, a major breach of security, but one which has been difficult to plug for a long time.
Now though, Mozilla have come up with a method of deciding where cookies can and cannot be set. It is called the public suffix list, and it’s basically a text database of every single top-level domain and at which level cookies can be set. Checking against this database will allow the browser to decide whether to allow a cookie or block it.
I am one of the volunteers currently working on this project, and hopefully with the co-operation of the registries, information in cookies will soon become that little bit more secure. Mozilla also hopes to distribute this file to other browser manufacturers, to allow them to secure their cookie handling as well, as a service to the public.
Three days ago, Andrei Herasimchuk, the well known ex-Adobe interface designer wrote an open letter to Adobe, posted on his blog, with regards to the poor state of typography on the web.
The gist of the letter is that Adobe, as a typographical leader, should release maybe eight to twelve core fonts into the public domain, so that they may be integrated into operating systems and other software, therefore making their availabilty nearly ubiquitous and allowing web designers to use them.
For Adobe, any consequences which may amount to a small loss of revenue from selling licenses to these fonts will be more than catered for by greater support of their actions by many designers around the world, who will, for the first time, be able to confidently use fonts other than the usual Arial, Georgia, Times New Roman and Verdana (most of them released by Microsoft in their Core Web Fonts package, since discontinued).
Talking of Microsoft, Jeff Croft has also replied to Andrei’s post, but this time urging Microsoft to distribute some of their newly-commissioned fonts Calibri, Cambria, Candara, Consolas, Constantia and Corbel more widely. Currently, they are set to be shipped with Windows Vista and Microsoft Office 2007. He also urges Apple to license these fonts from Microsoft and include them with Mac OS X.
Although I’m not a typography connoisseur or expert, I fully support both of these calls as I can see the immense benefits that it will bring to the web community at large. Having more than one or two fonts to reliably use will make every designer’s job so much easier and rewarding, and will make the web a much nicer and prettier place.
According to the W3C, XHTML should be served with the application/xhtml+xml MIME type rather than text/html, which is used for plain old HTML, or application/xml and text/xml, which some people (incorrectly) use instead.
Until now, I’ve served my pages with text/html as Internet Explorer does not support application/xhtml+xml and offers your pages for download rather than displaying them as it should.
I found an article yesterday which details a way in which you can serve your pages with the appropriate type depending on the browser. A sample PHP script was also included. I took the script and modified it to serve my purposes, and now my pages are served as application/xhtml+xml if the browser supports it, and text/html otherwise.
Continue reading "The perils of MIME types and XHTML" »
I’ve been using Windows Live Writer for a few days now and posting all of my blog articles using it. I’ve found it an altogether pleasing experience, especially as the software makes it so easy to do many things. However, there are a few small things that I think could be improved.
- You can’t give an article a separate excerpt, which makes Movable Type using a first part of your post body instead. It’s not too bad though, as I prefer the latter behaviour.
- When you paste a multi-paragraph block of text into a blockquote, paragraphs aren’t made properly. Every paragraph starts with a <p> but doesn’t end with a matching </p>, making it invalid XHTML. I don’t know if this is also the case with normal blocks of pasted text as opposed to a blockquote.
- The Windows Live Writer window does not seem to remember its last size settings and always default to a small windows at the bottom of the screen.
Other than these small annoyances, the software is great for a beta.
So Microsoft have decided to conquer the blogging-from-a-PC-application market by releasing the beta of Windows Live Writer.
Basically, the software is a glorified version of the venerable WordPad that’s been with us since Windows 3.1, updated with the 2007 style and with the main functionality of posting to a blog. In a first for Microsoft, they’ve made the tool work with blogging tools other than their own, and even this beta version works with an amazing number of apps, although more support is planned for future releases. The application mainly works using XML-RPC and other such interfacing standards, which means that its support can be extended.
Set-up is very easy, and all you really need to do is to enter the URL of your blog, plus a username and password. The software works out most of the rest itself, and only asks you if it needs further information (in my case, it asked for Movable Type’s XML-RPC URL, which is easy to work out as it offers the placeholders). You can also provide some FTP details if you want it to use those to upload your pictures, otherwise it just uploads it to your weblog app, which then stores it somewhere or another.
The main window contains a writing pane with all the usual rich-text editing tools, plus a spelling checker, which is a must for all us blogging types! There’s even a function to insert pictures and maps from Windows Live Maps. The editor saves drafts just in case that all-important post goes missing :)
After posting your entry, you can have a look at it on your weblog, and if the software supports it, the writing pane itself adapts to show your post in your blog’s style, even as you’re typing it, which is a nice touch.
The interface itself needs a little tweaking here and there and maybe some touch-ups, but overall, it’s a very nice version 1.0 app from the Windows Live people. Well done Microsoft!
PS. Oh, and if you were wondering, this post itself was written and posted using Windows Live Writer. See how easy it is? If you want more information, or to download it and try it out for yourself, visit the Windows Live Writer Zone.
I spent a good while yesterday wading through all of my bookmarked favourite blogs and adding their feeds to my reader. It was surprising just how few feeds I was keeping up with on a regular basis, and I throught it was high time I got a good grip on things and kept up. I now have more than enough to keep me occupied for a good 15 minutes a day, which is about the amount of time I’m willing to spend going through them. Some people have commented in the past about the inability to keep up with information overload, but as long as you keep the list sensible and always make sure you only read what matters then you should be just fine :)
It’s always interesting to see a cross-section of the browsers that people use when browsing this site. Above all, it allows me to test my site more with those browsers to make sure that the majority of people are getting a best out of the site.
Here’s my current breakdown courtesy of Mint:
As you can see, both Internet Explorer and Firefox are neck-and-neck on 45%, accounting together for 90% of my visitors. To be honest, I would have expected more Firefox users, but its also interesting to see that 3% of Internet Explorer users are using the upcoming version 7 (not shown).
What do your browser stats say about you?
A few months ago, I came across an article named “Web Developers: Speed up your pages!” Yes, it was written in November 2005, but that’s just like me - late to everything!
I read through the article thinking that it would contain valuable advice which I could use in order to speed up load time (which was a problem I had for quite a while before I finally found a way to fix it). However, as I went through it, I found that much of the advice seemed either to be flawed or contradictory to web standards (especially XHTML). Therefore, I’ve decided to look at each point in turn and discuss whether it’s really necessary and whether it’ll actually make that much of a difference.
Continue reading "Standards vs. Speed" »
As we all know by now, Internet Explorer has dire support for PNGs, especially for alpha transparency.
While building wackomenace 6, I came across yet another transparency bug in Internet Explorer. 8-bit PNGs using alpha transparency are displayed with jagged edges. I used the Internet Explorer non-standard CSS filter to load the PNG in order to make the transparency work in the first place, but this was the next bug.
Continue reading "Transparent PNGs and Internet Explorer" »
