Why the HTML5 ‘Video’ Element Is Effectively Unusable • Hacker News Board

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#21

Post by aw3c2 » Mon, Dec 21, 2009, 10:03 PM UTC

DarkShikari wrote: post #3

Another flaw in the spec is that it provides no means to specify client buffering behavior: you cannot tell the client how many seconds to buffer before playback. This completely breaks the buffering model inherent in modern video compression systems and basically only works properly at all if the users' connection is far higher than the bitrate of the video. Until HTML5 has basic feature parity with Flash's video ca…

Your constant Theora bashing is so wrong. H264 is patented, patents are bad, Theora seems the best alternative. Get over it.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#22

Post by youngian » Mon, Dec 21, 2009, 10:05 PM UTC

IgorPartola wrote: post #11

SecurityMatters wrote: post #10

The author demonstrated why Firefox, et al, made the correct choice on his example page. I visited his page using Firefox and the video would not play. My guess is that you need javascript turned on to play the videos on his site. I almost never enable javascript, and certainly would not do so just to watch a little video. It sounds like Firefox and others are trying to make the web pages more universally work.

I am sorry but that is insane. Today's web relies heavily on JavaScript. I recommend you get yourself a clean browser (maybe on a virtual machine), if you are paranoid about security (SecurityMatters huh?), and try using Google Maps, Google Calendar, et al.

Turning off Javascript is not insane. JS opens you up to a wide range of possible security problems. Also, you can think of it ideologically - websites should still work with JS turned off. Building an accessible, semantic, well-formed website means building a website that works without Javascript.

The only exceptions are Google Maps or anything equally as rich. And I do mean equally as rich.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#23

Post by generalk » Mon, Dec 21, 2009, 10:06 PM UTC

How does the title call out the video element as "effectively unusable" when in the end Gruber actually crafts a page that works with the video element?

Sure, no client respects the autobuffer attribute, and there's no way to use a poster image without resorting to javascript, and you have to encode the video two different ways. But it still works. It works even if you stick to one format (you're just excluding clients) or don't play the javascript-dom-switchout game (the video autobuffers, you don't get a poster image at all).

Better title: HTML5 Video Element Has Glaring Issues, but Usable.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#24

Post by rimantas » Mon, Dec 21, 2009, 10:08 PM UTC

youngian wrote: post #22

IgorPartola wrote: post #11

Earlier quoted context omitted.

I am sorry but that is insane. Today's web relies heavily on JavaScript. I recommend you get yourself a clean browser (maybe on a virtual machine), if you are paranoid about security (SecurityMatters huh?), and try using Google Maps, Google Calendar, et al.

Turning off Javascript is not insane. JS opens you up to a wide range of possible security problems. Also, you can think of it ideologically - websites should still work with JS turned off. Building an accessible, semantic, well-formed website means building a website that works without Javascript. The only exceptions are Google Maps or anything equally as rich. And I do mean equally as rich.

You know, times has changed recently. Now we have not only web sites, but the web apps too. And there different rules apply.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#25

Post by briansmith » Mon, Dec 21, 2009, 10:08 PM UTC

"As for why I refuse to embed Flash, let me put it this way. I use and highly recommend ClickToFlash, which blocks all Flash content by default. Why would I publish content using a technology that I personally block by default?"

Soon you will be blocking and by default too, for the same reasons.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#26

Post by DarkShikari » Mon, Dec 21, 2009, 10:09 PM UTC

windsurfer wrote: post #19

tumult wrote: post #9

Earlier quoted context omitted.

Then it probably doesn't work with ogg :) I personally think it's a huge mistake for Firefox to support only ogg. It's a bad time for fragmentation in the push for open video on the web. It should still be possible to get a rough estimate for when to start playback. Good enough for buffered autoplay.

How can Firefox distribute the H.264 codecs without infringing on patents?

How do Linux distributions distribute H.264 and AAC decoders? Debian does, Ubuntu does, Fedora does, basically everything in the world except GNUsense does--yet they do just fine with themselves.

The best solution would be to simply use system decoders, like Safari does. On Windows, this would be Directshow, on Linux this would be Gstreamer, and on OS X this would be Quicktime. The browser should have ABSOLUTELY NOTHING to do with video and audio decoding.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#27

Post by DarkShikari » Mon, Dec 21, 2009, 10:14 PM UTC

aw3c2 wrote: post #21

DarkShikari wrote: post #3

Another flaw in the spec is that it provides no means to specify client buffering behavior: you cannot tell the client how many seconds to buffer before playback. This completely breaks the buffering model inherent in modern video compression systems and basically only works properly at all if the users' connection is far higher than the bitrate of the video. Until HTML5 has basic feature parity with Flash's video ca…

Your constant Theora bashing is so wrong. H264 is patented, patents are bad, Theora seems the best alternative. Get over it.

When did I bash Theora?

There's a lot wrong with Theora, but it's irrelevant to the discussion: what matters is what people actually use. If today it came up that there was a big patent on JPEG, would you propose that the entire web stop using JPEG tomorrow?

No matter how good or bad Theora is, the internet will not simply drop the existing standard formats and switch. It doesn't work that way.

This is also why browsers should use system decoders: it would make it easier to use a different video or audio format, since one could use anything that people had decoders installed for. This would stop the internet from being locked into a single format.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#28

Post by youngian » Mon, Dec 21, 2009, 10:19 PM UTC

rimantas wrote: post #24

youngian wrote: post #22

Earlier quoted context omitted.

Turning off Javascript is not insane. JS opens you up to a wide range of possible security problems. Also, you can think of it ideologically - websites should still work with JS turned off. Building an accessible, semantic, well-formed website means building a website that works without Javascript. The only exceptions are Google Maps or anything equally as rich. And I do mean equally as rich.

You know, times has changed recently. Now we have not only web sites, but the web apps too. And there different rules apply.

Yes, and the vast majority of web apps boil down to forms with some flashy bits added. I'm not saying the flashy bits aren't nice, but you should build your forms in such a way that they still work without Javascript.

Like I said, Google Maps is my yardstick - anything less complicated than that should be built to work without Javascript. It might work slightly different and be a little less pretty, but there's no reason it can't work.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#29

Post by pohl » Mon, Dec 21, 2009, 10:22 PM UTC

generalk wrote: post #23

How does the title call out the video element as "effectively unusable" when in the end Gruber actually crafts a page that works with the video element? Sure, no client respects the autobuffer attribute, and there's no way to use a poster image without resorting to javascript, and you have to encode the video two different ways. But it still works. It works even if you stick to one format (you're just excluding clien…

If you look up "effectively" in the dictionary, it means "in such a manner as to achieve a desired result". The author highlights the desired result of requiring the user to click on the poster before buffering is allowed to begin. He currently cannot achieve the result he desires. The title makes sense to me.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#30

Post by newhouseb » Mon, Dec 21, 2009, 10:24 PM UTC

Slightly related: the HTML5 'Audio' element is also effectively unusable.

I was building choreographi.es (http://choreographi.es) a while back and was using the JPlayer plugin for JQuery, which attempts to use HTML5 audio and then falls back on Flash for platforms which don't support it.

The gist of my app was that I needed to match movements _exactly_ to specific offsets in the music. Between Safari and Firefox, Firefox was dead on, while Safari randomly appeared to skew as it started playing from different points in the music, just enough to be significant. I'd imagine it was some bug in counting sampling rate. In the end I had to crack open the JPlayer code and force Flash all the time.

TL;DR Moral of the story? It's hard to expect implementation to be perfect for a not-yet-finished standard, but until then, someone (you/me/us?) needs to make the equivalent of a community quirksmode combined with automatic bug submission to the relevant engine so we can get on with our lives.