To be fair, all or almost all of the features Apple (and others) are showcasing do have open specifications at various stages of standardization.
The bad thing about branding them collectively as some sort of "HTML5 standard" is when people start calling other browsers non-compliant with standards that aren't even stable targets yet. Or targeting one browser's draft implementation, without even checking to see which other browsers have comparable support.
This is a major problem for us on the Mobile Firefox team. Since a huge portion of mobile web pages are now targeting WebKit browsers only, it's hard for competing browsers to enter this space. Mobile Safari is the new IE (in the sense that we need to reverse-engineer its non-standard features like meta[name="viewport"] in order to compete with it).
Well the web needed a means of setting the viewport scale, and the one Apple came up with is as good as any.
Are you really insistent that you come op with your own "-moz-viewport" crap just because there isn't a draft standard? The vendor prefix bullshit of the last few years is going to be around for at least another decade, with every CSS3 property being set three goddamn times because the vendors will have shipped support for the prefixed version for several major releases before they think about blessing it. I wish y'all would only do that stuff in beta releases to keep it out of the wild.
Setting the viewport doesn't require anything like trampolining through VBScript, loading an ActiveX control, or calling a DirectX function via VML (all things I've had to do recently). MobileSafari is not the new IE.
Have fun being another legacy browser on a slow release cycle that can't ship a decent mobile browser.
> Are you really insistent that you come op with your own "-moz-viewport" crap just because there isn't a draft standard?
No, we're not insistent. We implemented WebKit's "viewport" meta tag. We can be pragmatic too.
I just wanted to point out one of the many of Safari features that Apple is promoting without writing any specs or standards, and the effect this has on the browser market. Others include touch events, link[rel="apple-X"], -webkit-text-size-adjust...
I agree the proliferation of vendor prefixes in the wild has bad effects, and we are feeling the pain of it too.
----
> Have fun being another legacy browser on a slow release cycle that can't ship a decent mobile browser.
Thanks for the kind words. :) We know we're way behind the game on mobile, and the only thing we can do to fix it is ship great software. I think when you get a chance to see what you can do with add-ons for mobile Firefox, you'll be tempted to switch.
We're on a rough six-month release schedule: Fennec 1.0 shipped in January, Fennec 1.1 will ship this month, and we are targeting this October or November for Fennec 2.0. Look for our first 2.0 alpha release for Maemo and Android in a month or two.
[P.S. I see you're in Seattle too! Want to get together for coffee sometime? Email me if you do.]
> The vendor prefix bullshit of the last few years is going to be around for at least another decade, with every CSS3 property being set three goddamn times because the vendors will have shipped support for the prefixed version for several major releases before they think about blessing it. I wish y'all would only do that stuff in beta releases to keep it out of the wild.
It seems like Mozilla might benefit from developing and promoting tools like Modernizr, to encourage the standard use of feature detection instead of filtering by user agent. Some kind of complimentary repository for web developers to contribute and discuss equivalent rich web app functionality implemented for various browser capabilities, with sample code ensuring compatibility with Firefox, IE and Webkit browsers using Flash fall-backs when needed, would be the bee's knees. The benefit to no one owning the HTML5 standard means that Mozilla can also define it however they want. Given their relative browser market shares, Mozilla's take on the matter carries more weight than Apple's. It's sad to see Mozilla acting threatened by Apple on this, rather than throwing its own weight around, presenting their own case to web developers, and taking advantage of this transition to shiny HTML5 goodness to replace the crusty old user agent string method of compatibility checking with the shiny new hotness of discreet feature detection.
The bad thing about branding them collectively as some sort of "HTML5 standard" is when people start calling other browsers non-compliant with standards that aren't even stable targets yet. Or targeting one browser's draft implementation, without even checking to see which other browsers have comparable support.
Rather, all the draft-N devices I'm aware of interoperated. If you bought a draft-N network card, it didn't stop working the day after they published a new version, as far as I know.
The bad thing about branding them collectively as some sort of "HTML5 standard" is when people start calling other browsers non-compliant with standards that aren't even stable targets yet. Or targeting one browser's draft implementation, without even checking to see which other browsers have comparable support.
This is a major problem for us on the Mobile Firefox team. Since a huge portion of mobile web pages are now targeting WebKit browsers only, it's hard for competing browsers to enter this space. Mobile Safari is the new IE (in the sense that we need to reverse-engineer its non-standard features like meta[name="viewport"] in order to compete with it).