Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why the HTML5 ‘Video’ Element Is Effectively Unusable

daringfireball.net

Post reply on HN
Print view View original

41–50 of 80 posts

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

#41

Post by bphogan »

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.

There are a lot of web application developers out there don't have a clue how to build accessible web applications. JS is not required to log in to sites, nor is it required to send data back to the server. But devs do it because they see other sites do it, and rather than learn how to do it the right way, they just do it the way they see how. Blind and low-vision users disable JS too, because it prevents popups from taking focus, and prevents mouseover events that can also mess with people who have motor impairments.

Javascript is a great way to enhance the user experience, but you are being irresponsible if you develop sites that only work with JS enabled. It's seriously not that hard. Make it work first, then detect xhr on the server to add the nice partial updates, etc. And don't tell me it costs more money to do that. If it does, you designed it wrong or chose tools that are inherently inaccessible. In both cases the blame falls on you.

Full disclosure; I am a low-vision web application developer, born with congenital cataracts, along with my father and my daughter. Developers who use the excuse of "you have to have JS on for my stuff to work" make me incredibly angry, so I tried to keep this as civil as possible.

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

#42

Post by cpearce »

Unfortunately John is entirely wrong, about Firefox at least. Firefox does not buffer the entire media when autobuffer is not present. I don't know how he came to that conclusion, but just check out this page as an example:

http://pearce.org.nz/video/bunny-poster.html

Note that the progress bar on the controls does not turn to a lighter shade of gray until you press play - this means Firefox isn't buffering data unless you press play.

John's blog post is wrong.

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

#43

Post by bphogan »

prodigal_erik wrote: post #32
youngian wrote: post #28

Earlier quoted context omitted.

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 re…

Google Maps is of course less interactive and shiny but still works fine without js. I'm dismayed that we don't routinely expect all web developers to be similarly talented and thorough. http://maps.google.com/maps?f=q&source=s_q&output=ht...

Thank you so much for pointing this out. I agree completely with this. It's hard enough being a low vision user without having other developers falsely assert that you must have JS turned on to use "the new internet".

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

#44

Post by latortuga »

cpearce wrote: post #42

Unfortunately John is entirely wrong, about Firefox at least. Firefox does not buffer the entire media when autobuffer is not present. I don't know how he came to that conclusion, but just check out this page as an example: http://pearce.org.nz/video/bunny-poster.html Note that the progress bar on the controls does not turn to a lighter shade of gray until you press play - this means Firefox isn't buffering data unle…

You may be correct for Firefox but on the latest Chrome beta, my progress bar looks blue both before and after I press the play button - there is no indication to me as to whether it is buffering or waiting for input.

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

#45

Post by latortuga »

pohl wrote: post #29
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.

As a result of his rather drawn out explanation, however, it appears as though he can achieve the result he desires, just not as simply as he would like and in a manner he'd rather make fun of than use. I understand complaining that about the lack of a feature that everyone seems to agree is decent and desirable, not to mention spelled out in the specification but it is not relevant to that specific discussion to complain that "you can't do X" when you can in fact do X.

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

#46

Post by windsurfer »

DarkShikari wrote: post #26
windsurfer wrote: post #19

Earlier quoted context omitted.

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 NOTH…

We've had that kind of "standard" for embedding movies for years. The only reason you don't know that is due to it's unpopularity.

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

#47

Post by wmf »

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?

They could take their mountain of cash and pay the licensing fee like Chrome does.

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

#48

Post by telemachos »

latortuga wrote: post #44
cpearce wrote: post #42

Unfortunately John is entirely wrong, about Firefox at least. Firefox does not buffer the entire media when autobuffer is not present. I don't know how he came to that conclusion, but just check out this page as an example: http://pearce.org.nz/video/bunny-poster.html Note that the progress bar on the controls does not turn to a lighter shade of gray until you press play - this means Firefox isn't buffering data unle…

You may be correct for Firefox but on the latest Chrome beta, my progress bar looks blue both before and after I press the play button - there is no indication to me as to whether it is buffering or waiting for input.

I'm on yesterday's Chromium build on a Mac, and here was my test. Go to the page, don't click, wait, wait some more, keep waiting, wait, some more wait. Then, try to drag the video to the half-way point and start play from there.

Result? The video jumps back to the beginning of the play cycle. Thus, I deduce, it ain't loading. Firefox 3.5 here, no autobuffer. Safari does as Gruber says and starts loading immediately.

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

#49

Post by wmf »

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…

you cannot tell the client how many seconds to buffer before playback. This completely breaks the buffering model inherent in modern video compression systems

My understanding is that HTML5 browsers will attempt to buffer as much as possible; is there any reason you'd want less buffering?

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

#50

Post by DenisM »

wmf wrote: post #49
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…

you cannot tell the client how many seconds to buffer before playback. This completely breaks the buffering model inherent in modern video compression systems My understanding is that HTML5 browsers will attempt to buffer as much as possible; is there any reason you'd want less buffering?

So that playback starts quicker?
Post reply on HN