It is possible for someone other than the patent holder to use patented tech you know?
Yes, but only with permission. In the case of H.264, Mozilla could buy a license, but then anyone who wants to roll their own version of Firefox has to pay for a separate license.
No it wouldn't, it would simply shift it somewhere else.
Indeed. It would shift it to the OSes, and both Windows and OS X already license H.264, among others. Even Ubuntu looks likely to do so. There's also the Fluendo codecs, among others.
It also makes it technically possible for the individual user to violate the patent by downloading unlicensed implementations, like those found in medibuntu. If you don't like patents, that's a much better scenario than simply asking Mozilla to do it -- the MPEG-LA can sue Mozilla out of existence, but they can't sue every Linux user out of existence, especially when some people will buy Fluendo codecs.
Any way you slice it, this puts that "burden" in a much more manageable place. If I'm running Windows, I already have an H.264 license -- why shouldn't I be able to use it in Firefox? Does Mozilla really want to force me to only use it in IE?
Of course you really don't understand patents in the first place
Ad-hom based on less than two paragraphs out of me. That's hardly fair, wouldn't you say?
Yes, I've seen that, and I don't really see the point. The biggest privacy concerns in Chrome itself -- Chrome, not Chromium -- can be dealt with by un-ticking a checkbox or two in options.
As the summary said: There are only two countries in the world with software patents. TWO.
They're big enough that it would really suck if Firefox couldn't be distributed in those countries. Also, that's factually incorrect, as others have pointed out.
The big advantage with ffmpeg is, that you have the same interface on all operating systems. Even mobile phone OS ones.
You would with GStreamer, too. I don't know about mobile devices, but it already supports QuickTime and DirectShow. And unlike bundling ffmpeg, that means it can use native hardware decoding when available.
Also you don’t seem to know that ffmpeg is not a codec.
Tell that to stms, who seems to be under the impression that bundling ffmpeg would include support for h.264. If ffmpeg includes codecs, that doesn't really solve the problem, does it?
And for the media terrorist countries, make it optional. (So people can download ffmpeg separately. E.g. trough their package manager.
Which is exactly what I'm suggesting, only through GStreamer instead.
Since every Linux distribution known to man already includes ffmpeg,
Ubuntu doesn't include those problematic codecs in their ffmpeg. At least until the licensed versions start showing up, you'll have to use Medibuntu, which is entirely unsupported by Ubuntu. So no,
every Linux distribution known to man has more balls than the spineless Firefox team
-1 wrong.
Though I'd argue that the Firefox team is taking a truly moronic stand at refusing to implement the solution I suggested on what seems to be purely ideological grounds -- they don't like it because it means they can't refuse to support h.264 anymore, and they don't want h.264 to win. Well, if they keep digging their heels in, I'm guessing h.264 will win, and they'll lose -- people will switch from Firefox.
The point of standardizing stuff is not to make the browser one giant monolithic pile of crap. The point of standardizing stuff is to make a standard interface that developers can rely on -- <object> didn't provide support for things like altering the video with CSS, controlling it (pause/play), etc.
Because it would violate patents in many countries, unless you stripped out all of the infringing codecs, including h.264.
Also because it's the wrong way to go about this. Why bundle the codecs when you can call out to native, shared systems like GStreamer and have them provide the codecs for you? That'd handle the legal issue, too.
I don't. That doesn't make it any less wrong -- for one, why should it be a federal crime? I just don't get why the government is enforcing Apple's rules.
If a car existed that was extremely reliable, looked great, got excellent gas mileage, drove wonderfully and hardly ever broke down but I couldn't even change the oil, you know what? I might buy it.
Problem is, there are many cars for which nearly all of the above is true -- but you can change the oil.
Even on cars where I can lift the hood, I don't. I don't know shit about cars.
Neither do I.
I mean, I can change my oil, but I don't. I don't want to deal with it. I take it to my car expert.
There are shiny new BMWs which cannot have the oil changed except at a BMW dealer. That's the point.
Most people don't car about changing their own oil anymore than they give a shit about open source of vendor lock in.
I don't care about changing my own oil, no. But if I could only change my oil at a certain dealer, that'd be a problem. It's not that I want to change my own oil, it's that I want oil changes to be relatively cheap and abundant.
It's not that I want to pop my own hood, but if my car breaks down in the middle of nowhere, and a car expert happens by, it'd be nice if they could fix my problem. Or it'd be nice to call a local shop and have them send a truck, instead of having to -- what -- tow it two cities away to find the next person who's authorized to work on my car?
And you don't have to be much of a car person to want to be able to get a jump start -- or help someone else out by jumping them.
WTF is wrong with people around here? If you want a simple device you must be a simple person?
Badly worded, sorry. A simple device for people who don't want to tinker with it. Still not something that it should be a federal crime to tinker with. These devices are capable of so much more than we're being allowed to do with them.
But I see this all the time, and I'm surprised I keep seeing it -- your attitude seems to be that I should just not buy one, not develop for one, and shut up. Well, I've done the first two, but I'm not about to shut up. Whether or not I use it, the fact that it exists does affect me -- every developer working on an iPhone app is one less developer working on something cool. And while it's not quite one to one, the bigger a market the iPhone (or iPad) becomes, the less of a market there will be for the kinds of applications I want to work on.
Pass it to the OS or build against external libraries and let something else figure that out.
Also see WebGL. I agree that external libraries should be used, but there needs to be some amount of integration, or at least standardization. The browser doesn't have to implement OpenGL itself, but it helps that it's specified to be OpenGL and not DirectX.
HTML5 requires a bit more control than I think tools like mplayer would provide. However, there's nothing stopping Firefox from supporting local tools -- GStreamer on Linux, QuickTime on OS X, or DirectShow on Windows -- and letting the user get the appropriate codecs, legally or otherwise.
Many people do enjoy manual transmissions, though I don't, so I see your point.
However, the largest component missing is an option other than the App Store. This move is akin to selling a car with the hood welded shut. While some higher-end models might get away with it (Rolls-Royce, BMW, etc), it's still something I'd be very wary of buying. Modern BMWs are to the point where you physically can't even get an oil change, let alone change the radio, without going to a BMW dealer (at BMW prices) -- you're actually locked out of your own engine.
I don't have a problem with it being a simple device for simple people. I do have a problem with the fact that it's actually a federal crime to tinker with it, let alone try to sell apps or other accessories for it without Apple's stamp of approval.
Git is a decentralized vcs, which means it's easy for someone to download the source, make modifications, but keep those modifications private.... Use bzr or mercury if you like FREE software.
What's mercury? (Maybe you meant mercurial?) And both bzr and mercurial are both just as decentralized.
I know Linus Torvaldes is your hero, but let's be honest. Before git, his rcs of choice was the non-FREE BitKeeper.
And before that, his rcs of choice was none at all, because that's how much of a difference a dvcs makes over non-distributed.
FREE sfotware is about giving back your changes to the community, to the centralized repository.
Free "sfotware" doesn't exist. Free software is about giving your changes back to the community however you want, including not at all if you so desire. If I want to fork and develop on my own, in private, it's going to be very hard to merge that stuff back if I use svn. If I use Git, such private branches might be contributed back one day, and much more easily.
Oh, and you're offtopic. Guess what: It's free software now, so if you're that terrified of Git, go fork it in svn. See if anyone cares enough to follow you...
Oh, that's right, you're a hypocrite -- you won't use svn, you'll use bzr or hg, which function exactly like git, only slower.
Most of your points are valid, and I apologize for missing the original, original post. (I didn't go far enough up the thread.)
I'm actually going to have to go think about how script loading works.
But this part:
And "xml-ifying" html is purely an affectation, when it's meant to be viewed as a web page.
Nope, you seem to have ignored the microformats link and the potential for building a web service, not just a web page. HTML is rich enough to be used as a generic hypertext language -- no need for JSON or separate XML for your AJAX -- but it's a lot easier for bots to consume when it's XML.
And if you're complaining about this part:
A waste of space, time, and clock ticks.
A waste of space -- yeah, I think I can afford the occasional character or two. Really?
Time doesn't apply -- I linked to Haml, and there are other, similar tools. I actually spend less time generating perfectly valid XHTML than I would generating poorly-formed HTML, even when you consider that both cases are effectively hand-coding.
Clock ticks are actually the inverse. Again, an XHTML document can be parsed with an XML parser, which is much simpler than an HTML parser -- thus, fewer clock ticks, even if it's just being viewed as a web page.
A lot of your argument is based on making a random assumption
I don't think it's random or unprecedented. Moreover, you haven't demonstrated it to be false -- it may be difficult to implement. HTML5 evidently is not.
You've also outright ignored several important points I made:
Have they actually opened the spec to the point where third-party players are feasible? Last I checked, the spec was open for creating content, but not playing it....the DRM'd stuff is not and never has been open, so I can't duplicate that -- and Hulu is using that. So either you're wrong about Flash being open, or you're offtopic, take your pick.
You didn't answer either of those points. You handwaved about third-party players existing, but that doesn't tell me whether or not they're allowed to read the specs yet -- again, the specs were open to third-party content creation tools for awhile, but not players, for some perverse reason.
On to your arguments...
There are half a dozen working, competing, incomplete implementations of Flash, and many fully fledged production cross-browser apps on top of it.
Citation needed.
In brief, because they're web browsers, and their remit is to implement W3C's HTML spec, not to write it. Other motives include Google's dream of holding all your data and serving everything via Javascript....
While true, it's still entirely up to a browser to simply refuse to implement a spec. In particular:
MS, as usual, is just paying lip service in the hope of preserving browser marketshare.
That raises the question of why they would implement the video tag, but not canvas?
The point here is that there are other players than Apple -- other contributors to the spec than Apple -- and more to HTML5 than video. Your claim that this is just because Apple doesn't like Flash is wrong on many levels.
No, not at all. I don't see lots of iApps being written in the "entirely open HTML5",
Mostly because then they're not iApps anymore. Then they're just web apps, which happen to work on Apple devices, but also work in any decent browser.
So how would you know?
And years 4 to 9 of the web were awash with huge imagemaps which everyone hated and which were soon replaced with smarter HTML as people accepted that an img was for an image, not for intelligence.
What? No, people still do things with images, though not to that extent. We still have mouseovers, at the very least. Images are used in place of buttons for interaction, and they're used as indicators and such all over the place. We've even got tricks with "sprite maps", where a single image file is manipulated through CSS to appear as multiple tiny icons as needed throughout the page.
More relevantly, you talk about "smarter HTML" -- I asked how an effect which is possible today with Canvas could be duplicated with SVG, and your response was to denigrate the effect. Apparently, smarter HTML, or smarter SVG, isn't really possible at this point.
video is a not entirely insane tag, but it appears in HTML5
That's like refusing to use HTML because it once contained the blink tag.
It's as modular as you pretend HTML can be, i.e. you could make a non-conforming implementation leaving out as many features as you want.
What no one has done yet is to create a competing, conforming implementation. That's the prerequisite -- leaving shit out isn't modularity. Modularity is being able to add and remove features at will, and for that to work, you need to have all the features at some point.
Bullcrap. The browsers themselves are the single biggest attack vectors,
The numbers disagree. Including the browser, most atta
Of course, caches are horribly ineffective on the modern web, since browsers tend to allocate 50 MB or something and that gets churned up almost immediately.
Which is why I try to give the browser more on the order of a gig or two. Unfortunately, Chrome doesn't seem to let me change that...
I got it from the actual url on the page in question. Beter ask the person who wrote the page, not me.
It's a content-encoding option. The file itself is transparently compressed if the client supports it. That means if you save it with wget, either wget will send an "accept-encoding" header and decompress it silently for you, or it won't send that header and it'll get the uncompressed version.
Here, try it yourself. It comes out to about 24k, when supported.
Very naive statement there,especially since the url, if you read my original post, is NOT the one you reference.
First, you don't give a URL in your original post.
Well, surprise surprise, they match perfectly, unless you're seriously going to claim Google is exploiting an MD5 collision -- not impossible, but seems absurdly unlikely. Again, how is it naive to assume that when I ask Google's API for jQuery 1.4, I get jQuery 1.4?
And also totally irrelevant to the original point - a PROPER demo to support the claim that there are no other dependencies would NOT make reference to any other scripts.
Oh, I see. There was that claim. Fair enough.
Of course, as others have pointed out, it's not terribly difficult to remove that dependency, as it seems to only be using it for the load.
HTML != XHTML. Get over it, and stop making "fake" xml
Erm, no, that's real XML. Making it XML enables much easier access to microformats, among other things, and generally easier access from REST clients. It also means that, so long as the document actually is XML, the browser can use an XML parser instead of a raw HTML parser -- and XML parsers are much smaller and faster than HTML parsers.
Putting script tags anywhere else in the document is generally considered bad form because of the existence of document.write. The fact that it exists, even if you don't use it, means that the HTML parser has to completely stop and evaluate the script before it can continue parsing the rest of the document. It's in the head for the same reason you want to put the Content-Type meta tag near the top of the document -- as soon as your browser sees that Content-Type, it has to throw away any parsing its done and re-parse the entire document using the new encoding.
In other words, it's not just a matter of people whining about standards, it's a matter of making the best, fastest pages you can.
It's also not like you have to type more in order to do that -- that's what Haml is for.
Have they actually opened the spec to the point where third-party players are feasible? Last I checked, the spec was open for creating content, but not playing it.
Adobe's player is not great, but it works
No, it really doesn't.
you could always write a better one.
That's not terribly relevant.
First, Gnash has been trying for awhile, and hasn't been very successful. That could just be that Gnash sucks, it could just be that everyone already has Flash, and it could be that everyone's focused on HTML5. But it could also be because it's a hard spec to implement, and not a good choice. Compare OOXML and ODF -- both of those are at least approved by standards bodies, but they're not equally easy to implement.
Also, the DRM'd stuff is not and never has been open, so I can't duplicate that -- and Hulu is using that. So either you're wrong about Flash being open, or you're offtopic, take your pick.
The canvas element is a nowhere-fully-implemented
"Full" or not, it has multiple working, competing implementations, and many cross-browser demos on top of it.
ostensibly an "open standard" but really nothing more than Apple's troll
Now why would Chrome, Firefox, even IE participate in something that's merely "Apple's troll"? Any credibility you had till this point is pretty much gone.
to squeeze Flash out so anything worth using on their new legion of devices will have to be written using yet more proprietary Cocoa.
Well, that or using the entirely open HTML5. See how that works?
And why the hell would Apple care what's a standard or not? They can implement whatever they want on their devices, and ban whatever they want. If Flash didn't suck, there's not much stopping them from allowing it in the browser for video, but banning it as an app development tool and forcing everyone to use Cocoa anyway.
If you're seriously going to say you think Apple is trying to force crappy Flash game developers to become crappy iPhone game developers... really? You don't see them becoming crappy HTML5 game developers instead?
Neither Flash nor canvas are in the spirit of HTML, in that they basically provide a blank sheet outside the DOM.
So does <img>. Besides, what does canvas have to do with this? This would be about <video> vs Flash, and <video> is even more just another kind of <img>.
If you believe that modular plug-ins fit for purpose are good, Flash is a reasonable approach...
And no one is stopping you from implementing HTML5 as a set of plug-ins, or implementing a truly modular browser where image tags are only supported by an optional extension.
In the mean time, Flash is far from modular. It's a single monolithic plugin, a giant binary blob which also happens to be the single biggest attack vector, and it handles everything from application development (why the FUCK is the IRS using Flash for my taxes?) to streaming video to simple font embedding to animated ads to games to, lately, full 3D. Indeed, Adobe has gone the other direction, if anything -- Adobe AIR includes a WebKit engine, so that particular brand of Flash has sucked all of HTML into it.
If you actually like HTML, use SVG and build on that standard.
I don't particularly disagree, but again, WTF does this have to do with Hulu? How do I play a video in SVG?
Since you seem to have confused HTML5 with <canvas>, the same way most people confuse HTML5 with <video>... While you're at it, how do I get local SQL storage in SVG? How about offline web app support? Seamless drag-and-drop? How about a simple, efficient motion blur effect?
We were able to see right through it, sure, but from TFS:
Our player doesn't just simply stream video, it must also secure the content, handle reporting for our advertisers, render the video using a high performance codec to ensure premium visual quality, communicate back with the server to determine how long to buffer and what bitrate to stream, and dozens of other things that aren't necessarily visible to the end user.
Unless that's a particularly bad quote, they're actually lying about HTML5, or at least about continuing to monitor it. An HTML5-based player can indeed handle reporting for your advertisers and use a high-performance codec (or really, whatever codec you want). Communicating back to the server is certainly possible. The only thing that's not reasonable is switching bitrates on-the-fly and implementing any sort of DRM.
Switching bitrates may be a legitimate concern. DRM is legitimate insofar as it's not up to Hulu -- they have to implement DRM because it's what their "customers" want. Everything else is pure unadulterated FUD, so no, Hulu gets no credit for it -- they were trying to give the impression that HTML5 is missing tons of stuff they need (including DRM), when really, all that's missing is DRM and switching bitrates mid-stream.
The whole point being that jquery is not in any way vital to the functioning of the original page.
What he hasn't demonstrated is whether jQuery enhances the functioning of the original page. As far as I can tell, it does, certainly over his suggestion.
And certainly, jQuery is not necessary -- you could do everything yourself. That's the nature of a library.
Actually, even the minified version is 72k, not 24k,
It's 24k after gzipping. You do serve text content gzipped, don't you?
It's possible that there's a different version in play here, but the 24k figure is what I'm getting from the latest version.
And of course the only way to verify that the minified version doesn't pull in more stuff
jQuery? It doesn't.
since the source script is, for all practical purposes, semi-obfuscated.
That's like bitching that you can't figure out what Firefox is doing, because you only have a binary. It's jQuery! The original, un-obfuscated source is available, along with full version-control history! Unless they've gone out of their way to be difficult, you should be able to verify (with diff) that the version they are using is actually a particular version available for download from jquery.com.
If the "only" purpose was to run the script, a simple body.onload() would have done the job,
Except that's not what jQuery does. If your browser supports it, it's actually onDOMReady. There's a world of difference between those -- onload requires everything to be loaded, including images, movies, everything. onDOMReady only requires the HTML DOM itself to be finished loading, which is going to be considerably faster -- but it's still enough that your script knows what it's dealing with.
If your browser doesn't support that event, I believe jQuery will emulate it via polling. I'm not sure if it ever falls back to load.
But no, body.onload() is not equivalent. You could certainly do onDOMReady yourself, if you were really determined not to have external dependencies, but that could be said of anything included with a library.
as would calling the first function from an embedded script tag at the bottom of a demo page..
I'm pretty sure the only XHTML-compliant place to put script tags is inside the <head> tag, which makes sense. Progressive enhancement is good design.
Unfortunately, patents have been perverted far past that original purpose. That "little guy" inventor will be lucky if he can invent anything without tripping over someone's patent, and if he somehow succeeds, he's still going to have to hire a lawyer to make sure, and to help him file, etc.
That bigger business knows this game and can play it to their advantage.
Slashdot Mirror
It is possible for someone other than the patent holder to use patented tech you know?
Yes, but only with permission. In the case of H.264, Mozilla could buy a license, but then anyone who wants to roll their own version of Firefox has to pay for a separate license.
No it wouldn't, it would simply shift it somewhere else.
Indeed. It would shift it to the OSes, and both Windows and OS X already license H.264, among others. Even Ubuntu looks likely to do so. There's also the Fluendo codecs, among others.
It also makes it technically possible for the individual user to violate the patent by downloading unlicensed implementations, like those found in medibuntu. If you don't like patents, that's a much better scenario than simply asking Mozilla to do it -- the MPEG-LA can sue Mozilla out of existence, but they can't sue every Linux user out of existence, especially when some people will buy Fluendo codecs.
Any way you slice it, this puts that "burden" in a much more manageable place. If I'm running Windows, I already have an H.264 license -- why shouldn't I be able to use it in Firefox? Does Mozilla really want to force me to only use it in IE?
Of course you really don't understand patents in the first place
Ad-hom based on less than two paragraphs out of me. That's hardly fair, wouldn't you say?
Yes, I've seen that, and I don't really see the point. The biggest privacy concerns in Chrome itself -- Chrome, not Chromium -- can be dealt with by un-ticking a checkbox or two in options.
I honestly don't see what the big deal is.
As the summary said: There are only two countries in the world with software patents. TWO.
They're big enough that it would really suck if Firefox couldn't be distributed in those countries. Also, that's factually incorrect, as others have pointed out.
The big advantage with ffmpeg is, that you have the same interface on all operating systems. Even mobile phone OS ones.
You would with GStreamer, too. I don't know about mobile devices, but it already supports QuickTime and DirectShow. And unlike bundling ffmpeg, that means it can use native hardware decoding when available.
Also you don’t seem to know that ffmpeg is not a codec.
Tell that to stms, who seems to be under the impression that bundling ffmpeg would include support for h.264. If ffmpeg includes codecs, that doesn't really solve the problem, does it?
And for the media terrorist countries, make it optional. (So people can download ffmpeg separately. E.g. trough their package manager.
Which is exactly what I'm suggesting, only through GStreamer instead.
Since every Linux distribution known to man already includes ffmpeg,
Ubuntu doesn't include those problematic codecs in their ffmpeg. At least until the licensed versions start showing up, you'll have to use Medibuntu, which is entirely unsupported by Ubuntu. So no,
every Linux distribution known to man has more balls than the spineless Firefox team
-1 wrong.
Though I'd argue that the Firefox team is taking a truly moronic stand at refusing to implement the solution I suggested on what seems to be purely ideological grounds -- they don't like it because it means they can't refuse to support h.264 anymore, and they don't want h.264 to win. Well, if they keep digging their heels in, I'm guessing h.264 will win, and they'll lose -- people will switch from Firefox.
Directshow, Gstreamer/FFMpeg and Quicktime is going to cause the Internet to catch fire and explode ("performance tuned code with little security").
Because Flash is so much better. And where are they getting their Theora implementation, hmm?
The second issue is that WinXP and Vista don't have H.264, you need to install FFDshow or Nero, etc to get that support.
So what? At least then it's possible to get that support.
Basically, their argument is, "It might be hard for the average user to get H.264, at least on older OSes, so we'll make it actually impossible." WTF?
The point of standardizing stuff is not to make the browser one giant monolithic pile of crap. The point of standardizing stuff is to make a standard interface that developers can rely on -- <object> didn't provide support for things like altering the video with CSS, controlling it (pause/play), etc.
Because it would violate patents in many countries, unless you stripped out all of the infringing codecs, including h.264.
Also because it's the wrong way to go about this. Why bundle the codecs when you can call out to native, shared systems like GStreamer and have them provide the codecs for you? That'd handle the legal issue, too.
So don't buy one.
I don't. That doesn't make it any less wrong -- for one, why should it be a federal crime? I just don't get why the government is enforcing Apple's rules.
If a car existed that was extremely reliable, looked great, got excellent gas mileage, drove wonderfully and hardly ever broke down but I couldn't even change the oil, you know what? I might buy it.
Problem is, there are many cars for which nearly all of the above is true -- but you can change the oil.
Even on cars where I can lift the hood, I don't. I don't know shit about cars.
Neither do I.
I mean, I can change my oil, but I don't. I don't want to deal with it. I take it to my car expert.
There are shiny new BMWs which cannot have the oil changed except at a BMW dealer. That's the point.
Most people don't car about changing their own oil anymore than they give a shit about open source of vendor lock in.
I don't care about changing my own oil, no. But if I could only change my oil at a certain dealer, that'd be a problem. It's not that I want to change my own oil, it's that I want oil changes to be relatively cheap and abundant.
It's not that I want to pop my own hood, but if my car breaks down in the middle of nowhere, and a car expert happens by, it'd be nice if they could fix my problem. Or it'd be nice to call a local shop and have them send a truck, instead of having to -- what -- tow it two cities away to find the next person who's authorized to work on my car?
And you don't have to be much of a car person to want to be able to get a jump start -- or help someone else out by jumping them.
WTF is wrong with people around here? If you want a simple device you must be a simple person?
Badly worded, sorry. A simple device for people who don't want to tinker with it. Still not something that it should be a federal crime to tinker with. These devices are capable of so much more than we're being allowed to do with them.
But I see this all the time, and I'm surprised I keep seeing it -- your attitude seems to be that I should just not buy one, not develop for one, and shut up. Well, I've done the first two, but I'm not about to shut up. Whether or not I use it, the fact that it exists does affect me -- every developer working on an iPhone app is one less developer working on something cool. And while it's not quite one to one, the bigger a market the iPhone (or iPad) becomes, the less of a market there will be for the kinds of applications I want to work on.
If they actually go with Chrome, that will be a joke. I actually value my privacy rights...
If you look at the list of stuff Chrome adds over Chromium, you won't find much you'd actually care about as far as privacy rights.
3D support next?
Google WebGL.
Pass it to the OS or build against external libraries and let something else figure that out.
Also see WebGL. I agree that external libraries should be used, but there needs to be some amount of integration, or at least standardization. The browser doesn't have to implement OpenGL itself, but it helps that it's specified to be OpenGL and not DirectX.
HTML5 requires a bit more control than I think tools like mplayer would provide. However, there's nothing stopping Firefox from supporting local tools -- GStreamer on Linux, QuickTime on OS X, or DirectShow on Windows -- and letting the user get the appropriate codecs, legally or otherwise.
Many people do enjoy manual transmissions, though I don't, so I see your point.
However, the largest component missing is an option other than the App Store. This move is akin to selling a car with the hood welded shut. While some higher-end models might get away with it (Rolls-Royce, BMW, etc), it's still something I'd be very wary of buying. Modern BMWs are to the point where you physically can't even get an oil change, let alone change the radio, without going to a BMW dealer (at BMW prices) -- you're actually locked out of your own engine.
I don't have a problem with it being a simple device for simple people. I do have a problem with the fact that it's actually a federal crime to tinker with it, let alone try to sell apps or other accessories for it without Apple's stamp of approval.
I've had to parse xml in c - I've seen what generic parser code is like, and it's both ugly and time+space-consuming.
Still not nearly as much as HTML. Also, much better specified, and many existing implementations in every conceivable language.
I don't recall claiming that it was easy, but you were the one who raised the issue of clock ticks. Have you had to parse generic HTML in C?
Git is a decentralized vcs, which means it's easy for someone to download the source, make modifications, but keep those modifications private.... Use bzr or mercury if you like FREE software.
What's mercury? (Maybe you meant mercurial?) And both bzr and mercurial are both just as decentralized.
I know Linus Torvaldes is your hero, but let's be honest. Before git, his rcs of choice was the non-FREE BitKeeper.
And before that, his rcs of choice was none at all, because that's how much of a difference a dvcs makes over non-distributed.
FREE sfotware is about giving back your changes to the community, to the centralized repository.
Free "sfotware" doesn't exist. Free software is about giving your changes back to the community however you want, including not at all if you so desire. If I want to fork and develop on my own, in private, it's going to be very hard to merge that stuff back if I use svn. If I use Git, such private branches might be contributed back one day, and much more easily.
Oh, and you're offtopic. Guess what: It's free software now, so if you're that terrified of Git, go fork it in svn. See if anyone cares enough to follow you...
Oh, that's right, you're a hypocrite -- you won't use svn, you'll use bzr or hg, which function exactly like git, only slower.
Most of your points are valid, and I apologize for missing the original, original post. (I didn't go far enough up the thread.)
I'm actually going to have to go think about how script loading works.
But this part:
And "xml-ifying" html is purely an affectation, when it's meant to be viewed as a web page.
Nope, you seem to have ignored the microformats link and the potential for building a web service, not just a web page. HTML is rich enough to be used as a generic hypertext language -- no need for JSON or separate XML for your AJAX -- but it's a lot easier for bots to consume when it's XML.
And if you're complaining about this part:
A waste of space, time, and clock ticks.
A waste of space -- yeah, I think I can afford the occasional character or two. Really?
Time doesn't apply -- I linked to Haml, and there are other, similar tools. I actually spend less time generating perfectly valid XHTML than I would generating poorly-formed HTML, even when you consider that both cases are effectively hand-coding.
Clock ticks are actually the inverse. Again, an XHTML document can be parsed with an XML parser, which is much simpler than an HTML parser -- thus, fewer clock ticks, even if it's just being viewed as a web page.
A lot of your argument is based on making a random assumption
I don't think it's random or unprecedented. Moreover, you haven't demonstrated it to be false -- it may be difficult to implement. HTML5 evidently is not.
You've also outright ignored several important points I made:
Have they actually opened the spec to the point where third-party players are feasible? Last I checked, the spec was open for creating content, but not playing it....the DRM'd stuff is not and never has been open, so I can't duplicate that -- and Hulu is using that. So either you're wrong about Flash being open, or you're offtopic, take your pick.
You didn't answer either of those points. You handwaved about third-party players existing, but that doesn't tell me whether or not they're allowed to read the specs yet -- again, the specs were open to third-party content creation tools for awhile, but not players, for some perverse reason.
On to your arguments...
There are half a dozen working, competing, incomplete implementations of Flash, and many fully fledged production cross-browser apps on top of it.
Citation needed.
In brief, because they're web browsers, and their remit is to implement W3C's HTML spec, not to write it. Other motives include Google's dream of holding all your data and serving everything via Javascript....
While true, it's still entirely up to a browser to simply refuse to implement a spec. In particular:
MS, as usual, is just paying lip service in the hope of preserving browser marketshare.
That raises the question of why they would implement the video tag, but not canvas?
The point here is that there are other players than Apple -- other contributors to the spec than Apple -- and more to HTML5 than video. Your claim that this is just because Apple doesn't like Flash is wrong on many levels.
No, not at all. I don't see lots of iApps being written in the "entirely open HTML5",
Mostly because then they're not iApps anymore. Then they're just web apps, which happen to work on Apple devices, but also work in any decent browser.
So how would you know?
And years 4 to 9 of the web were awash with huge imagemaps which everyone hated and which were soon replaced with smarter HTML as people accepted that an img was for an image, not for intelligence.
What? No, people still do things with images, though not to that extent. We still have mouseovers, at the very least. Images are used in place of buttons for interaction, and they're used as indicators and such all over the place. We've even got tricks with "sprite maps", where a single image file is manipulated through CSS to appear as multiple tiny icons as needed throughout the page.
More relevantly, you talk about "smarter HTML" -- I asked how an effect which is possible today with Canvas could be duplicated with SVG, and your response was to denigrate the effect. Apparently, smarter HTML, or smarter SVG, isn't really possible at this point.
video is a not entirely insane tag, but it appears in HTML5
That's like refusing to use HTML because it once contained the blink tag.
It's as modular as you pretend HTML can be, i.e. you could make a non-conforming implementation leaving out as many features as you want.
What no one has done yet is to create a competing, conforming implementation. That's the prerequisite -- leaving shit out isn't modularity. Modularity is being able to add and remove features at will, and for that to work, you need to have all the features at some point.
Bullcrap. The browsers themselves are the single biggest attack vectors,
The numbers disagree. Including the browser, most atta
Certain file systems, even with tons of free space, will fragment files that are in the low megabyte range.
Then part of the solution would be to pick filesystems which don't do that, right?
Of course, caches are horribly ineffective on the modern web, since browsers tend to allocate 50 MB or something and that gets churned up almost immediately.
Which is why I try to give the browser more on the order of a gig or two. Unfortunately, Chrome doesn't seem to let me change that...
I got it from the actual url on the page in question. Beter ask the person who wrote the page, not me.
It's a content-encoding option. The file itself is transparently compressed if the client supports it. That means if you save it with wget, either wget will send an "accept-encoding" header and decompress it silently for you, or it won't send that header and it'll get the uncompressed version.
Here, try it yourself. It comes out to about 24k, when supported.
Very naive statement there,especially since the url, if you read my original post, is NOT the one you reference.
First, you don't give a URL in your original post.
Second, how is it naive? Watch this:
Well, surprise surprise, they match perfectly, unless you're seriously going to claim Google is exploiting an MD5 collision -- not impossible, but seems absurdly unlikely. Again, how is it naive to assume that when I ask Google's API for jQuery 1.4, I get jQuery 1.4?
And also totally irrelevant to the original point - a PROPER demo to support the claim that there are no other dependencies would NOT make reference to any other scripts.
Oh, I see. There was that claim. Fair enough.
Of course, as others have pointed out, it's not terribly difficult to remove that dependency, as it seems to only be using it for the load.
HTML != XHTML. Get over it, and stop making "fake" xml
Erm, no, that's real XML. Making it XML enables much easier access to microformats, among other things, and generally easier access from REST clients. It also means that, so long as the document actually is XML, the browser can use an XML parser instead of a raw HTML parser -- and XML parsers are much smaller and faster than HTML parsers.
Putting script tags anywhere else in the document is generally considered bad form because of the existence of document.write. The fact that it exists, even if you don't use it, means that the HTML parser has to completely stop and evaluate the script before it can continue parsing the rest of the document. It's in the head for the same reason you want to put the Content-Type meta tag near the top of the document -- as soon as your browser sees that Content-Type, it has to throw away any parsing its done and re-parse the entire document using the new encoding.
In other words, it's not just a matter of people whining about standards, it's a matter of making the best, fastest pages you can.
It's also not like you have to type more in order to do that -- that's what Haml is for.
open
Have they actually opened the spec to the point where third-party players are feasible? Last I checked, the spec was open for creating content, but not playing it.
Adobe's player is not great, but it works
No, it really doesn't.
you could always write a better one.
That's not terribly relevant.
First, Gnash has been trying for awhile, and hasn't been very successful. That could just be that Gnash sucks, it could just be that everyone already has Flash, and it could be that everyone's focused on HTML5. But it could also be because it's a hard spec to implement, and not a good choice. Compare OOXML and ODF -- both of those are at least approved by standards bodies, but they're not equally easy to implement.
Also, the DRM'd stuff is not and never has been open, so I can't duplicate that -- and Hulu is using that. So either you're wrong about Flash being open, or you're offtopic, take your pick.
The canvas element is a nowhere-fully-implemented
"Full" or not, it has multiple working, competing implementations, and many cross-browser demos on top of it.
ostensibly an "open standard" but really nothing more than Apple's troll
Now why would Chrome, Firefox, even IE participate in something that's merely "Apple's troll"? Any credibility you had till this point is pretty much gone.
to squeeze Flash out so anything worth using on their new legion of devices will have to be written using yet more proprietary Cocoa.
Well, that or using the entirely open HTML5. See how that works?
And why the hell would Apple care what's a standard or not? They can implement whatever they want on their devices, and ban whatever they want. If Flash didn't suck, there's not much stopping them from allowing it in the browser for video, but banning it as an app development tool and forcing everyone to use Cocoa anyway.
If you're seriously going to say you think Apple is trying to force crappy Flash game developers to become crappy iPhone game developers... really? You don't see them becoming crappy HTML5 game developers instead?
Neither Flash nor canvas are in the spirit of HTML, in that they basically provide a blank sheet outside the DOM.
So does <img>. Besides, what does canvas have to do with this? This would be about <video> vs Flash, and <video> is even more just another kind of <img>.
If you believe that modular plug-ins fit for purpose are good, Flash is a reasonable approach...
And no one is stopping you from implementing HTML5 as a set of plug-ins, or implementing a truly modular browser where image tags are only supported by an optional extension.
In the mean time, Flash is far from modular. It's a single monolithic plugin, a giant binary blob which also happens to be the single biggest attack vector, and it handles everything from application development (why the FUCK is the IRS using Flash for my taxes?) to streaming video to simple font embedding to animated ads to games to, lately, full 3D. Indeed, Adobe has gone the other direction, if anything -- Adobe AIR includes a WebKit engine, so that particular brand of Flash has sucked all of HTML into it.
If you actually like HTML, use SVG and build on that standard.
I don't particularly disagree, but again, WTF does this have to do with Hulu? How do I play a video in SVG?
Since you seem to have confused HTML5 with <canvas>, the same way most people confuse HTML5 with <video>... While you're at it, how do I get local SQL storage in SVG? How about offline web app support? Seamless drag-and-drop? How about a simple, efficient motion blur effect?
We were able to see right through it, sure, but from TFS:
Our player doesn't just simply stream video, it must also secure the content, handle reporting for our advertisers, render the video using a high performance codec to ensure premium visual quality, communicate back with the server to determine how long to buffer and what bitrate to stream, and dozens of other things that aren't necessarily visible to the end user.
Unless that's a particularly bad quote, they're actually lying about HTML5, or at least about continuing to monitor it. An HTML5-based player can indeed handle reporting for your advertisers and use a high-performance codec (or really, whatever codec you want). Communicating back to the server is certainly possible. The only thing that's not reasonable is switching bitrates on-the-fly and implementing any sort of DRM.
Switching bitrates may be a legitimate concern. DRM is legitimate insofar as it's not up to Hulu -- they have to implement DRM because it's what their "customers" want. Everything else is pure unadulterated FUD, so no, Hulu gets no credit for it -- they were trying to give the impression that HTML5 is missing tons of stuff they need (including DRM), when really, all that's missing is DRM and switching bitrates mid-stream.
The whole point being that jquery is not in any way vital to the functioning of the original page.
What he hasn't demonstrated is whether jQuery enhances the functioning of the original page. As far as I can tell, it does, certainly over his suggestion.
And certainly, jQuery is not necessary -- you could do everything yourself. That's the nature of a library.
Actually, even the minified version is 72k, not 24k,
It's 24k after gzipping. You do serve text content gzipped, don't you?
It's possible that there's a different version in play here, but the 24k figure is what I'm getting from the latest version.
And of course the only way to verify that the minified version doesn't pull in more stuff
jQuery? It doesn't.
since the source script is, for all practical purposes, semi-obfuscated.
That's like bitching that you can't figure out what Firefox is doing, because you only have a binary. It's jQuery! The original, un-obfuscated source is available, along with full version-control history! Unless they've gone out of their way to be difficult, you should be able to verify (with diff) that the version they are using is actually a particular version available for download from jquery.com.
If the "only" purpose was to run the script, a simple body.onload() would have done the job,
Except that's not what jQuery does. If your browser supports it, it's actually onDOMReady. There's a world of difference between those -- onload requires everything to be loaded, including images, movies, everything. onDOMReady only requires the HTML DOM itself to be finished loading, which is going to be considerably faster -- but it's still enough that your script knows what it's dealing with.
If your browser doesn't support that event, I believe jQuery will emulate it via polling. I'm not sure if it ever falls back to load.
But no, body.onload() is not equivalent. You could certainly do onDOMReady yourself, if you were really determined not to have external dependencies, but that could be said of anything included with a library.
as would calling the first function from an embedded script tag at the bottom of a demo page..
I'm pretty sure the only XHTML-compliant place to put script tags is inside the <head> tag, which makes sense. Progressive enhancement is good design.
Robots are also getting better at doing these things. If they're not good enough yet, maybe we have a dearth of good robotics engineers.
So you're saying that, because it made different claims, it shouldn't expire?
Unfortunately, patents have been perverted far past that original purpose. That "little guy" inventor will be lucky if he can invent anything without tripping over someone's patent, and if he somehow succeeds, he's still going to have to hire a lawyer to make sure, and to help him file, etc.
That bigger business knows this game and can play it to their advantage.