John Smith's Blog

Ramblings (mostly) about technical stuff

CSS3 transitions on properties which haven't been explicitly defined

Posted by John Smith on

While continuing to fiddle with the CSS and JavaScript on this blog, I noticed a rather strange behaviour whilst testing on Chrome, where the page would render differently, apparently at random. This turned out to be largely down to issues with JavaScript executing before or after CSS had been applied, but it's also shown up something unpleasant with CSS3 transitions, where it seems that the only thing consistent between browsers is that none of them do what you (probably) want...

First off, a very quick overview of CSS transitions for the uninitiated. These are a means of having smooth changes between styling property values of HTML elements, and are supported in modern browsers i.e. Chrome, Opera, Safari, and Firefox from 4.0 onwards. (Forget IE, not even IE9 beta supports them.) Here's a bit of sample code that animates a <div> when you click on it - the most relevant bits are in cyan.

<div style="position: relative; left: 50px; font-size: x-large; -webkit-transition: all 2s linear; -moz-transition: all 2s linear; -o-transition: all 2s linear; transition: all 2s linear;" id="css3-demo-click-me">Click me</div> <script> document.getElementById("css3-demo-click-me").onclick = function(ev) { ev.target.style.left = (300 - parseInt(ev.target.style.left)) + "px"; }; </script>

Which you can see here:

Click me

The above example should work fine on all browsers supporting CSS3 transitions, on ones which don't the text will jump immediately to the alternate position.

Now, in the example above, the left property is always explicitly defined. What happens if you try to transition a property which isn't explicitly defined at the start of the transition?

The answer seems to be, "it depends on what browser you're using". More annoyingly, no browser does what I'd think would be the expected/preferred behaviour, namely to transition from the computed value to the new value. However, Opera and the WebKit browsers transition from a zero value to the target value, and Firefox 4.0 ignores the transition altogether, jumping straight to the target value.

I've coded an example that transitions the width of some text, as you might want if you had to make some space for a new element on the right hand side of the page. Unfortunately it doesn't play well within this blog, due to the use of position: fixed; breaking the layout, so instead you'll have to look at it via this link.

The somewhat crappy solution is to:

  1. Turn off transitions on the element you're going to change
  2. Explicitly set the CSS property to the computed value, a jQueryish example would be something like $("#my-element").css("width", $("#my-element").width()) + "px");
  3. Re-enable transitions on the element
  4. Change the property to the target value
Not too bad in simple isolated cases, but I wouldn't want to do that amount of faffing around on anything complex.

I haven't looked at the official CSS3 spec to see what - if anything - is the expected behaviour in this sort of scenario, but the fact that we have browsers doing different things indicates that someone needs to fix something.

Animation of newsprint reel change in SVG and JavaScript

Posted by John Smith on

Just been mucking around with SVG and JavaScript, and knocked out this fairly basic animation...

Something that's a tad annoying is that if you include an SVG file via an <img> tag, it doesn't seem to execute any JavaScript that it might contain - as such, I've had to resort to an <iframe> above. Whilst I can understand why an <img> isn't executed, it's mildly annoying - animated GIFs work, after all.

Just in case browser support does change, here's the SVG again, but this time pulled in as an <img>... SVG animation of the reel change process in a newspaper printing plant

Anyway, this is all well and good, but I imagine that >99% of the people who might view this will have no idea of what this is supposed to be. In brief (?), it's a very simplified side-on view of how paper is consumed in a newspaper printing press.

To avoid having to literally "stop the press", each press tower can hold two (or less commonly, three) reels of paper. One of these reels will be "webbed up", and unwinds the reel to feed the paper into the press. Note that these reels can weight between 500kg and two tonnes, with - very approximately - 20 kilometres of paper on them, which takes around 20 minutes to be consumed when a press is running at full tilt. (Bear in mind that I'm referring to the specifications of the presses and reels at a place I used to work, and other print sites are likely to differ considerably.)

As one is about to expire, the other moves into position to take over. There's some clever mechanical/electrical engineering magic involving double sided sticky tape (no joke) and automated cutters, which I'm not going to mention further, as I don't know enough about it to speak with any degree of accuracy. The finished reel drops down into a bin below, for later removal to a waste area, and a new reel takes its place.

The SVG/JS code is pretty hacky, and could do with a lot of improvement; however this was primarily for me to have a proper play with SVG for the first time, rather than to produce something "professional".

Helvetica is dangerous

Posted by John Smith on

For the past couple of months or so, I've been using the "Minefield" nightly builds of Firefox 4.0 rather than the "official" 3.6.x releases - 4.0 truly is an upgrade that merits the increment of the major version number.

It therefore came as a bit of a shock when I viewed this blog using 3.6.12 on my Mac - just about all the text was showing in an italic (or possibly oblique) typeface! My initial panic subsided when I confirmed that everything still looked as expected in every other browser, but this didn't get any closer to resolving the issue. Using Firefox's "Inspect Element" functionality gave no further clues, insisting that the text was in a regular font, despite the evidence in front of my eyes.

A quick hack-up of an HTML test file proved that I wasn't going insane, and that there is in fact a bug in Firefox 3.6:

Screen grab from Firefox 3.6 on Mac OS X, showing Helvetica text rendered at different font-weights.  The text at lower weights is italicized

Some cursory Googling didn't find any reports of exactly the same issue, but this thread (started by no less than Jeffrey Zeldman!) covers similar ground.

I did try explicitly setting the font to be Helvetica Neue Light, but it transpires that Firefox ignores this, and requires you to use font-weight, which as we've just seen is broken - thanks a bundle...

As the bug seems to have been around for a while, and is fixed in the 4.0 betas, I don't hold out much hope of it being rectified in the 3.6.x releases. As a workaround, I've fallen back to using Arial for the headings, as does work correctly with the lower font-weight values.

Historical revisionism

Posted by John Smith on

Oh look, The Guardian have changed the headline and subhead on the story I linked to in my previous post. It's now:

Rupert Murdoch creates 'iNewspaper' - with the help of Steve Jobs News Corp reportedly set to launch iPad news publication exclusively via download
which is certainly a more accurate - but less link-baiting - description of the story. That said, the piece itself doesn't appear to have been edited to reflect, this; as of midday on Monday 22nd November, the first paragraph of The Guardian piece reads:
Rupert Murdoch, head of the media giant News Corp, and Steve Jobs, the chief executive of Apple, are preparing to unveil a new digital "newspaper" called the Daily at the end of this month, according to reports in the US media.
which is still pushing things when you look at the original referenced article.

Whilst the article history does acknowledge a change has been made, it doesn't actually give any hint as to what the change was, it could just as easily have been some trivial typo fix.

Unfortunately for them though, their use of semantic URLs means that there's still visible evidence of their original intent - http://www.guardian.co.uk/technology/2010/nov/21/ipad-newspaper-steve-jobs-rupert-murdoch is a bit of a stretch from the new headline.

BTW, I'm not claiming this change was down in any way to my writings - having seen how many hits I (don't) get, I'm not under any illusions about the readership of this blog :-(

Don't believe everything you read (including this post)

Posted by John Smith on

The Guardian/Observer have just put up an article that at first glance makes one of my recent posts look pretty stupid.

Whereas I was disparaging newspaper execs belief that the iPad would be their saviour, according the Graun/Observer's headline:

iPad 'newspaper' created by Steve Jobs and Rupert Murdoch
Apple and News Corp reportedly set to launch joint iPad news publication exclusively via download

From that, and the following article, you might well think that Apple is as involved in this as News Corp.

However, if you go and dig out the original article - which is the sole attributed source for the Graun/Obs piece - you'll note that:

  • Steve Jobs isn't mentioned until the very final paragraph
  • Whilst it does say that Jobs and KRM have been in discussions, it shouldn't be any real surprise that two corporate moguls talk every now and again - and bear in mind that the Murdochs seem to be frequent guests aboard Larry Ellison's navy, yet I don't recall seeing any stories about Oracle and News Corp being close business partners
  • There's no mention of Apple having any involvement, any more than any of the thousands of other apps on the App Store

which gives a rather different impression.

The Daily project certainly exists, and it may well be that Steve Jobs has some sort of presence at its launch, but there's no evidence of any real Apple involvement at this point in time. I also have to wonder how strategic this project is - with a quoted headcount of just a hundred people, and more of an emphasis on light news and features than "serious" journalism, it seems more akin to the late UK freesheet TheLondonpaper than any of News Corp printed titles.

Blog restyling

Posted by John Smith on

Got bored with my initial styling attempts, so here's a new attempt that's inspired by

Hopefully it will strike a reasonable balance between being visually interesting and not being overly gaudy.

Still got a bit more fine-tuning to do - the gradients don't work in Opera (or IE I imagine) - but I want to get back to some "proper" coding now...

The iPad is not the saviour of the newspaper business

Posted by John Smith on

There've been a couple of bits of (IMHO) crazy talk from UK newspaper execs reported in the past couple of days, that I couldn't let go without adding my two-penneth.

First off we have James Murdoch proclaiming:

Our flagship newspaper products are now the iPad apps.

Yeah, and the Titanic was the flagship of the White Star Line.

We then have Sylvia Bailey piping in:

Bailey looked forward to platforms like tablets and Apple’s desktop app store, “without the design limitations of the web”.
and
I just can't see why a consumer would pay for something where they can get the same thing at as high a quality for free.

Now, I agree 100% with that last comment. Thing is though, the iPad newspaper/magazine apps I've seen so far [1] don't actually seem to be much of an advance from their website equivalents - and in some aspects, they can be inferior, such as how rapidly their content is updated:

Photos of The Telegraph's website and iPad app, taken 1:20pm on 2010/11/16.  The iPad app has no coverage of a story that broke earlier that day.

Whilst it's unfair to use a rival's products to critique someone's opinion, I think you'd be hard pushed to say that the Telegraph website shows has "design limitations" compared to their native app, quite the contrary in fact. Not to mention that if you're going to be comparing custom iOS (or Android for that matter) native apps to the web, then it'd be only fair to look at webpages built with CSS3, HTML5, AJAX, etc which aren't crippled by the need to support the likes of IE6.

Going back to the original JRM quote, surely the flagship product of a newspaper organization - for now at least - should be the newspaper itself? I haven't looked for recent figures for News International, but a couple of years ago, the printed product accounted for 85% of Guardian Media Group's revenues, and I'd be surprised if things are radically different now.

JRM talks about the "cannibalistic effect" of apps on the printed product, and I assume he's talking about that from a user/income point-of-view. But what about the "cannibalistic effect" internally? If your flagship is actually a niche product, then all the focus and attention it has taken away from the core business is more likely to accelerate than prevent your demise.

Not to mention, burning 20 million quid and several hundred man-years on these sorts of frivolities can't be healthy in an organization that's had to make fairly big cuts elsewhere.

Doubtless a year-or-so back, Steve Jobs did the rounds of all the big media conglomerates, using the notorious reality distortion field, to sell them on his "magic". Now, if you were in the desperate ruler of a declining kingdom, and a wizard came along saying that all of your problems would be solved if you had some of his magic beans, then it wouldn't be surprising that you bought into that fairy tale dream.

Personally, I'd be surprised if Steve Jobs has any more love in the interest in the publishing business than he does for the music industry. Selling the world a new type of device is/was a tall order, especially when apparently similar products had previously flopped. Who better to help spread the word than a desperate bunch seeking a saviour, but who still retain a good degree of influence and audience?

Footnote: I hasten to add, I've not actually spent much time with many iPad/iPhone newspaper/magazine apps. Those which I have seen I haven't found overly inspiring - they're either fairly basic text/image rendering that could be done just as well in HTML, or humongous archives of JPGs or PDFs pulled straight from the print version. I haven't checked The Times' Eureka app, which is supposedly quite good, but reeks of "mid '90s multimedia CD-ROM" to me, and we all know what happened to that line of electronic publishing...

Experimental rhythm action game using HTML5 video and Safari 3D CSS3 transforms

Posted by John Smith on

UPDATE: this is currently broken on my iPad, suspect it's iOS 4.2 related. I think I might be able to do a hacky fix, but I'm still working on it. It should work OK on regular Safari though.

It's probably not the most sensible thing in the world to publicize a >10MB video file that's being hosted on an Amazon EC2 'micro' instance, but let's see how long this lasts before I take it down to avoid too much damage to my credit card...

Photo of an iPad running the game

One of the things that surprised me when I got an iPad was that in Mobile Safari, embedded YouTube videos would play within the browser, rather than launching the standalone app as they do on the iPhone/iPod Touch. (Assuming that they've been embedded using the iframe method, rather than a Flash video.) This inspired me to start playing with HTML5 video, which previously hadn't struck me as that interesting.

Unfortunately, the embedding of YouTube video in an <iframe>, coupled with the way the underlying video file URLs are uniquely signed - presumably to inhibit hotlinking - means that it's difficult to impossible to have a lot of customized interaction with the YT video itself, but by hosting the video myself, I've able to build something really, simple but (hopefully) effective.

Anyway, at http://bit.ly/aRoq3V is a very basic rhythm action game. It's primarily aimed at the iPad, but will work acceptably on Mac/Windows Safari. Other browsers will have mixed results, as currently none of them support the 3D transformations added into WebKit's CSS, not even Chrome. The 3D stuff is super-simple, and could probably be 90% faked using regular CSS/JS/images, but as this is purely experimental, I've not been inclined to try. If this was a serious project, I'd probably do it in Objective-C, but I was really only interested in the HTML5/CSS3 aspects.

Tweet me to let me know how much you hate it...

Installing pywebsocket and samples on Fedora

Posted by John Smith on

I've been playing a bit with a Python implementation of WebSockets over the past couple of days, and whilst the documentation does cover everything, it's a bit uncentralized. Here are some of my notes about getting it up and running on Fedora 11 and 12...

Prerequisites

Browsers

Support for WebSockets across all browsers is still an issue, but I've tested this successfully with the following browsers as of :

  • Firefox 4.0 nightly build (Fedora, WinXP)
  • WebKit nightly (Fedora)
  • SRWare Iron 6.0.475 (WinXP)
  • Safari 5.0.2 (WinXP)
The following however didn't work:
  • SRWare Iron 5.0.382 (WinXP)
  • Firefox 3.6.10 (WinXP)
As far as I know, WebSockets functionality works equivalently across all operating systems, but I've indicated the specific configurations I've tried just in case.

The protocol has changed over time, I believe Opera and older versions of Chrome only support an older version, which can be made to work with this library according to the documentation, but which I haven't tried personally.

As I understand it, there are no plans for WebSockets to be supported in IE9 - surprise, surprise...

Server side packages

Although the download includes a standalone server, I've only used the module within Apache.

You need mod_python (Fedora package is similarly named) for mod_pywebsocket.

The Ruby and Wakachi sample applications use MeCab, a library for Japanese language handling. The Fedora packages needed are for that are:

  • python-mecab
  • mecab
  • mecab-ipadic
  • mecab-ipadic-EUCJP

mod_pywebsocket

The project page is http://code.google.com/p/pywebsocket/. The source can be checked out from Subversion via: svn checkout http://pywebsocket.googlecode.com/svn/trunk/ pywebsocket-read-only

To build and install the library, do the following: cd pywebsocket-read-only/src python setup.py build su {enter root password} python setup.py install {exit root session}

Verify that the module has been installed within your PYTHONPATH by importing it from an interactive Python session without errors: python import mod_pywebsocket {exit python session}

For the purposes of these tests, I created a new Apache configuration file, serving on port 8003. Create a file /etc/httpd/conf.d/websocket_test.conf with the following content, modifying the highlighted directory paths as appropriate: # An Apache config for the testing the pywebsocket samples # http://code.google.com/p/websocket-sample/ # Put this in /etc/httpd/conf.d and restart Apache # This line should be unnecessary # PythonPath "sys.path+['/websock_lib']" <IfModule python_module> PythonOption mod_pywebsocket.handler_root /proj/3rdparty/pywebsocket/websocket-sample-read-only/python PythonHeaderParserHandler mod_pywebsocket.headerparserhandler </IfModule> Listen 8003 NameVirtualHost *:8003 <VirtualHost *:8003> DocumentRoot /proj/3rdparty/pywebsocket/websocket-sample-read-only/html Options Indexes MultiViews FollowSymLinks ServerName pywebsocket.example.com ErrorLog logs/pywebsocket_error.log CustomLog logs/pywebsocket_access.log common ErrorDocument 404 /error.html </VirtualHost>

Restarting Apache will pick up this new configuration.

Samples

The sample applications are a separate project located at http://code.google.com/p/websocket-sample/. Checking out the code can be done via svn checkout http://websocket-sample.googlecode.com/svn/trunk/ websocket-sample-read-only

The count and litechat sample applications use local files to store state.

These files need to be made writable by the account that runs Apache:

  • python/pub/litechat/messages
  • python/pub/count/count
If you don't make this permission change, then you're liable to get the browser applications closing the connection prematurely, which initially made me think it was a problem on the client side rather than the server side.

These files need to be updated to reflect the location of the aforementioned files:

  • python/pub/litechat/do_wsh.py
  • python/pub/count/do_wsh.py
The path defined in the 'file' variable needs changing along these lines: diff do_wsh.py do_wsh.py.ORIG 86c86 < file = '/proj/3rdparty/pywebsocket/websocket-sample-read-only/python/pub/count/count' --- > file = '/home/komasshu/websock_handler/pub/count/count'

At this point you should hopefully be good to try the sample applications...

count

Shows the number of connected clients

litechat

A simple chat application where you enter a message to broadcast to the other connected clients.

ruby and wakachi

These are a bit more complicated to understand, as they assume you know something about how the Japanese language works.

Japanese is normally written without any spaces between words. The wakachi demo processes some sample text, putting spaces between the words.

Japanese also has 3 alphabets. Two of them are syllabic in nature - the symbol/ideograph directly indicates how it should be pronounced. However kanji can have multiple ways of being read. Ruby characters are kana which can be printed alongside the kanji in a smaller font to indicate the correct pronunciation. The ruby demo takes the same regular Japanese text, processing it to add these ruby characters where needed.

I should point out that I wasn't able to get the XHR functionality of these two applications to work - the Apache logs showed 404 errors. As the point of these applications is to show WebSockets in action, I didn't bother investigating what the problem was with the XHR stuff.

So the majority of web video is available in HTML5? Not from where I'm sitting

Posted by John Smith on

A recent survey that says "54% of web video is now available for playback in HTML5" has been widely reported in the past couple days. From that figure, one might think that those of us who prefer not to install Flash on our computers can now watch more skateboarding dogs than we can shake a stick at.

However, a quick test of some of the sites mentioned in that survey tells a somewhat different story...

blip.tv

Screen grab of Firefox 4 browser being told by blip.tv that Flash is required to video their video content

Dailymotion

Screen grab of Firefox 4 browser showing a black rectangle rather than a video

Vimeo

Screen grab of Firefox 4 browser being told by Vimeo that Flash is required to video their video content

YouTube

Screen grab of Firefox 4 browser being told by YouTube that Flash is required to video their video content

The above tests were done on a Fedora 12 machine running the nightly Firefox 4 beta (aka Minefield), which is quite capable of running videos such as the one at html5video.org.

I've yet to do a more thorough investigation as to what's happening with these sites, but one or more of the following seem possible:

  • By default, they all assume anyone visiting from a desktop browser will have Flash installed. There's definitely a strong feeling out there that you only need to provide Flash-free versions of sites for mobile devices, like this for example.
  • HTML5 video is only offered if a user explicitly requests it. Last time I checked, on YouTube you had to explicitly go to a page which gave you a cookie to enter their HTML5 "beta". Although if you do have to jump through such hoops, why don't these sites provide a link to the relevant page to set the options, rather than merely linking to Adobe's download page?
  • The sites only have the video in H.264 format. They detect that Minefield doesn't have a plug-in to handle it, and so don't offer any HTML5 video. If so, does this merely mean that we're replacing Adobe with MPEG-LA as the overlord of online video content - in which case, I'm not actually sure that's a positive step. The original report does mention H.264, but perhaps any follow-up survey should go further, and break HTML5 video availability into the stats for how much H.264 vs OGV vs WebM are all supported?
  • The sites don't recognize Minefield 's User-Agent string, and so don't realize it can handle HTML5 video, and just fall back to the perceived lowest common denominator. (I don't think this is likely, but it's possible.)

Based on this sort of thing, I don't see Flash video going away any time soon...

« Page 5 / 6 »

About this blog

This blog (mostly) covers technology and software development.

Note: I've recently ported the content from my old blog hosted on Google App Engine using some custom code I wrote, to a static site built using Pelican. I've put in place various URL manipulation rules in the webserver config to try to support the old URLs, but it's likely that I've missed some (probably meta ones related to pagination or tagging), so apologies for any 404 errors that you get served.

RSS icon, courtesy of www.feedicons.com RSS feed for this blog

About the author

I'm a software developer who's worked with a variety of platforms and technologies over the past couple of decades, but for the past 7 or so years I've focussed on web development. Whilst I've always nominally been a "full-stack" developer, I feel more attachment to the back-end side of things.

I'm a web developer for a London-based equities exchange. I've worked at organizations such as News Corporation and Google and BATS Global Markets. Projects I've been involved in have been covered in outlets such as The Guardian, The Telegraph, the Financial Times, The Register and TechCrunch.

Twitter | LinkedIn | GitHub | My CV | Mail

Popular tags

Other sites I've built or been involved with

Work

Most of these have changed quite a bit since my involvement in them...

Personal/fun/experimentation