Yes. I am claiming that the demos include all sorts of stuff that's not in "the spec" if "the spec" is HTML5, nor is it in any drafts likely to become specs in the near future. So they're basically demoing proprietary Safari extensions and trying to claim that they're part of HTML5.
> Clearly that is what they're focusing on, but where do they say other browsers are behind?
In the "other browsers don't implement this stuff" verbiage.
> Yeah, those bastards putting up a demo of Safari,
Which is fine, if you don't then advertise it as a demo of HTML5 (complete with the url claiming it has something to do with HTML5).
> and that other browsers and Safari are in the process of adding support for the spec
Which makes it sound like what they're demoing is part of "the spec". It's not. It also makes it sound like Safari is just ahead of the other browsers in implementing HTML5 (a line Apple has been pushing hard), which it's not.
> You have to be biased as hell and looking for a way to interpret this negatively.
No, you just have to be willing to call entities on actions that are not acceptable even if you otherwise like what they're doing.
No, it's really not. Different groups of people are involved, different working groups, different schedules.
> which is vital for it to be used
No, it's really not. You don't need CSS3 to use the new types of form controls in HTML5, to use video, audio, canvas, the new sectioning elements, to implement the HTML5 parsing algorithm. In fact, you pretty much don't need CSS3 for anything related HTML5 other than additional styling (which is he point of CSS, of course).
> It would be hard to write an HTML5 demo without CSS.
No, it would in fact be trivial if you wanted to demo HTML5 as opposed to CSS stuff. Here's a simple example:
This is a demo of a useful new HTML5 capability that makes whole classes of flash/java uploader applets not needed anymore, and requires absolutely no CSS.
There are plenty of other HTML5 demos out there that aren't CSS-bound.
> is generally referred to as "HTML5" by both the layman and the people writing the specs.
Speaking as one of the latter... no, it's not. Though Google and Apple are both trying hard to expand "HTML5" to mean "all next-generation web technologies, including the proprietary ones" (both of them have been doing this recently). I'm sorry they got you to buy into their marketing.
> for putting up a technology demo of cool new open specs
Except that a bunch of the stuff they put up isn't specs; not even really spec proposals.
> Seriously, show me the code that Apple is including that is not proposed as part of one > of the new WHATWG specs
Well, since no CSS specs are whatwg specs... that's easy. As a particularly egregious example, the demo at http://www.apple.com/html5/showcase/vr/ uses 3d transforms, which are not associated with anything in the WHATWG, are implemented only on some versions of Safari on only some Apple operating systems (because they need significant OS-level support, apparently), and the closest they come to a spec is a CSS3 draft published by 3 apple employees (note that any CSSWG member can just put up a draft saying anything they want to; the bar for initial draft publication is _very_ low).
> whether Apple's demos use undocumented or non-standard features
They do, yes.
So to use your car analogy, this is like Mercedes having a car with a parachute it can use to brake in an emergency and putting up an ad saying "we sell cars that comply with federal safety standards; check out this feature that not all other car makers offer" and showing the parachute in action. The result is the viewer getting an impression that the other car makers don't comply with federal safety standards, of course, which is bunk.
So you're right that it's an advert, but the problem is that it's a deceptive one.
> It's just not worth the effort at this point to try to support Firefox when the public > builds have very little support for HTML 5.
Oddly enough, shipping Firefox has more support for parts of HTML5 than shipping Safari, last I checked (and likewise when comparing unstable to unstable). But of course Apple and Google are hard at working trying to convince people like you that they invented HTML5...
> The webkit tags they are using, work in pretty much any up-to-date webkit browsers
That's actually false. The 3d transforms stuff they're using works in Mobile Safari and Safari on Snow Leopard. Doesn't work in Safari on Leopard or earlier, Safari on Windows, other webkit-based browsers (does something quite different from what's intended on some of these, in fact).
Amusingly enough, neither Safari's nor Chrome's JS engine is actually part of WebKit...
Which pretty much sums up your post. You complain that JS performance is slow in some cases in Firefox (a legitimate complaint, by the way!) and then say that this means HTML5 is not supported... But the HTML5 parts are fine; it's the specific scripts operating on them that has issues. And the worst issues are specific to some sets of use cases people love to use for benchmarking (e.g. emulators). So you see the worst-case scenario and assume that's the way the entire world works. It doesn't.
But the thing is that most of what they're showing off isn't "HTML5" but in fact Safari-proprietary CSS (and for that matter CSS that only works in Safari on Snow Leopard and Mobile Safari, not any other Safari).
> A vendor prefix doesn't mean "proprietary"--it means "experimental"
It can mean either one. There are -webkit properties of both kinds (and -moz properties of both kinds, and -msie properties of both kinds, last I checked).
No, this is all about making it seem like other browsers need to play catchup when in fact they may be ahead of you on actually implementing HTML5. You do that by putting out a demo that doesn't really demo HTML5 much and calling it an HTML5 demo.
> Actually they tried to be open and cutting edge,
No, they very purposefully tried to create the impression that "HTML5" support in other browsers is worse than in Safari (which happens to be not true, if you actually look at HTML5 instead of the things Apple decided to demo).
In other words, this is a pure deceptive marketing ploy, and deserves to be called out as such.
But the point is that the demos are using random proprietary Safari features that are not part of HTML5, not planned to be a part of it, and will never become a part of it (for example, because they're CSS features, not HTML ones). So calling it a demo of "support for HTML5" is just a bald-faced lie. Call it "support for some stuff we made up", which is what it is, and no problem.
The only problem with this line of reasoning is that if you actually _look_ at the demos:
1) Most of what's involved isn't parts of HTML5 _or_ proposals for HTML5. 2) Some of the things involved are "proposals" that they submitted (something anyone can do
anytime) to the CSS working group and that no one else is really interested in so far
last I heard.
There's no problem publishing demos that only work in your browser due to you using proprietary things you added to your browser. The problem is calling that sort of thing "HTML5" and making it sound like it's a standard or likely to become one soon.
> What agenda is that, beyond making HTML5 more functional and useful for media and Web apps?
Controlling all content delivery to as many users as it can manage. Replacing as many web apps as it can get away with with iPhone apps. Making sure that as much of the mobile web as possible only renders well in their browser (hence recommending that people effectively design sites wrong then use -webkit-* properties that are only supported in Mobile Safari, not even desktop Safari, to "fix" the rendering for Apple's mobile devices).
That sort of thing, in addition to the agenda you listed.
I should clearly have quoted more of grandparent's post. He was specifically wanting to run JavaScript in the Mozilla JS interpreter, not the Mobile Safari one.
The poster was specifically talking about doing it "via Mozilla". And a JavaScript interpreter (other than the one Apple ships) is one of the things you are NOT allowed to ship on iPhone OS by Apple. Nor can you ship an interpreter of any other kind. It's not clear to me that even an XSLT implementation would be acceptable (since XSLT is a Turing-complete functional language).
So you could not in fact use Mozilla's JavaScript interpreter on iPhone or iPad.
It depends. "H.264" actually has multiple profiles; for simplicity people usually refer to baseline, main, and high. Baseline is the simplest to encode and decode; high is the most complex. High gives the best results (quality at given bitrate, etc).
Some expert opinion (biased toward H.264 due to being heavily involved with it, but let's start with it) basically comes down to VP8 being probably better than baseline, maybe comparable to main, worse than high.
H.264 on the web is in practice all baseline because that's what phones can typically hardware-accelerate (amongst other reasons), so the other ones would drain your phone battery in a jiffy if you tried to actually play them there.
The upshot of all this is that "codec quality" is hard to define, much less measure...;)
Slashdot Mirror
> Are you claiming that is not true.
Yes. I am claiming that the demos include all sorts of stuff that's not in "the spec" if "the spec" is HTML5, nor is it in any drafts likely to become specs in the near future. So they're basically demoing proprietary Safari extensions and trying to claim that they're part of HTML5.
> Clearly that is what they're focusing on, but where do they say other browsers are behind?
In the "other browsers don't implement this stuff" verbiage.
> Yeah, those bastards putting up a demo of Safari,
Which is fine, if you don't then advertise it as a demo of HTML5 (complete with the url claiming it has something to do with HTML5).
> Here's a simple example:
Gah. Slashdot ate the tags. Here we go:
<form action="someurl">
<input type="file" multiple>
<input type="submit">
</form>
> and that other browsers and Safari are in the process of adding support for the spec
Which makes it sound like what they're demoing is part of "the spec". It's not. It also makes it sound like Safari is just ahead of the other browsers in implementing HTML5 (a line Apple has been pushing hard), which it's not.
> You have to be biased as hell and looking for a way to interpret this negatively.
No, you just have to be willing to call entities on actions that are not acceptable even if you otherwise like what they're doing.
> HTML5 is being developed in parallel with CSS3
No, it's really not. Different groups of people are involved, different working groups, different schedules.
> which is vital for it to be used
No, it's really not. You don't need CSS3 to use the new types of form controls in HTML5, to use video, audio, canvas, the new sectioning elements, to implement the HTML5 parsing algorithm. In fact, you pretty much don't need CSS3 for anything related HTML5 other than additional styling (which is he point of CSS, of course).
> It would be hard to write an HTML5 demo without CSS.
No, it would in fact be trivial if you wanted to demo HTML5 as opposed to CSS stuff. Here's a simple example:
This is a demo of a useful new HTML5 capability that makes whole classes of flash/java uploader applets not needed anymore, and requires absolutely no CSS.
There are plenty of other HTML5 demos out there that aren't CSS-bound.
> is generally referred to as "HTML5" by both the layman and the people writing the specs.
Speaking as one of the latter... no, it's not. Though Google and Apple are both trying hard to expand "HTML5" to mean "all next-generation web technologies, including the proprietary ones" (both of them have been doing this recently). I'm sorry they got you to buy into their marketing.
> for putting up a technology demo of cool new open specs
Except that a bunch of the stuff they put up isn't specs; not even really spec proposals.
> Seriously, show me the code that Apple is including that is not proposed as part of one
> of the new WHATWG specs
Well, since no CSS specs are whatwg specs... that's easy. As a particularly egregious example, the demo at http://www.apple.com/html5/showcase/vr/ uses 3d transforms, which are not associated with anything in the WHATWG, are implemented only on some versions of Safari on only some Apple operating systems (because they need significant OS-level support, apparently), and the closest they come to a spec is a CSS3 draft published by 3 apple employees (note that any CSSWG member can just put up a draft saying anything they want to; the bar for initial draft publication is _very_ low).
> whether Apple's demos use undocumented or non-standard features
They do, yes.
So to use your car analogy, this is like Mercedes having a car with a parachute it can use to brake in an emergency and putting up an ad saying "we sell cars that comply with federal safety standards; check out this feature that not all other car makers offer" and showing the parachute in action. The result is the viewer getting an impression that the other car makers don't comply with federal safety standards, of course, which is bunk.
So you're right that it's an advert, but the problem is that it's a deceptive one.
> It's just not worth the effort at this point to try to support Firefox when the public
> builds have very little support for HTML 5.
Oddly enough, shipping Firefox has more support for parts of HTML5 than shipping Safari, last I checked (and likewise when comparing unstable to unstable). But of course Apple and Google are hard at working trying to convince people like you that they invented HTML5...
> The webkit tags they are using, work in pretty much any up-to-date webkit browsers
That's actually false. The 3d transforms stuff they're using works in Mobile Safari and Safari on Snow Leopard. Doesn't work in Safari on Leopard or earlier, Safari on Windows, other webkit-based browsers (does something quite different from what's intended on some of these, in fact).
That's a Safari/webkit issue, not an HTML5 one. Gecko performs sub-pixel layout and positioning, for example.
Amusingly enough, neither Safari's nor Chrome's JS engine is actually part of WebKit...
Which pretty much sums up your post. You complain that JS performance is slow in some cases in Firefox (a legitimate complaint, by the way!) and then say that this means HTML5 is not supported... But the HTML5 parts are fine; it's the specific scripts operating on them that has issues. And the worst issues are specific to some sets of use cases people love to use for benchmarking (e.g. emulators). So you see the worst-case scenario and assume that's the way the entire world works. It doesn't.
But the thing is that most of what they're showing off isn't "HTML5" but in fact Safari-proprietary CSS (and for that matter CSS that only works in Safari on Snow Leopard and Mobile Safari, not any other Safari).
> A vendor prefix doesn't mean "proprietary"--it means "experimental"
It can mean either one. There are -webkit properties of both kinds (and -moz properties of both kinds, and -msie properties of both kinds, last I checked).
> if you want to analyze Apple's source and point out where their site breaks standards
For example, by using Apple's proprietary "3d transforms" extensions to CSS, which are not a standard of any sort.
No, this is all about making it seem like other browsers need to play catchup when in fact they may be ahead of you on actually implementing HTML5. You do that by putting out a demo that doesn't really demo HTML5 much and calling it an HTML5 demo.
> Actually they tried to be open and cutting edge,
No, they very purposefully tried to create the impression that "HTML5" support in other browsers is worse than in Safari (which happens to be not true, if you actually look at HTML5 instead of the things Apple decided to demo).
In other words, this is a pure deceptive marketing ploy, and deserves to be called out as such.
But the point is that the demos are using random proprietary Safari features that are not part of HTML5, not planned to be a part of it, and will never become a part of it (for example, because they're CSS features, not HTML ones). So calling it a demo of "support for HTML5" is just a bald-faced lie. Call it "support for some stuff we made up", which is what it is, and no problem.
The only problem with this line of reasoning is that if you actually _look_ at the demos:
1) Most of what's involved isn't parts of HTML5 _or_ proposals for HTML5.
2) Some of the things involved are "proposals" that they submitted (something anyone can do
anytime) to the CSS working group and that no one else is really interested in so far
last I heard.
There's no problem publishing demos that only work in your browser due to you using proprietary things you added to your browser. The problem is calling that sort of thing "HTML5" and making it sound like it's a standard or likely to become one soon.
> What agenda is that, beyond making HTML5 more functional and useful for media and Web apps?
Controlling all content delivery to as many users as it can manage. Replacing as many web apps as it can get away with with iPhone apps. Making sure that as much of the mobile web as possible only renders well in their browser (hence recommending that people effectively design sites wrong then use -webkit-* properties that are only supported in Mobile Safari, not even desktop Safari, to "fix" the rendering for Apple's mobile devices).
That sort of thing, in addition to the agenda you listed.
> HTML5 does not have the capability to access the webcam and the microphone on the desktop.
It's coming. See http://www.w3.org/TR/capture-api/ and I know Gecko is experimenting with this sort of thing.
> Multi-file upload:
In the HTML5 draft and supported in Firefox 3.6, at least. See http://hacks.mozilla.org/2009/12/multiple-file-input-in-firefox-3-6/
To summarize, you do in your source, and you're done.
It also uses broken browser-sniffing, so it's not possible to easily test what it would behave like on development Firefox versions....
I should clearly have quoted more of grandparent's post. He was specifically wanting to run JavaScript in the Mozilla JS interpreter, not the Mobile Safari one.
The poster was specifically talking about doing it "via Mozilla". And a JavaScript interpreter (other than the one Apple ships) is one of the things you are NOT allowed to ship on iPhone OS by Apple. Nor can you ship an interpreter of any other kind. It's not clear to me that even an XSLT implementation would be acceptable (since XSLT is a Turing-complete functional language).
So you could not in fact use Mozilla's JavaScript interpreter on iPhone or iPad.
> It would be nice if we could run javascript/html5/css3 code on Apple products
Apple's terms of service for the iPhone and iPad prohibit just this, so it's not likely barring an Apple policy change.
> Will it require something on my desktop that then sends all the information from my
> browser to their servers?
Yes (though note https://wiki.mozilla.org/Labs/Weave/Crypto for details; the only data the server sees is an encrypted blob).
> Does firefox do that currently now?
Only if you install the relevant extension. See https://mozillalabs.com/sync/
It depends. "H.264" actually has multiple profiles; for simplicity people usually refer to baseline, main, and high. Baseline is the simplest to encode and decode; high is the most complex. High gives the best results (quality at given bitrate, etc).
Some expert opinion (biased toward H.264 due to being heavily involved with it, but let's start with it) basically comes down to VP8 being probably better than baseline, maybe comparable to main, worse than high.
H.264 on the web is in practice all baseline because that's what phones can typically hardware-accelerate (amongst other reasons), so the other ones would drain your phone battery in a jiffy if you tried to actually play them there.
The upshot of all this is that "codec quality" is hard to define, much less measure... ;)