Linked by Kroc Camen on Fri 1st Jan 2010 15:36 UTC
Opera Software HTML5 Video is coming to Opera 10.5. Yesterday (or technically, last year--happy new year readers!) Opera released a new alpha build containing a preview of their HTML5 Video support. There's a number of details to note, not least that this is still an early alpha...
Thread beginning with comment 401964
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Opera....
by tyrione on Fri 1st Jan 2010 20:27 UTC in reply to "Opera...."
tyrione
Member since:
2005-11-21

Seriously... I don't think Opera has a chance in snot of moving out of the basement. The world is moving to webkit/khtml... Browser makers would be well advised to use webkit for rendering and focus on innovating features for the browser like faster JS, more scripting languages, content management features, etc.


The world isn't moving to Webkit/khtml.

The world is moving to WebKit.

Reply Parent Score: 2

RE[2]: Opera....
by wumip on Fri 1st Jan 2010 21:56 in reply to "RE: Opera...."
wumip Member since:
2009-08-20

The world is moving to a bunch of hard-to-manage forks of Webkit.

Reply Parent Score: 0

RE[3]: Opera....
by KugelKurt on Sat 2nd Jan 2010 13:49 in reply to "RE[2]: Opera...."
KugelKurt Member since:
2005-07-06

You keep posting wrong things about WebKit over and over again.
As proof for your accusations, you post links to an article, that merely states the varying degrees of WebKit port quality on different platforms.
I don't know if you don't know better of if you're lying on purpose.
No matter what, here are some facts:

Fact 1:
WebKit is not controlled by Apple.
Apple initiated WebKit and provides the hosting infrastructure. Other than that Apple has no special role in WebKit these days. Apple engineers work together with Google, GNONE, and Nokia ones.
They all have equal rights.
Anyone who reads http://webkit.org/blog/ sees postings about new source code reviewers (with full commit rights) quite regularly.

Fact 2:
Ports are not forks.
You claim that every port equals an fork.
That's not true. The main development branch can be accessed via http://trac.webkit.org/browser/trunk
Platform-specific code is in subfolders http://trac.webkit.org/browser/trunk/WebCore/platform and http://trac.webkit.org/browser/trunk/WebKit
The core code is located in JavaScriptCore and WebCore directories. That one is generic and not platform-specific.

Fact 3:
Quality varies from port to port.
When a vendor releases a browser based on WebKit, it works like this: the main trunk is branched and the vendor focuses his work (bug fixing) on that branch. That's the same for every vendor. Newer ports or branches by smaller vendors may not get as much bug fixing as e.g. the Chrome port by Google.
There may also be bugs in the used toolkit. Those bugs are out of scope to fix for the WebKit project.
Branches are made on a regular basis from the main trunk. A branch does not serve as primary development place for a port.
All big software projects use the trunk/branch development model. It's a proven model and does not equal unmanageable forks.

Fact 4:
Rendering capabilities depend on the graphics library.
WebKit does not have a single, unified graphics library. Gecko for example uses Cairo. Opera uses something proprietary.
If a vendor decides to port WebKit to a new graphics library instead of adapting the graphics library to the platform, regressions may occur.
No vendor is forced to port WebKit to a new graphics library. WebKit has already been ported to Cairo. If a vendor wants to improve on that one, he is free to do so.
Still, most vendors prefer porting to new/native graphics libraries. This reduces memory footprint -- especially important in mobile space. Vendors may see this as more important than 100% compatibility with existing ports.

Reply Parent Score: 2