Google has released today probably the coolest doodad you can make for a logo. It’s a JavaScript version of Pacman, along with the original sounds, although these use Flash.

I’ve managed to save a local copy of the game for the sake of keeping such a cool piece of JavaScript code. I hope Google or Namco don’t mind. In any cases, it doesn’t run directly on my server, for reasons I still ignore (I have to go through minified JavaScript from Google and it’s a real puzzle), but this copy should manage to run from your hard drive.

I’ll probably be releasing the JavaScript code in human-readable form soon so that we can all learn from this cool piece of JavaScript. Additionally, with the <audio> element, HTML now has a sound API (kinda), so I believe it would be possible to implement this game without having to use Flash at all. Google didn’t do this, but it’s understandable as the game works as well on IE.  A pure HTML5 solution probably wouldn’t be so cross-browser for now. With the launch of WebM however, I have a vested interest in exploring the possibilities.

In a very surprising move, Google just touched what no one dared to touch before, what actually appears in the address bar.

Well, actually Microsoft did decide to touch it once, by graying out everything that isn’t part of the domain in the address bar when you’re not typing and your mouse isn’t on the address bar. Google copied them with Chrome but botched the whole goal, removing the un-graying action when you’re actually typing something and leaving the whole domain name including the sub-domain in full black, which makes the point of doing such a thing pretty worthless, since it’s technically supposed to help people see when they are on phishing web sites.

For example, a fake PayPal web site would look like this in both scenarios:

I thus think it’s very clear for the end user of IE 8 that they’re not on paypal.com but on fake.com, however the distinction isn’t so clear in Google Chrome. Note that Firefox, Opera and Safari provide absolutely no such clues to inform users on the validity of a web site. As a reader of this blog, you might think that having highlighting is unnecessary and that even without it anyone can tell if it’s a fake address, but you’d be surprised at how frequent Internet users get fooled quite easy, even on IE 8. Actually, there’s a strong percentage of users who don’t even know what a sub-domain is.

But in Google’s case, I tend to believe they highlight the address that way to favor quick identification instead of doing it for security purposes. Considering Google’s practical aim for speed, efficiency, and, well, search, it’d make a lot of sense for them to think that way, especially given the efforts they have gone through to simplify the address bar. Google is the first to combine the search and the address bar by default, and Chrome is also unique in being the first browser to prioritize on direct results (ex: engadget.com) while typing in the address bar instead of giving the most recent history item (ex: www.engadget.com/2010/04/13/editorial-engadget-on-microsoft-kin/).

What Google Did

Starting with Chromium 5.0.377.0 (I think, but I’ve noticed it since I installed this release, jumps from 370 so it’s in-between), Google decided that the famous but confusing http://www. was no longer. Instead, it’s now stripped from the address bar on whatever web site you go to.

So, what’s up with that and why is it so important? Keep reading to find out.

History of the “www”

WWW, or World Wide Web, is well, the Internet as we know it today. Back then, FTP and NNTP protocols used prefixes like ftp:// and nntp:// in order to define what they were. They still do today, but the practice of using such prefixes to define the services was transcended into the WWW.

However, because web sites weren’t transfered over the www protocol but on the http protocol, which they still are today, it was impossible to prefix a web site with www://. It had to be http://, because of its underlying protocol. The Internet web sites however, came to be known as a whole as the World Wide Web, or WWW, and not HTTP. And so, in order to market web sites as being web sites, the generic www sub-domain was prefixed to practically every web site in existence.

When web sites were just a new thing, the practice of prefixing addresses with www was meaningful. Anything preceded by www on a business card for instance automatically referred to a web site.

They could have wrote http, but web browsers were quick to implement automatic http:// input before it even the web even became mainstream. Given that the HTTP protocol had to be written http://, www was much more elegant, hence its popularity in the mainstream market.

www is actually a sub-domain

But in reality, www is actually a sub-domain. Contrary to popular belief, there is no real difference between www, ww2, www2, blablabla and somethingelse. If any of these precede a web site, they’re a sub-domain. Some people are so used to www they think they have to put it in front of actual sub-domains, resulting in ugliness like www.sub-domain.domain.com. Yes, this is actually a dual sub-domain, and believe it or not, but famous web sites like deviantART implement it to avoid cases where users would type www.user.deviantart.com and come up with an error instead of the user page.

However, a sub-domain is distinct from its domain, so http://www.pacoup.com and http://pacoup.com actually don’t necessarily point to the same web site. Usually though, practice has been that http:// and http://www. point to the same web site, with one often redirecting the user to the correct sub-domain or domain, which is the case of most dynamic web sites that require a consistent web domain in order to function properly, this blog not being an exception.

In fact, you can test it yourself. Simply type www.pacoup.com and press enter, and you’ll find that you’ve been redirect to pacoup.com without the www. In most cases where a web site works on both domains, it’ll be a static web site.

Arising problems because of uneducated admins

In the old days of the web, www became so well-known that a significant amount of web sites didn’t work at all without www before the address. In fact, the host didn’t even support accessing the domain without the www sub-domain, which led to the false belief that web addresses must be preceded by a www. Heck, the ability to access a web site with or without the preceding www even became a feature on some low-tech-consumer-targeting hosts such as 1and1 and still is today.

Unfortunately, major web sites like practically all the Government of Canada web sites and myriad other small web sites don’t work without the www. Even the USA’s CIA web site doesn’t work without it because its SSL certificate is attached to www.cia.gov and cia.gov.

Fortunately, in the case of Google Chrome, it redirects you to a Google Search page proposing the correct address. Baldy setup SSL web sites like cia.gov however throw you a very pretty dangerous web site warning.

To www or to not www?

I’m very much in line with what Google thinks, www should go. The prefix www is inherently wrong so you should not use it. It’s not questionable, it’s just the way it’s made. Referring to your main web site via a sub-domain is just plain stupid, even though the industry’s been doing it for ages.

For the sakes of compatibility, you should include a redirecting www sub-domain for the uneducated masses out there, but you should never default your web site to www. Don’t redirect users from http:// to http://www., redirect them from http://www. to http://. That’s the way it’s meant to be, and in fact, the first web site to ever exist didn’t use any www prefix (although it was a sub-domain, namely nxoc01.cern.ch).

Is there confusion because you didn’t include the www? No, frankly, people today recognize .com, .net, .org, or .anything for that matter. Advertisers discovered it was more efficient to forgo a prefix before their company name. www.microsoft.com/silverlight is not as easy on the eyes as microsoft.com/silverlight, and the later provides the added benefit of providing the reader with the name of the company first instead of a generic “www” marking.

How Chrome handles it

In all actuality, Google did not remove the entire www sequence of web sites, they just removed the protocol sequence. In fact, it would be suicide to remove any www, because let’s not forget it’s a sub-domain. Such a rule would also be bound to remove regular sub-domains, which are very important.

But on web sites where Chrome detects it makes sense, such as www.engadget.com or www.techcrunch.com, the www is also stripped out. I don’t know how this is figured out, but it looks like it relies on a few tips, such as if the web site is powered by WordPress, etc.

Chrome is also smart in that it only hides the http sequence. Copying any address from the bar will copy the complete, http sequence included, address.

Simplicity Rules

In other words, Google has decided to push the simplicity of the web even further by getting rid of the www. Google Search still runs on the www, but I’m guessing changing this one is a bit more complicated considering the size of it. If this Chrome thing sticks though, I think it’s easy to see a very close future where Google.com comes without the www.

Advice for Web Masters

1. Redirect www to the raw, http:// address.
2. Never refer to your web site by including the word “www”
3. Keep a www sub-domain for compatibility reasons
4. Teach your friends and family to type addresses without the http or www sequence
5. Contact the owners of web sites who don’t provide www-less access with a polite advice email/letter
6. Twit a thank you to web sites like arstechnica.com that use the correct web address syntax

I’ve made a few tests on –videoquality encoding with Theora via ffmpeg2theora which I think is the best way to encode OGV media. Earlier tests conducted with ffmpeg2theora 0.25 reveal that 2-pass Target Bitrate encoding with Theora is less efficient than videoquality encoding, which is a one pass constant quality variable bitrate encode.

This might be surprising if you come from an H.264 encoding background, where quality-based encoders are almost nonexistent, but it’s quite the buzz with Theora. I could get the best quality encode possible on a somewhat motion-intensive animation with only 4.4 Mb/s.

Here’s the result of an intensive scene taken from an AMV that will appear in February at the G-AMV 2010 contest made by AMV-Canada. I’m the president of AMV-Canada and I do pretty much all of the grunt work of web encoding for the moment, so I was testing OGV encoding for our HTML 5 Open Video technology.

This scene is a very intensive scene which goes up to 7 Mb/s in VQ 10 . What you have to look for is discrepancies in the screenshots from VQ 9 down to VQ 0 comparatively to VQ 10. The video is a 740 x 410 pixels, which is a close approximate of what you can expect for an average SD video.

Benchmark

VQ 10

Size 99.03 MiB
Average Bitrate 4499 kb/s

VQ 9

Size 78.35 MiB
Average Bitrate 3589 kb/s

VQ 8

Size 61.41 MiB
Average Bitrate 2770 kb/s

VQ 7

Size 48.91 MiB
Average Bitrate 2255 kb/s

VQ 6

Size 39.79 MiB
Average Bitrate 1800 kb/s

VQ 5

Size 31.43 MiB
Average Bitrate 1415 kb/s

VQ 4

Size 24.52 MiB
Average Bitrate 1117 kb/s

VQ 3

Size 19.12 MiB
Average Bitrate 859 kb/s

VQ 2

Size 15.19 MiB
Average Bitrate 682 kb/s

VQ 1

Size 11.40 MiB
Average Bitrate 512 kb/s

VQ 0

Size 8.86 MiB
Average Bitrate 398 kb/s

Analysis

What you can observe is that the codec, in general, doesn’t start to drop in perceptible quality until VQ 8, and it’s still very subtle. VQ 8 is ideal for high quality encoding with minimal space.

VQ 7 starts to have noticeable blocking going on which often plague Theora videos. It’s very particular and while not exactly in your face, it’s always sort of there in lower quality Theora videos. VQ 7 might be more adapted to high quality web streaming.

VQ 6 and VQ 5 on the other hand fit perfectly in what the average H.264 encode looks like in terms of bitrate. While of substantially lower quality than H.264 at the same bitrate, both choices remain watchable and ideal for the web.

From VQ 4 and down, the codec starts to lose its ability to define straight lines and makes text increasingly hard to read. VQ 1 and VQ 2 then lose any ability to define detail and text becomes unreadable in most cases.

You can also enable –optimize in ffmpeg2theora, which makes encoding slightly slower and increases quality a bit. There’s definitely less blocking, but the difference is so minimal that with side-by-side comparison it’s often hard telling which is actually better. So while this might be a must when encoding, it’s definitely not worth re-encoding your whole library for it.

I’m seriously happy about Opera right now. Not only have they succeeded at keeping up with the technical updates, their browser is now finally another proud owner of a native shell on Mac.

This whole native shell movement really makes my eyes happy. Afterall, we did go from 9.6 to 10.5:

From the left to the right, Opera 9.6, Opera 10.1, Opera 10.5 Pre-Alpha for Labs.

10.5 also has a nice addition, smoothly animated tabs à-la-Safari.  We might see additional changes by the time this hits release, but it really makes me want to use Opera more. (Note, Opera 10.5 has other interface change niceties not covered here, but you get the gist of it; more animation and coolness, including for the first time being able to tab through checkboxes on Mac)

A note on speed

Opera Software proved once again that sheer technical expertise can surpass open source communities, as well Google on that note. On my computer, I got 393.2 ms for Opera 10.5 and 428.4 ms for Chrome 4 in the SunSpider JavaScript Benchmark, and it’s apparently even faster on Windows but I didn’t test that yet. Amazing.

Many thanks to Parakey for their Firebug Firefox Extension and to Opera Software for their Opera Dragonfly without which this CSS study wouldn’t have been possible.

If you’re an experienced web interface coder like me, the kind of guy who spent several years doing more than just toying around with HTML and CSS, you know that mastering these is pretty close to arcane magic. When using standards-compliant browsers, the CSS box model might not look logical. A lot of times I have faced issues where I thought the specifications were simply screwed up, but they are not. The real issue lies within the default CSS values established as standard.

It’s the real part that’s screwed up, but fortunately it’s easy to fix it and make it work the way it apparently should. The trick is to overwrite the defaults with your CSS style sheet. One marvel of specifying a higher than average amount of CSS rules is that even browsers like Internet Explorer 7 will end up displaying your web site correctly because a major problem in web standards is the default rule set. Hence, we’re essentially going to overwrite these defaults here.

Let’s start by breaking down this sample code:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>CSS Box Model Test</title>
    <style type="text/css">
      .div01
      {
        width:150px;
        height:150px;
        background-color:blue;
      }

      .div02
      {
        width:150px;
        height:150px;
        background-color:green;
      }
    </style>
  </head>
  <body>
    <div class="div01"></div>
    <div class="div02"></div>
  </body>
</html>

This perfectly valid HTML 5 code will produce a blue and a green square like this:

What’s important to notice here is how the defaults specify a margin of 8px all around the body element. These defaults are what make HTML easy and very much helped its success. It avoids us having to specify tons of display properties. However, simplicity is always at the cost of control. Hence, designing very complex CSS layouts might result in a few headaches linked to surprise default values that weren’t expected. Unlike what we tend to think, most padding and margin values actually don’t default to 0.

To show what I mean, change the div02 to this:

<div class="div02">
  <h1>H1</h1>
</div>

And you get:

Take note here that we did not provide any padding or margin information to any of the squares for them to move down like this. If you see this in one of your complex designs, you might end up searching a complete afternoon for some discrepancies in your div blocks. The margin is actually on neither squares, those default to the expected 0px margin; it’s on the h1.

The problem lies in common mistakes made with the W3C Box Model, which differs quite a lot from the traditional box model older web developers might be used to. Quirksmode.org explains it very well.

Firebug can also give us insight at how the margin affects the result:

This is where it gets tricky though. The width of any text element like our h1 is predefined to fill its parent container from left to right. Our h1′s width is thus 150px. The height of any text element is predefined based on the font. In this case, it’s 36 px. This is shown by the green highlight around the h1. Our h1 also has a predefined top and bottom margin so to make it stand from the rest of the text. This is natural and removing this margin makes your text look cramped, but this margin is exactly where all the problem is.

In the W3C Box Model, there exists three ays to define extra spacing between elements; padding, borders and margins. The padding comes first, and is then followed by any border, and lastly by the margin. All of these elements exist outside the element’s width and height, meaning a 20px padding and a 100px width will equal a total width of 120px.

The border is self-explanatory, but the difference between a padding and a margin is more subtle and difficult to grasp. Layed down on paper though, it’s actually quite simple.

The margin is transparent and lies outside the border of an element. Even if the element has a border of 0px, it is still outside the border. A margin does not acquire the background color of an element.

The padding on the other hand lies between the border and the box of an element, or inside the border if you want. Hence, a lot of people like to call the padding a margin but for the an element’s content instead of the box. A padding acquires the background color of an element because it is part of the content (what’s within the border).

If we base ourself on the previously explained box model, then logically the h1 should be entirely contained within our green box, but it is not so. Why? Because the standards people screwed up. Wait, wait, you’re thinking, is this guy serious? Well yes I am, and all the evidence is there to prove it. In fact, a lot of modifications we can do to the code clearly demonstrate how every single browser manufacturer, probably due to the people who made the ACID tests, communally screwed up on this and manufactured a giant bug.

To understand how this bug works, let’s first look at what the result should look like:

To obtain the following, I replaced the 21px margin with a 21px padding like so:

h1
{
  margin-top:0px;
  padding-top:21px;
}

Doing so does provide a quick fix, but not in the event you’d be using a background for your h1 element. While such an occurence is rare, major web sites like Engadget use this background technique to make their links’ roll-overs. Replacing the margin with a padding would completely screw up their design by incurring a huge extra highlight on the text like so:

The real way to circumvent the problem is to use the box model in a way that doesn’t include the bug. Weirdly enough, this is quite easy and proves that it really is a bug. Simply add any padding or border to the affected box and voila, problem solved:

.div02
{
  width:150px;
  height:150px;
  background-color:green;
  padding-top:1px;
}

But just for the sake of it, I’ve made another example that demonstrates how this can only be a bug.

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>CSS Box Model Test</title>
    <style type="text/css">
      .div01
      {
        width:150px;
        height:150px;
        background-color:blue;
      }

      .div02
      {
        width:150px;
        height:150px;
        background-color:green;
        color:white;
      }

      .div03
      {
        width:150px;
        height:150px;
        background-color:red;
      }

      .div04
      {
        width:100px;
        height:100px;
        background-color:yellow;
      }

      .div05
      {
        width:150px;
        height:150px;
        background-color:black;
      }

      .div06
      {
        width:100px;
        height:100px;
        background-color:yellow;
        position:relative;
        top:16px;
      }

      .div07
      {
        width:150px;
        height:150px;
        background-color:blue;
      }

      .div08
      {
        width:150px;
        height:150px;
        background-color:green;
        color:white;
        margin-top:20px;
      }

      .div09
      {
        width:300px;
        height:400px;
        background-color:red;
      }

      .div10
      {
        width:200px;
        height:140px;
        background-color:yellow;
      }
    </style>
  </head>
  <body>
    <div></div>
    <div>
      <p>Paragraphs are also affected</p>
    </div>

    <div>
      <div><p>This…</p></div>
    </div>

    <div>
      <div><p style="margin-top:0px;">should technically do this.</p></div>
    </div>

    <div></div>
    <div>Any block following another block with a margin is affected. This text doesn't have any margin.<br>
    The box does.</div>

    <div>
      <div><p>The first block remains intact or influences the one on the previous level if it exists as it is in this scenario.</p></div>
      <div><p>The second block follows the bug partern.</p></div>
    </div>
  </body>
</html>

Since it is possible to reproduce this bug at all times under specific conditions, it is clear this is a manufactured bug that has been hidden away as standard. If someone believes this is not a bug and that there is a logical explanation to this behavior, please post a comment and explain! (One from Håkon Wium Lie would be appreciated)

In my new career as a Java developer, as I’m French, I’ve been using the siteduzero.com’s Java tutorial. Actually, that’s just when I didn’t want to get my big Deitel and Deitel book out, but seriously, forget about SiteDuZero’s crap. I’m really sorry for the author, but as a message to you: “Your code sucks”.

All that said, if you want a serious and reliable source to learn Java, just try Java Tutorials! It’s an official publication from Sun, it’s free, and it’s more than complete (check out that massive index). You can even buy it in book form.

The only hiccup with this is the coding style. While K&R might be Java conventions, it might not be your cup of tee. I know, I’m allergic to K&R too and I prefer Allman. If you really can’t look at Sun’s code, there’s always Deitel and Deitel’s Java books.

Note: This does not cover Java EE. For that go to the Java EE 5 Tutorials (lol, it’s amazing really, they have it for like everything).

Well, after trying to find out via Google, I gave up with the stupid answers from dumb ASP.net programmers such as “VBScript is not a server-side language” or “you can’t run .asp on IIS 7″.

Sure…

So for the curious, here it is:

1. Start
2. Search for Internet Information Services (IIS) Manager
3. In Debugging Properties, set “Send Errors To Browser”  to true
4. Don’t forget to click “Apply” under the Actions panel on the right

That’s it. IIS will now shoot the runtime errors directly into your browser window instead of saying something went wrong with the URL. I’m pretty sure this is on by default in previous IIS versions, hence the confusion.

You might also want to turn on “Enable Parent Paths” in the Behavior section, which will enable the ..\ relative path notation. Frankly I don’t know why this is turned off by default… but hey, we’re talking classic ASP here. It’s not like Microsoft really cares.

Might I say finally?

At least, it looks like one Mobile Carrier in Canada understood; don’t stop charging for access fees, just hide them in more expensive plans. I admit it doesn’t really change anything. TELUS’s new charging model isn’t very different than previous prices in the end, but the jump to an all included price that doesn’t hide service charges is an appreciated change.

For example, say you take the Clear Choice iPhone 50, a 50$ plan that gives you 150 local minutes and a choice of extra features, like doubling minutes or 1000 outgoing text messages and unlimited incoming, which unfortunately means Canadian providers have, as rumored, started to charge for incoming text messages (total rip-off) and 500 MB of data (also a total rip-off). Well, that’s it, that’s all you pay, 50$.

On the other hand, Bell has an almost identical iPhone plan that looks cheaper; 45$ (the difference being that you only have one extra option; favorite 5 numbers. But add on top of that the system access fees; 6.95$ and the 0.75$ 9-1-1 emergency service fee, and you get a fabulous 52.70$ (not mentioning the fact that the 9-1-1 service charges can be as high 1.28$ depending on the province, in this case New Brunswick). So, who’s cheaper now? Note that, however cool TELUS’s new scheme may be, Bell’s higher cost plans totally kick TELUS’s ass, really.

And on Rogers, well as always, it’s even higher, coming in at 57.58$ for the same thing TELUS offers. Oh, and I almost forgot to mention Rogers’ best matching plan to the highest Bell offers, coming in at 105$, doesn’t even manage to match the Bell’s offered minutes and unlimited text messaging plus the unlimited favorite 5 numbers for 95$. Good luck Rogers, cause really, you’re total rip-off. I hope nobody ever buys an iPhone again from Rogers.

If you read a lot of journalistic articles, chances are you have stumbled upon the marks “i.e.” and “e.g.”. Chances are you probably also never thought you never truly knew what they meant.

The confusion is obvious when you take a good look. First and foremost, we have the dreaded “i.e.”. Most people either pronounce it “I E” or “in example”, both of which are wrong. “i.e.” is actually an acronym for Latin “id est”, literally “that is”. The grammatical sens of a phrase may thus be very different if you interpret it wrong. Besides, “in example” is wrong grammar. You should always use “for example”.

Second but not last is “e.g.”. Much in the same way, “e.g.” is not read by its sounding which is similar to “example”, but rather as the Latin “exempli gratia”, literally “for the sake of an example”. Because of its close meaning, reading “e.g.” as “for example” is generally accepted and can be used in situations which require such a construct.

Very often we overhear Standard in International. The technical definition of international is that it is something pertaining to two or more nations at the same time. As a web site owner, being conscious of your audience is important, and that audience can turn out to be more than just American.

This is why you have to learn to speak internationally, and probably the biggest obstacle is Time Notation, for which there is generally two solutions.

The Standards Solution

One easy way to cater to an international audience, if you happen to have one (Google Analytics is a very good way to find out), is to simply put everything in standard notation.

For example, when announcing an live web event, you could use dates like these: 2010-02-07

This normally confusing notation, is 02 or 07 the month, can never be because it’s part of the IEC standard for dates, so it’s YYYY-MM-DD and because it is the only date format that starts with the year.

However, English isn’t Japanese, and we were conditioned to naming months by their name, and not by numbers, so using the IEC standard notation is not the best for readability because we have to constantly translate the middle number to a month.

The same happens with time. We could use the standard 24:00 clock, but it wouldn’t cater to France which uses an h instead of a colon, like this: 24h.

The Local Solution

One real solution is to take a good look at your audience. Is it international? Etc.
Although you can do that by studying demographic statistics, the language you use is an easy way to determine what standard to use.

For example, French-speaking communities practically never use p.m and a.m with a 12 hour clock (the exception being Canadian French, although the 24 hour notation is still common). Most people in France that have never been exposed to American English will look at you weird if you say p.m. or a.m. as they probably never heard that before.

So, adapting is the key. For example, on AMV-Canada’s web site, I used a mixed representation for the different populations that goes like this for live show: 2 p.m PST, 5 p.m. EST and 22:00 in the UK. While this may look bizarre at first, it is unambiguous as Canadians and Americans will read the part they need easily while skipping a different notation for an piece of information not important to them and the British will do the same by simply reading their version.

It’s also better to avoid writing dates without the month, and to avoid things such as UTC -05 when denoting Eastern Standard Time (EST). You’d be surprised at how many people don’t know what UTC or GMT are, even EST is sometimes not known.

If you’re American, avoid naming web events with TV notations like 8/7c as these are not only majorly unknown to every other English speaking country, but they are also not the same time across the entire United States. 8/7c effectively equals 8 EST, 8 PST, 7 CST and 7 MST, but if you live on the East Cost, you might have meant 8 EST and 5 PST, 7 CST and 6 MST.

However, Local Adapting requires some research into each country’s way of specifying dates and time.