Back to the subject in hand though; why did Facebook feel it was necessary to come up with a complete new iPhone UI? As Peter correctly suggested, the sites entire stylesheet could be incorporated into a Media Query based on max-width so that handheld devices of varying width (within reason) are dealt the same layout. Granted, the site does have a prominent theme replicating the behaviour and colour palette that iPhone uses, so although the URL can of course be accessed through any browser (Opera Mini in my case), there is an obvious mis-match between the theme of the site and the skin that Opera Mini uses (it’s also worth noting that Opera Mini fell flat on it’s face trying to render anything other than the logo, links the either side of it, and the navigation menu below that- I’m guessing this is down to the processing power of my Nokia E65 as opposed to the browser itself).

Also it’s interesting that the site’s in quirks mode, and check out the body > .fullScreen declaration- for some strange reason they’ve chosen to use a combination of min-height and max-height to emulate height!

Whilst it’s a huge step forward (in the right direction, I’d like to add), there’s still no alternative (and I doubt there will be for a long time to come) to textual content being marked up with the correct HTML semantics if you wish for your Flash-based content to be a) accessible, b) on an equal footing with its semantic HTML file counterparts for ranking results (based purely on internal factors in this particular context), c) quick to download… the list goes on. Add to that the ability to aggregate physical files (HTML, video formats) into an XML sitemap, rather than relying purely on Google to identify your new pages through crawling links, and you have still no excuse for not correctly marking up your textual content semantically.

So whilst I welcome this news that textual content and hyperlinks within Flash files are that bit more accessible, I’ll still get a shiver down my spine every time I see any form of text embedded in a Flash file.

This is the Adobe press release on the matter which goes into more detail, and here’s one from Google

If you have Google Web Accelerator installed on your machine, it’s best for you to not to use any web apps that incorporate destructive links, as you might find out one day that you’ve removed page content, left groups you intentionally joined, deleted users on your site etc - the list could go on.

Background

Straight from the horses mouth:-

“Google Web Accelerator is an application that uses the power of Google’s global computer network to make web pages load faster. Google Web Accelerator is easy to use; all you have to do is download and install it, and from then on many web pages will automatically load faster than before.”

Google Web Accelerator uses various strategies to make your web pages load faster, including:

• Sending your page requests through Google machines dedicated to handling Google Web Accelerator traffic.
• Storing copies of frequently looked at pages to make them quickly accessible.
• Downloading only the updates if a web page has changed slightly since you last viewed it.
• Prefetching certain pages onto your computer in advance.
• Managing your Internet connection to reduce delays.
• Compressing data before sending it to your computer.

Essentially, it prefetches pages to cache by spidering links that present on the page your viewing at a given time. So this begs the question - what links are, and aren’t prefetchable? Well, Googles Support pages on the matter state that in line with the HTTP 1.1 spec, “‘the GET method is defined as a Safe Method which “SHOULD NOT have the significance of taking an action other than retrieval.’ In practice, Google Web Accelerator does not prefetch links which have query parameters (i.e. have a “?” in the URL) and encrypted pages (i.e. URL starting with https://).”

In v1.0 we could directly target it as it identified its requests with a “X-moz: prefetch” header, however apparently in v2.0, the header has dissapeared. Having said that, it’s slightly strange that Google haven’t updated their pages to reflect the apparent changes in v2.0

Although I have no first-hand experience of this, it was highlighted to me (cheers Mark) when I was implementing the UI for a past project.

I’ll let you read through a number of useful comments on the subject submitted by readers… I’m off to bed.

As you can read if you visit the link, the article starts off by explaining what Acid2 is and the hype at Mix08 surrounding IE8. What I found particularly interesting in the article was a single comment from Eric Meyer; it reads, “CSS support in IE8 looks thus far to be very, very promising…”. He does actually mention that he’s “never had any inside track” from the IE guys, and granted, his comments did come before MS released a document outlining planned CSS support in the IE8 final release (which I talk more about in a recent post), but still…

Also during my time off I was approached by an old acqaintance from Teachers TV, who has persuaded me to take up a position as Senior ID on a fairly large-scale project in Reading; unfortunately, I can’t really say anymore than that at the moment!

A couple of weeks ago I attended the first day of @Media London (too hungover from the end of day drinking for the second). It was great to finally put faces to names (and amusing avatars); from CSS3.Info, I met both Peter and David, and the party after the first was a great chance to meet a few new faces. It was great to meet Lachlan Hunt and speak to him after his and James Graham’s informative talk on HTML5. After we drank the bar dry, a few of us went onto a small Italian restaurant (complete with it’s own real-life take of a Sopranos scene) across the river, where I had a chance to chat to John Resig along with a few others.

At the conference there were a couple of developers from the BBC who talked about the new sites design (homepage in particular) in more detail. One interesting piece of news that came from their talk was that they decided to build themselves a bespoke JS library from the ground up due to the vast array of browsers that they have to support (apparently FF 1.3 is particularly troublesome with JQuery). From what I recollect, they were mentioning that it might be released within the next couple of months.

So sorry guys for the lack of posts within the last few weeks, but promise you’ll see a lot more activity from now on

My tasks for my time off are as follows:-

1. Get super fit like I was a couple of years ago before a little thing called ‘work’ came along.
2. Go visit my mates who are at uni
3. Do some local voluntary work; I really want working with people who aren’t as fortunate as me to give me a more rounded view on life, ‘cos I kind of take life a bit for granted at the mo, but I want that to change…

Note to spammers - I can understand you’re eager to post your unrelated links on my posts, but please can you refrain from doing so for the next couple of months? I won’t constantly be at my desk like I’ve been up until now, so will be unable to remove them as quickly - thanks!

So finally, please don’t expect many (if not any) new posts to appear on the site - I wish you all well, and hopefully see you all back here in a couple of months!

Two resolutions that the post doesn’t mention however, are to do with the public disclosure of dialogue within the Working Group relating specifically to IRC log’s and meeting minutes.

It was decided that from now on the WG’s minutes and also IRC logs will be made public; there was also talk about opening up process-related discussions into a new public mailing list, although this has apparently been put on the back burner for the moment.

What I feel this does show is that the WG are listening to what people are wanting and have made their workings more transparent, which is great news.

Here are the first minutes

Look’s like a couple of regression bugs as they certainly weren’t there in 3.0- think I’ll need to come up with a test case or two.

I’m really trying to get my head round why this proposal was put forward (possibly because I’m particularly tired tonight and am missing some blatant advantages, in which case someone please point them out to me), but I’m really not sure why we’re trying to turn CSS into a programming language (see last two lines of Appendix E).

As I see it, there are several disadvantages to straying After an editor for this proposed spec has been found (apparently they’ve already identified someone) he/she will to dedicate a fair amount of resources into a) maintaing the spec, b) deciding on a suitable module for it to go into c) acquiring and managing use cases and d) finding two interoperable implmentations etc.

As far as I can see it, any constant/variable infrastructure would be completely backwards incompatible and there are currently no plans for a fallback option (I’m not sure how one could ever be implemented in this scenario?) which would be a huge problem taking into account the vast array of different levels of CSS support cross browser, resulting in widespread adoption becoming a lengthy process.

The problem that we’re trying to achieve has been a fundamental server-side lang feature since the dawn of time. There are no backwards compatibility issues and we don’t have to wait for vendors to support it - the server side solution can be used today!