jPlayer 2.0.20 preview and the Pink Flag skin

[Mark Panaghiston]

Since it will probably be another week or two before the jPlayer 2.1.0 is ready for release, I wanted to give users of the jPlayer group a preview of the current state of the development.

The following link comes with some disclaimers...

Only the (new) Pink Flag skin is working correctly. (I will be addressing the Blue Monday skin next.) Also, the video play button still needs some work for the full screen mode. The full screen feature does not work in IE6 as the CSS does not work.

Only the demos are there. There are no docs on how to use it. To gleam any form of docs, you'll need to read the patch notes in the main jPlayer 2.0.0 dev thread:
https://groups.google.com/d/topic/jplayer/rdWPvU4GpB8/discussion

Be careful navigating around... This section is not part of the main site, but the main site template is being used so you will pop back to 2.0.0 if you are not careful.

The CSS and HTML will change before jPlayer enters 2.1. So use this with caution. The video play button needs to work in a different way and I expect its structure will change in the HTML and CSS.

Remember that in Firefox when the Flash is being used, the flash will reset when changing the video screen mode. Playback should resume when changing modes after a brief silence. An old Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=90268 causes this, but it looks like they have a fix coming out soon.

This is a temporary area and will be removed when jPlayer 2.1 is released.

http://jplayer.org/2.0.20/demos/

I put the demos in a zip for ease:
http://jplayer.org/2.0.20/jQuery.jPlayer.2.0.20.demos.zip

The demo file postfix -pf is for Pink Flag, -bm for Blue Monday.
(Yes, I generate all the files from a script. I did not make all the broken Blue Monday ones for you with TLC.)

Best regards,
Mark P.

[Mark Panaghiston]

After a huge effort on the CSS... We now have Blue Monday and Pink Flag working well on standard browsers and IE7+. IE6 degrades to a usable state when you try and full screen it.

There is still a little bit to work out, like the loop and shuffle buttons on the Blue Monday playlist version, but on the whole there are ready.

Now for the major downer... They do not work at all on iOS in Full Screen mode. Reviewing other HTML5 players, they simply lie about the skin-able bit for iOS and slap in the default controls. Maybe that would be the best solution since all those we reviewed did so.

The BlackBerry PlayBook works fine with our CSS.

http://jplayer.org/2.0.22/demos/

http://jplayer.org/2.0.22/jQuery.jPlayer.2.0.22.demos.zip

After all the stuff we through at the browser during our Radiolab demo, which worked on iOS, I had thought that iOS would work... But iOS does not work with the position:fixed CSS rule.

Maboa and I are considering options right now...

Your suggestions are welcome.

Best regards,
Mark P.

[Mark Panaghiston]

After our discussion last night and today, we are currently considering 2 paths:

1) First we feature sniff whether the position:fixed is supported by the browser.
Then we have an option that basically is a boolean stating whether you must have full screen capability.
If position:fixed is not supported, then the default controls are used and the jPlayer GUI is hidden.
This gets a little woolly with IE6, which really only needs the full screen button and the option disabled.

2) We sniff device platforms and have a bunch of options for each. These could be condensed into a set for mobile phones and tablet device to limit the options to reasonable amount. Then if the iPad is used, the option are checked to see if you want to use the nativeControls or just hide/disable the fullscreen button/option.
If we did it this way, I should be able to add an option for the volume controls too, as iOS ignores those controls.

The issues...

iOS5 supports position:fixed... Well that is the claim. My simple mock-up that I have used to develop the skins seems to work in iOS5, but the skins themselves do not work when used in the jplayer.org page template. This would suggest that iOS5 has limited support for position:fixed.

The position:fixed feature detector will need to work with iOS in general. Currently, I have not found code that detects this correctly, but that does not mean it is not possible. We have got some input through twitter that might help for this case.

Browser sniffing... Or probably even worse, platform sniffing is certainly not fashionable and generally should be avoided and only used as a last resort.

[Mark Panaghiston]

During my testing it has become obvious that the current skin CSS is dependant on the jPlayer site page template and its CSS.

This boils down to a few margin errors in Blue Monday.

Pink Flag has some bigger problems with the audio player version, but the video skin seems fine.

To see what I mean... use the display=min url query param.
http://jplayer.org/2.0.22/demo-02/?display=min&theme=1

[Mark Panaghiston]

Apparently I was off my game yesterday when I put that (2.0.22) online...

The primary reason for the pink flag audio players not working was that I missed the class jp-interface off the same node as the jp-gui.
There is still a minor issue with the pink flag CSS on ie6. The video progress bar has too much height.

The Blue Monday issue boiled down to a margin:0 on the ul.jp-controls.

Explanation of the jp-gui and jp-interface classes... The jp-gui class is on the element that holds the GUI. The video player has the jp-video-play and jp-interface elements in the jp-gui. This allows the jp-gui element to be shown and hidden with autohide. The audio player does not really need the jp-gui class at all, as it is the same element as the jp-interface. The jp-interface class is really for defining all the CSS rules.

[Mark Panaghiston]

This is the current CSS for the Blue Monday and Pink Flag skins for jPlayer 2.0.23

http://jplayer.org/2.0.23/demos/

http://jplayer.org/2.0.23/jQuery.jPlayer.2.0.23.demos.zip

The skins work in all modern standard browsers and IE7/8.

IE6 cannot support full screen mode without a major frig, so instead it degrades to 270p video size, however the GUI grows to match the video size which is not desired, but I'm buggered if I know how to make the CSS work nicely with this old browser without screwing up all the modern ones. Regardless, we intend to disable the full screen button and option in IE6 so this should not be an issue.

The full screen mode on mobile browsers is still under investigation.
The BlackBerry PlayBook works fine.
iOS4 cannot work. It would need to use either the native controls or to have the full screen button and option disabled.
iOS5 should work. The iOS5 beta 3 emulator works when the skins are the only thing on the page, however, when the jPlayer skin is added to the jplayer.org template, the full screen mode no longer works.

You can see for yourself on the iOS5 beta 3 iPad using the URL query parameters display=min on any of the demos. For example:
http://jplayer.org/2.0.23/demo-01-video/?theme=0&display=min

There also appears to be an issue with detecting the mouse move over the video on the iOS5 iPad... However, this is rather difficult to test with the emulator and all I know is that clicks on the video area do not register a mousemove event. iOS4 does detect it. Also, going back and then forward in the browser seems to make the mouse move events work again... Sometimes.

I have reported this to Apple and will do a little more investigation in the hope of finding the actual position:fixed bug and reporting the bug properly... Rather than a vague "This site don't work in iOS5".

Testing on Android has been limited. On the Android 2.3 phone I have for testing, the CSS works. Even the CSS for full screen seems to work in Android, but that mode is kinda pointless as the video plays full screen anyway on the phones. Like with the video on the iPhone/iPad. Ah, the position:fixed is not actually working in Android, if you scroll down the page, it wanders off the top.

That's today's update.

[Mark Panaghiston]

Here is an update to the current development...

In order to solve the problem where we want some mobile devices to use their native controls, a blocklist has been developed that is basically a list of regular expressions that are tested on the user agent string. If the test is matched, then the native controls are used.

Using the native controls has thrown up a number of problems on some mobile devices. In the first instance, the controls are sometimes hidden for some unknown reason. Investigation has led us to believe that the clearMedia operation that occurs when setMedia is used, is what causes the problem. The clearMedia within the setMedia command was always something that I did not like. It was there for the rare situation where old media was still downloading when the media changed AND the new media is NOT played. I have not seen any examples of people ever using jPlayer in this way.

Another item under review is the use of the mediaElement.load() command when the media is changed. This ccommand is no longer necessary under the W3C spec, as simply changing the SRC now does this for you. As in, the new SRC is read in when it changes, rather than waiting for the load() command. The problem here is that the HTML5 spec has evolved over the past year or so and older HTML5 browser will require the load() command, otherwise the new SRC is simply ignored.

Apart from juggling the old and new spec so that all are satisfied, we also have to consider that when the native controls are used, the commands like jPlayer("play") are not used. The native controls have their own play button. This means that we cannot simply move the load() command to the play() command, as the native controls would never use it.

Incidentally, this explains why some browsers, such as chrome, load the entire media when setMedia with preload != "none" in jPlayer at the moment... Because that is what it should do when you tell it to load.

So we have a decision to make... Follow the spec, and break browsers like Firefox 3.6, or deal with all the old spec too and have a solution that works in both... But has some quirks because we are adding commands that are no longer necessary.

In my opinion, we cannot break the older HTML5 browser. Just because someone uses a non IE browser, does not mean they bother to upgrade. I understand that 8% of web users still use Firefox 3.6 in the last month. (So Maboa warned me.) I believe that Firefox plan to force you to update soon, like Chrome does. Safari and Opera both prompt you for the upgrade often enough, once they are available.

Enough of my waffle... Back to testing and seeing which parts I need to change in order to get the new features to work, while maintaining support for older HTML5 browsers.

[Wintours]

Hi Mark,

Many thanks for all your work on JPlayer and the new version - it looks great!  I would like to adapt the Pink Flag skin to better fit with my color scheme and therefore wondered if the PSD is available for download anywhere? If not, would you be happy to make it available?

Thanks again,

Wintours

[Mark Panaghiston]

I'll make the pink flag PSD available when 2.1 is released.

I'll review them and add the PSD to any interim releases. The final features of 2.1 make me want to throttle someone. Especially the person who changed the operation of .load() in the spec all that time ago. Now we have a bunch of older HTML5 browsers that need it, while all the new HTML5 browsers would prefer it never happened at all.

If only every browser insisted on being updated like Chrome does. By far, that is the best thing I like about the Chrome browser.

It is just crazy for IE6/7/8 to work fine, but for Firefox 3.5 and 3.6 to fail because the spec changed and the user does not update the browser... To Firefox 5.

Just grumbling... I'm going to keep jPlayer supporting the obsolete HTML5 browsers for the time being. It just means that the browsers that do follow the spec will actually load the media at times when they should not... Like Chrome and Safari do already in jPlayer 2.0.0 when you give a setMedia with preload != "none".

[Wintours]

Thanks Mark - will look forward to the new PSD.

The issue regarding old / new HTML5 browsers is indeed a pain. Something you might like to know regarding usage of Firefox 3.6 is that there are likely to be a lot of Mac users (myself included) still using 3.6 because they are simply unable to upgrade to Firefox 4 or 5. This affects all Mac users with 'PowerPC' processors - because Firefox 4 and up will not run on PowerPC's Macs. Although the newer processor architecture for Macs (Intel processors) came out 5 years ago there are still a lot of folks unwilling to replace their PowerPC macs (some of which may be only just over 5 years old) because they cost them a lot of £ and still work perfectly!  So, there are perhaps rather more people that you realised who will be greatful that you are planning to continue support for the older HTML5 browsers!

Your efforts are much appreciated.

Wintours

[Mark Panaghiston]

Ah ok. I did wonder why so many people still used Firefox 3.6. That helps explain it.

[Vebel]

Hi Mark,

Any news about the availability of the Pink Flag PSD file - I would really like to make a Red/White/Black version, but need the original PSD file to do so. If I can get the PSD file I will make the new Red/Black skin file available to others, when finished.

Thanks
Lise

[DtM]

I found the PSD :  http://www.proleiloes.com/jplayer/css/pink.flag/ 

[Steve Wehr]

Looks like that link is no longer any good. Any ideas where I could find the pink.flag skin .PSD file??