Performance: Profiling how different web sites use browser subsystems

re: Performance: Profiling how different web sites use browser subsystems

Giuseppe — Mon, 13 Sep 2010 13:23:18 GMT

@Shiv Kumar 12 Sep 2010 9:24 PM

sorry, i didnt mean to insult you, neither did i intend to 'show how smart i am' (because i am not). i wanted to be concise. still i thought i added value. maybe i failed. and i should have mentioned that i examined the player from a user's point of view, rather than a developer's. finally i should have pointed out that the rest of the player, the whole site and also the 1.5 short movies i watched are very nice, but i didnt want to have nested off-topics for brevity's sake.

but let me try again:

"we have a fully functional html 5 player that will work across all browsers, supported pretty much all the features one would expect in a video player"

a visitor that loads your page does not get an error message or fallback when his browser does not support the video element. it silently fails, and visitors usually dont like this. I am, and was, aware that switching to the html5 video player had to done explicitely by the visitor, but what i wanted to imply (and should have done in a more clear and friendly way) is that a "fully functional html5 player" should provide some kind of fallback. no piece of software should fail silently.

"fullscreen"

i did not rate the practicality of the spec concerning fullscreen to stay more objective. of course, fullscreen is absolutely necessary for video content. personally i favor safari's approach, but only the 'right click' triggering of fullscreen complies to the spec in its current state. i would like to see the spec changed towards allowing the safari way, but i cannot demand so due lack of insight on the security implications (can a user be tricked into clicking the 'button'? can the 'button' be styled (see input[@type='file'])? etc.).

maybe i should have applied common sense and used safari until other browsers follow their way of even the spec is changed, but again, a regular visitor would not know about the fullscreen case, and thus get unexpected result.

"It implies that either you can't build your own skin/player or they expect users to right-click to get access to the option"

that's where we are today. but the user could be informed about the right-click possibility (like 'press escape to exit fullscreen' seen on some flash video players). And/or you could inform the user how to enable the browser's fullscreen mode (e.g. F11).

"hide scrollbars" and "fixed positioning"

i thought by this, as by the former suggestions, you could improve your html5 video player. and to introduce a tiny bit of criticism, i really don't see how that was pointless. however, i should have expressed myself more clearly and polite.

peace,

re: Performance: Profiling how different web sites use browser subsystems

Shiv Kumar — Mon, 13 Sep 2010 04:24:36 GMT

@giuseppe

Rather than waste bandwidth with you pointless comments, I'd ask that you add value to this conversation (if you have anything of value to add that is).

The player is fully functional in all major browsers. Yes, I should have been clear about that means. However, one would assume if the browser in question does not support the html 5 video element completely, then testing with it would be a moot point, no? I mean a little bit of common sense is all it takes, so I suggest you use it, why don't you? May I suggest using the beta version of Firefox since it's support for the html 5 video element at this time is more complete?

Full screen:

The spec? Man, what a joke! It's not about the specs. Since when have specs met all the requirements? And certainly, the Html 5 video specs lack badly in this regard. Again, the idea is that one can go full screen. So a little bit of common sense will go a long way.

Now as regards the specs on the Full Screen aspect. Read it and you'll soon discover that the spec the way it is, is useless. It implies that either you can't build your own skin/player or they expect users to right-click to get access to the option. The issue with that is that most video websites would want to have their own player and most users won't think to right-click to get the full screen option. Besides, most websites will block the right click option anyway.

Safari has gone against the so called "spec" and provided a programmable interface that they in turn ensure has been called using a user gesture. Oh, and guess what, we use it too.

Keep in mind that the reason we have the mess that we do as regards browsers and meeting specs is that the specs have never been enough. They’ve never addressed the real needs and they’ve not been explicit enough when that needed to.

Another “spec” joke is the poster attribute for the video element. It’s completely useless. So much so that any website that has implemented their own Html 5 video player doesn’t use it. Or they have to find other in order to be able to use it like not setting the source of the video element so the poster doesn’t vanish after about half a second.

Oh, and if it's all about showing how smart you are, then yes, please have the last word.

re: Performance: Profiling how different web sites use browser subsystems

giuseppe — Sat, 04 Sep 2010 20:20:06 GMT

@ jabcreations (30 Aug 2010 6:52 PM)

i totally agree

@ Shiv Kumar (30 Aug 2010 8:40 PM)

OT:

"we have a fully functional html 5 player that will work across all browsers, supported pretty much all the features one would expect in a video player"

I wonder why it silently fails in firefox 3.6.

And "all browsers" is an inclompletely defined set.

"1. Full screen"

No. No fullscreen as suggested by spec. That's probably why your player doesn't have fullscreen. As I am sure you already knew that, I wonder why you wrote something different. Maybe you should review your advertising text.

However, you could hide the scrollbar(s) of the containing page while in 'fullwindow' mode, and hint the user to how to toggle browser fullscreen mode. Oh, and fixed positioning for the maximized player would seem like a good idea to me.

re: Performance: Profiling how different web sites use browser subsystems

impact crusher — Thu, 02 Sep 2010 03:25:14 GMT

thanks.I need it.

re: Performance: Profiling how different web sites use browser subsystems

hAl — Wed, 01 Sep 2010 12:56:34 GMT

@ Shiv Kumar

Using WebM would make a lot of people unhappy.

It uses more significantly bandwith for the same video. Especially anoying is you have a limited 3G subscription.

re: Performance: Profiling how different web sites use browser subsystems

Harry Richter — Wed, 01 Sep 2010 08:29:46 GMT

@ Drake92

If you like pie charts or bar charts, that is a matter of personal preferencies. Having said that, the pie charts in this article are NOT wrong, as they are in order of occurence, , starting as you've said at 0 degrees, continuing clockwise, which makes much more sense.

Cheers

Harry

re: Performance: Profiling how different web sites use browser subsystems

AM — Tue, 31 Aug 2010 19:04:13 GMT

This is a nice article, it will be really nice if the developer tools in the new IE9 can build the same chart, or at least give the time for each layer; this will help many developers improve their web applications.

It reminds me of “Show execution plan in SQL server” :-)

re: Performance: Profiling how different web sites use browser subsystems

MisterW — Tue, 31 Aug 2010 17:18:58 GMT

What about the real world of the future? IE, being the browser with the largest market share, controls to some extend how the future web applications will look like, so IE should improve on all fronts, even on those which don't play a big role on current web sites.

re: Performance: Profiling how different web sites use browser subsystems

Drake92 — Tue, 31 Aug 2010 17:18:04 GMT

Pie charts are wrong. Should start at 0 degrees with highest percentage item first, then go around clockwise in descending order. Let's hope more attention was paid to the browser's development!

re: Performance: Profiling how different web sites use browser subsystems

Ryan — Tue, 31 Aug 2010 17:03:46 GMT

Can you guys explain what 'rendering' is and how it's affected? What affects rendering time? Too many DOM nodes? Too many CSS rules? JavaScript changing the page before load?