Chrome runs as close as any browser can to the bleeding edge of Web standards. Though it uses the same open source WebKit rendering engine as Safari, it doesn't reliably support the controversial, proprietary CSS3 transformation and animation tricks that Apple's built into Safari. However, like every browser I tested, it earned a perfect score in a compatibility test for CSS3 selectors, and it joined Safari and Opera with a flawless score of 100 in the Acid3 web standards benchmark. Chrome 5 also supports both Apple's H.264 codec and Mozilla's preferred open source Ogg Theora technology for plugin-free HTML5 video, and it beautifully played back HTML5 demo videos from YouTube and Brightcove.
In XHTML and CSS tests, Chrome was surprisingly slower than Safari, despite their shared rendering engine -- but the race was close. Safari rendered a local XHTML test page in 0.58 seconds to Chrome's 0.78 seconds, and a local CSS test page in 33 milliseconds to Chrome's 51 milliseconds. Note that Chrome still rendered XHTML more than twice as fast as Opera (1.67 seconds) and left Firefox (12.42 seconds--no, that's not a typo) eating its dust. In CSS, it also beat the pants off Opera (193 milliseconds) and Firefox (342 milliseconds).
But Chrome shines brightest when handling JavaScript. Its V8 engine zipped through the SunSpider Javascript benchmark in 448.6 milliseconds, narrowly beating Opera's 485.8 milliseconds, and absolutely plastering Firefox's 1,161.4 milliseconds. However, Safari 5's time of 376.3 miliseconds in the SunSpider test beat Chrome 5 handily.
Return to the bad old days
Many of Apple's demos rely on "experimental" CSS3 properties to work. The exact implementation of these properties has yet to be hammered out, so browser vendors must use their best guess to determine how they should be rendered onscreen. Because of the ambiguity this introduces, it is the custom for browser vendors to attach a vendor-specific prefix to the CSS property names. Firefox uses "moz," while Safari uses "webkit," named for the browser's WebKit rendering engine.
This means Web developers who want to use a specific experimental CSS feature must include the vendor-specific properties for each browser they want to support in their style sheets. It's a less than ideal situation, but the actual coding required is trivial. Apple chose not to bother for its HTML5 demo site.
That would be bad enough. But Apple's demos don't work on Google's Chrome browser, either -- and Chrome also uses the "webkit" prefix for its experimental CSS3 properties (because it's also based on the WebKit rendering engine). Rather than detecting browser capabilities and degrading the user experience gracefully where features aren't supported -- as is the accepted best practice on modern browsers -- Apple chose to deliberately screen out any browser that doesn't self-identify as Safari.
That's right: By forcing my browser's user agent string to identify as Safari 5, I was able to view many of the demos just fine in Firefox 3.6 on Windows. Seriously, Apple? I thought we left elaborate browser-detection scripts behind in the bad old days of the 1990s. I can't imagine anyone would want to start up the practice again, let alone one of the leading companies in the development of next-generation Web standards.
Interesting development in the world of real time Web Apps. Looks like Business processes and services in the Cloud are embracing HTML5, and moving fast to replace legacy client/server. Note this is not Flash or Silverlight RiA.
excerpt:
Telax Hosted Call Center, a leader in cloud contact center solutions announced the release of its HTML5-based Call Center Agent (CCA) today. Key to the development of the browser-based CCA was Websocket, a component of HTML5 that provides a bi-directional, full-duplex communication channel over a single Transmission Control Protocol (TCP) socket. Websocket is currently supported by the latest versions of Google Chrome, Apple Safari, and Firefox, making Telax's new CCA compatible with the most popular browsers in Mac environments.
Before HTML5, real-time unified communication software was typically deployed as a local client because its browser-based counterparts were unable to deliver an acceptable user experience. Some browser-based clients use 3rd party software such as Adobe Flash or Sliverlight to operate adequately, but both solutions require software installation and are not mobile friendly.
"FREQUENTLY ASKED QUESTIONS
What is WhiteHat Aviator?
WhiteHat Aviator; is the most secure , most private Web browser available anywhere. By default, it provides an easy way to bank, shop, and use social networks while stopping viruses from infecting computers, preventing accounts from being hacked, and blocking advertisers from invisibly spying on every click.
Why do I need a secure Web browser?
According to CA Technologies, 84 percent of hacker attacks in 2009 took advantage of vulnerabilities in Web browsers. Similarly, Symantec found that four of the top five vulnerabilities being exploited were client-side vulnerabilities that were frequently targeted by Web-based attacks.
The fact is, that when you visit any website you run the risk of having your surfing history, passwords, real name, workplace, home address, phone number, email, gender, political affiliation, sexual preferences, income bracket, education level, and medical history stolen - and your computer infected with viruses. Sadly, this happens on millions of websites every day. Before you have any chance at protecting yourself, other browsers force you to follow complicated how-to guides, modify settings that only serve advertising empires and install obscure third-party software.
What makes WhiteHat Aviator so secure?
WhiteHat Aviator; is built on Chromium, the same open-source foundation used by Google Chrome. Chromium has several unique, powerful security features. One is a "sandbox" that prevents websites from stealing files off your computer or infecting it with viruses.
As good as Chromium is, we went much further to create the safest online experience possible.
WhiteHat Aviator comes ready-to-go with hardened security and privacy settings, giving hackers less to work with. And our browser downloads to you - without any hidden user-tracking functionality. Our default search engine is DuckDuckGo - not Google, which logs your activity. For good measure, Aviator integrates Disconnect
The demo movie above from Adobe shows off some WebKit-based experiments that seek to change that. Adobe Engineering VP Paul Betlem narrates and the demo, and he shows how his team is extending the WebKit browser to do some new typographic tricks. WebKit is the open source engine behind Safari and Google Chrome, and it powers the most popular mobile browsers like the ones on the iPhone, iPad, iPod and all the Android phones. The demo certainly shows some impressive results.
However, we're a bit suspicious of the methodology behind the results. Betlem talks about extending WebKit's CSS support via vendor prefixes, but neglects to mention what those prefixes are built against - in other words, there's no mention of submitting a standard that other browsers could work from.
Wow! This reads like a premature press release, but if true it's breakthru technology. I wonder though why Ericom is targeting education? Seems this innovation would be of immediate importance to enterprise and SMB businesses struggling with the great transition from desktop/workgroup productivity systems to Web Productivity Platforms.
excerpt: Ericom has released AccessNow, a pure HTML5 remote desktop (RDP) client that runs within a Web browser without the need to install anything on the client device.
AccessNow provides accelerated remote access to applications and desktops running on Windows Terminal Services, remote desktop services (RDS), and virtual desktop infrastructure (VDI), including applications, remote desktops, VMware View desktops, virtual desktops running on Microsoft Hyper-V, and other hypervisors.
AccessNow works on any device with an HTML5-capable browser, such as Chrome, Safari, Firefox, Opera, and others, without the use of browser plugins, Java, Flash, ActiveX, Silverlight, or other underlying technology. Internet Explorer is also supported, although it does require the Chrome Frame plugin. AccessNow uses only the standard Web technologies: HTML, CSS, and JavaScript.
This approach helps IT administrators maintain centralized control of school resources. It also enables students and staff to use any Internet-enabled device, including smartphones, tablets, and Chromebooks, to do their work anywhere and anytime.
While HTML5 developers are working directly with JavaScript, SVG, CSS, and other technologies, Flash designers enjoy a high-level environment with timelines, drawing tools, easy control of animation effects, and more. With Edge, released in beta Sunday, Adobe is striving to bring that same ease of use to HTML5 development.
The user interface will be familiar to anyone who's used Flash or After Effects; a timeline allowing scrubbing and jumping to any point in an animation, properties panels to adjust objects, and a panel to show the actual animation. Behind the scenes, Edge uses standard HTML5. Scripting is provided by a combination of jQuery and Adobe's own scripts, and animation and styling uses both scripts and CSS. Pages produced by Edge encode the actual animations using a convenient JSON format. Edge itself embeds the WebKit rendering engine-the same one used in Apple's Safari browser and Google's Chrome-to actually display the animations.
Great title, no substance. But who can pass this up? Even if it's been obvious since the 2007 release of the iPhone. WebKit Rules the Edge of the Web today! Tomorrow, the greater Web will follow.
Excerpt: There are a lot of brave souls out there making mobile browsers, hoping to gain traction with the phone makers. But most of them are fighting a losing battle, for the mobile browser war is increasingly being fought between two camps - the Webkit-based browsers camp, which includes Safari on the iPhone, the Google Android Browser, the Palm browser and the Nokia browser; and the Opera camp.
Swiffy converts Flash SWF files to HTML5, allowing you to reuse Flash content on devices without a Flash player (such as iPhones and iPads).
Swiffy currently supports a subset of SWF 8 and ActionScript 2.0, and the output works in all Webkit browsers such as Chrome and Mobile Safari. If possible, exporting your Flash animation as a SWF 5 file might give better results.
Upload a SWF file
Net Application’s numbers for October show another loss for IE, down 0.39 points or 0.65% to 59.26%, the lowest number in, as far as we know, in at least 12 years. Firefox dropped as well, down to 22.82%, which is a 15 month low for Mozilla. The clear winner in October was Google, which saw its Chrome browser blow past the 8% barrier and landed at 8.47%, a gain of 0.49 points or 6.14% over September. Safari gained slightly and is now at 5.33% and Opera continued its zig-zag pattern and was down a bit to 2.28%.
StatCounter is also out with market share numbers. As usual, the numbers deviate from Net Applications’, but the trend is comparable. Chrome, by the way, is listed by StatCounter with 12.39% market share, Firefox with 31.24% and IE with 49.22%.
The interesting part about StatCounter is the geographic breakdown. While North America still loves IE, Europe does not – and this is critical for Microsoft as there are more Internet users in Europe than in North America. On these shores, there is a good distance between IE and Firefox, but Firefox has caught up with IE in Europe, even if Firefox has turned into a slight decline over there as well. IE is now a 39.53% in Europe and Firefox at 38.65%. Firefox is losing market share not quite as fast as IE and could become Europe’s most popular browser by the end of the year. The big winner, however, is also Chrome – which is now listed at 12.28%.
The Worldwide Web Consortium has released the results of its first HTML5 conformance tests, and according to this initial rundown, the browser that most closely adheres to the latest set of web standards is...Microsoft Internet Explorer 9.
Yes, the HTML5 spec has yet to be finalised. And yes, these tests cover only a portion of the spec. But we can still marvel at just how much Microsoft's browser philosophy has changed in recent months.
The W3C tests — available here — put IE9 beta release 6 at the top of the HTML5 conformance table, followed by the Firefox 4 beta 6, Google Chrome 7, Opera 10.6, and Safari 5.0. The tests cover seven aspects of the spec: "attributes", "audio", "video", "canvas", "getElementsByClassName", "foreigncontent," and "xhtml5":
The tests do not yet cover web workers, the file API, local storage, or other aspects of the spec.
W3C is warning against drawing any conclusions based on the early tests, saying thousands of more HTML5 tests are planned. The goal of the tests is not to declare one browser a winner, but rather to help vendors and Web application
developers ensure interoperability across all browsers, W3C says.
"We do expect to have tens of thousands of tests," says Philippe Le Hegaret, who oversees HTML activities for the W3C.
the purpose of the HTML5 test suite is to help
vendors and developers ensure that HTML5 applications work across all browsers. For example, a developer might check the test
results before enabling a certain feature in an application, just to make sure it will work across IE9, Firefox, Chrome, Safari
and Opera.
Developers can build HTML5 applications today, but they have to keep in mind that they are early adopters and act accordingly,
Le Hegaret says.
"If you think HTML5 is perfectly stable today and you can use it without worrying about interoperability issues, I think you're
going to fool yourself," he says.
Although the first round of HTML5 tests focused on desktop browsers, Le Hegaret says HTML5 compatibility is advancing more
rapidly on mobile devices such as iPhones and Androids.
Note the continuing, indeed, escalating abuse of the term "interoperability" by W3C. "Interoperability" has both a legal and (happily, coinciding) technical meaning that involves round-tripping of information. ISO/IEC JTC 1 Directives defines the term in precisely the same terms as the European Union's Court of First Instance did in the landmark Commmission v. Microsoft antitrust case; "interoperability is understood to be the ability of two or more IT systems to *exchange* information at one or more standardised interfaces and to make *mutual use* of the information that has been exchanged."
Web browsers do not do "interoperability;" there is no "exchange" and "mutual use" of the information exchanged. Web browsers do "compatibility," a one-way transfer of information that is broadcast from web servers; i.e., web browsers cannot send web pages to web servers.
excerpt: As you might know, WebKit Web Inspector is implemented as an HTML + CSS + JavaScript web application. What you might not know is that Web Inspector can run outside of the browser environment and still provide complete set of its features to the end user.
Debugging over the wire
Running debugger outside the browser is interesting because mobile platforms do not often provide enough screen real estate for quality debugging; they have network stack and CPU specifics that often affect page load and runtime. Still, they are based on the WebCore rendering engine, they could have Web Inspector instrumentation running and hence expose valuable debugging information to the end user. Now that Web Inspector is functioning out-of-process over the serialized-message-channel, attaching Web Inspector window to the remote browser is possible. Here is an example of the remote debugging session using Chromium:
1. Start your target browser with the remote-debugging-port command line switch:
Chromium --remote-debugging-port=9222
Microsoft’s browser-based operating systemGet this: The entire Metro interface — the complete Windows 8 front-end — is powered by Internet Explorer 10. Not the browser with a back button and an address bar, but the IE10 rendering engine Trident. To drive this point home, Metro-style apps in Windows 8 can be written in HTML, CSS, and JavaScript, and they will be just as “low-level” as their C++ and C# cousins. In other words, Windows 8 runs web apps natively.
To put this into contrast, think about the current state-of-the-art in Chrome, Firefox, and Internet Explorer 9. Chrome has glorified extensions and bookmarks, Firefox is working on an Open Web App Store, and IE9 has pinned sites. Windows 8 will have web apps that are first-class citizens, capable of using all of the same hardware resources as any other compiled program — and it will all be powered by Internet Explorer 10.
It’s the great Web App Dream: write once, run anywhere.
What if Windows 8 is actually a success on the tablet? If Windows 8 becomes ubiquitous, so does Internet Explorer 10 — and if IE10 can be found on hundreds of millions of devices, what platform do you think developers will choose?
This poses a tricky question, though. You see, not only does IE10 power Windows 8′s primary interface, but Internet Explorer 10 — the browser — is also available as a Metro-style app, and as a full-interface browser in the Explorer Desktop.
Do you write an app for tens of millions of iPhones and iPads, or do you write a single piece of HTML, CSS, and JavaScript that can run perfectly on every Windows 8, IE10-powered tablet, laptop, and desktop?
Those same web apps, with a little tweaking, will probably even work with Chrome and Firefox and Safari — but here’s an uncomfortable truth: if Windows 8 reaches 90% penetration of the computing market, why bother targeting a web browser at all? Just write a native, Metro-style web app instead.
Finally, add in the fact that IE10 will almost certainly come to Windows Phone 8 next year, and you will have a single app container — AppX — that runs across every damn computer form factor.
Microsoft, threatened by the idea of OS-agnostic web apps and browser-based operating systems from Google and Mozilla, has just taken the game to a whole new level — and, rather shockingly, given that Windows 8 started its development in mid-2009, it would seem that the lumbering behemoth might have actually out-maneuvered Google
Excellent review of Windows 8, including some prescient thinking about what it means to have HTML+ Web Apps running natively on the Win8 OS platform. The author/reviewer Sebastion Anthony suggest why this breakthrough is a problem for Google, Apple and Mozilla. I'm wondering though; is this a problem for the Open Web future? Or is this a positive step towards an Open Web communications and collaborative computation platform that is used by all and owned by none?
After nearly thirty years of a love-hate-hate more than ever relationship with Microsoft, for sure Win8 and native HTML+ is something to carefully watch.
Last week I wrote about the benefits of open standards versus open source. I argued that open standards provide greater protection against vendor lock-in than open source alone. I was reminded of this conclusion when reading Peter-Paul Koch's analysis of WebKit implementations. Thanks to Palm's Dion Almaer for pointing out the analysis. Readers know WebKit as the open source Web browser engine used by several mobile and PC Web browsers, including Apple's Safari, Google's Chrome, Palm's WebOS, and the Android Web browser. In fact, Wikipedia lists 19 browsers based on the open source WebKit browser engine. As you read on, keep in mind there is no standard that vendors using WebKit must adhere to or claim certification against. A WebKit-based browser is, well, whatever the vendor wants it to be.
Imagine if there were a WebKit standard and a compliance test suite that vendors had to certify against to use the WebKit brand. Customers and developers would gain protection against vendor lock-in that open standards deliver to a much higher degree than open source alone. I'm not naive enough to think that open standards equal "write once, run anywhere." But even if a WebKit open standard could drive a 50 percent improvement in compatibility across WebKit-based browsers, that would be something to write home about.
Microsoft might be hesitating on Scalable Vector Graphics (SVG) in Internet Explorer 8, but Google's pressing on.
The search giant's engineers are building a JavaScript library to render static and dynamic SVG in Microsoft's browser. Google promised that the library, a Javascript shim, will simply drop into IE.
SVG has a huge presence on the web. This facet of the World Wide Web Consortium's HTML 5 spec is supported in Firefox, Safari, Opera, Chrome, and Apple's iPhone, and is used in Google Maps and Google Docs. It also topped a list of features wanted by developers in a OpenAJAX browser wish list last year.
There's suspicion, though, that the reason has more to do with Microsoft's internal politics, with the company wanting graphics and drawing in IE done using Silverlight instead.
SVG Web is more than an answer to Microsoft's foot-dragging, however. Google has declared for HTML 5 on the web, proclaiming last week that the web programming model has "won".
Support for graphics capabilities in HTML 5 should also be seen as Google's partial answer to Adobe Systems' Flash. Google has complained that Flash is not open source and its development is not driven by the community. Google said the benefit of SVG Web is that it would sit inside the DOM whereas Flash "sits on top of the web, it's not part of the web"
With millions of iPhones out there, it makes sense to have your content, or application available on that platform, but how do you go about doing this? Where do you go to get started? And what are the steps you need to take to get there?
This article from interface designer, Etan Rozin, is an introduction to the various ways of getting content and applications onto the iPhone. It is by no means a full guide, but hopes to point you in the right direction and give you an overview of what is involved in the process.
Excellent explanation and collection of valuable resources!
So it makes sense that Firefox 3.5 called its rendering engine TraceMonkey, and with it has made the browser more than twice as fast as Firefox 3, by our own measurements. Using the SunSpider Javascript benchmark tool on a Windows PC, Firefox 3.5 scored 1,426ms, which is significantly faster than Firefox 3 which scored 3,250ms. Safari 4 and Chrome 2 scored 910ms and 709ms respectively. The average user will not find the previous version slow, and so may not notice version 3.5 working much harder. But it is, and pages are loading closer to the speed of Chrome now.
A nascent technology called WebGL for bringing hardware-accelerated 3D graphics to the Web is getting a lot closer to reality.
Last week, programmers began building WebGL into
Firefox's nightly builds, the developer versions used to test the latest updates to the open-source browser. Also this month, programmers began building WebGL into WebKit, the project that's used in both Apple's
Safari and Google's Chrome.
Wolfire Games picked up on the WebKit move and offered a video of WebGL in action.
Even the company with the most to lose from that direction--Microsoft--is embracing it with a Web-based version of Office
Although Google is a WebGL supporter, it's also developing a higher-level 3D graphics technology called O3D for browsers. Google is working on building O3D into Chrome, but the fruits of that labor aren't yet available.
YouTube has decided it's had enough of Adobe's perenially-p0wned Flash and will therefore now default to delivering video with the HTML5 <video> tag.
A post by the video vault's engineering and development team says the move is now possible, and sensible, because the industry has invented useful things like adaptive bitrates, encryption, new codecs and WebRTC that make the <video> usable work in the real world.
Those additions mean HTML5 is at least as functional – or more so – than Flash, and if YouTube detects you are running Chrome, IE 11, Safari 8 and beta versions of Firefox, it'll now deliver video using <video> and flush Flash.
YouTube's also decided to can what it calls the “'old style' of Flash
YouTube seems not to care a jot that its actions are inimical to Adobe, saying it's just doing what all the cool kids – Netflix, Apple, Microsoft and its competitor Vimeo – have already done.
Which is not to say that Flash is dead: those who don't run the browsers above will still get YouTube delivered by whatever technology works bes tin their environment. And that will often – perhaps too often* – be Flash. ®
Bootnote * Until they get p0wned, that is: Flash is so horridly buggy that Apple has just updated its plugin-blockers to foil versions of the product prior to 16.0.0.296 and 13.0.0.264.
Gary Edwards on 23 Jun 10Chrome runs as close as any browser can to the bleeding edge of Web standards. Though it uses the same open source WebKit rendering engine as Safari, it doesn't reliably support the controversial, proprietary CSS3 transformation and animation tricks that Apple's built into Safari. However, like every browser I tested, it earned a perfect score in a compatibility test for CSS3 selectors, and it joined Safari and Opera with a flawless score of 100 in the Acid3 web standards benchmark. Chrome 5 also supports both Apple's H.264 codec and Mozilla's preferred open source Ogg Theora technology for plugin-free HTML5 video, and it beautifully played back HTML5 demo videos from YouTube and Brightcove. In XHTML and CSS tests, Chrome was surprisingly slower than Safari, despite their shared rendering engine -- but the race was close. Safari rendered a local XHTML test page in 0.58 seconds to Chrome's 0.78 seconds, and a local CSS test page in 33 milliseconds to Chrome's 51 milliseconds. Note that Chrome still rendered XHTML more than twice as fast as Opera (1.67 seconds) and left Firefox (12.42 seconds--no, that's not a typo) eating its dust. In CSS, it also beat the pants off Opera (193 milliseconds) and Firefox (342 milliseconds). But Chrome shines brightest when handling JavaScript. Its V8 engine zipped through the SunSpider Javascript benchmark in 448.6 milliseconds, narrowly beating Opera's 485.8 milliseconds, and absolutely plastering Firefox's 1,161.4 milliseconds. However, Safari 5's time of 376.3 miliseconds in the SunSpider test beat Chrome 5 handily.
