Opera announces 'gradual transition' to WebKit for desktop and mobi


Recommended Posts

Yeah... forking is unlikely.. riiiight.. you'll see when browser vendors start forking edge features and implementing WHATWG new stuff however they want while W3C takes another 10 years to get everyone on board with snapshots while in the meantime we'll have each browser treating new features however they want and dealing with previous browser versions supporting certain sets of features as they will not really be standard.

How this is great is beyond any reason.

:facepalm:

they are still going to fork and fragment webkit. especially when webkit refuses to fix known bugs for years.

If all browsers used the same engine then they would all have to come to an agreement on new features and how they would be implemented. If one teams did not like it or wanted a feature others didn't, they would fork it and implement it how they wanted and you would have a mess of prefixes and features again.

What does any of this have to do with the fact that Google does not own Webkit?

Flash is still years ahead of HTML5. It's far better. Google also supports Flash by default because they recognize that..

No, they support Flash because it's still used everywhere on the web, and it's part of their distribution contract with Adobe where Adobe bundles Chrome with Flash, and Google bundles Flash with Chrome.

W3C actually worked with WHATWG on HTML5 and now they are split.. WHATWG will be introducing new features going forward while W3C will then evaluate whether or not those features will be implemented into standards. Which means fragmentation going forward because WHATWG will be introducing features that are NOT standard.

...

You're still not getting it. The WHATWG version of HTML is the standard, all the W3C is managing now is creating stable snapshots so people have something to point to and say "This is part of HTML5", etc. The W3C stopped managing HTML around the time they started work on XHTML2, and when work on that stopped they handed control of HTML to the WHATWG.

It's similar to how the W3C doesn't control JavaScript, or image formats, or video formats, or WebGL, etc.

You're still not getting it. The WHATWG version of HTML is the standard, all the W3C is managing now is creating stable snapshots so people have something to point to and say "This is part of HTML5", etc. The W3C stopped managing HTML around the time they started work on XHTML2, and when work on that stopped they handed control of HTML to the WHATWG.

It's similar to how the W3C doesn't control JavaScript, or image formats, or video formats, or WebGL, etc.

What you just said is exactly that.. "This is part of HTML5" is when those new features become part of the HTML spec, until then they are not part of the spec at all (they are really forked) and can be implemented however browser vendors want (prefixes and similar). WHATWG is NOT standards body. It's a community of people and companies who come up with ideas that should go in HTML and everyone can contribute and that's it.

what's the difference between a "snapshot" and new features WHATWG introduces? You are claiming that what WHATWG comes out with is the standard and that's not really true. When W3C adds them to officially be a part of the HTML spec is when it becomes part of the standard.

Let me just get this for the record. Are you saying that 100% of things that WHATWG comes up with will be part of HTML spec for sure. There is absolutely no guarantee of that. Furthermore, even if it will become part of the standard WHATWG will be dealing with new features much faster and add more features that browsers like Chrome or Firefox will introduce while Microsoft might choose not to until it is officially a part of the spec and thus creating similar situation we have now with HTML5 and fragmentation.

This is a good take on the whole W3C and WHATWG split

http://www.i-program...-w3c-split.html

Clearly as Webkit is behind supporting finalised standards such as the CSS3 backgrounds and borders module, browser vendors should abandon Webkit and switch to Trident.

Microsoft control the desktop OS market, so clearly they should be the ones to dictate the future of the web too.

Yeah that worked out really well with IE6 :rolleyes:

Yeah that worked out really well with IE6 :rolleyes:

Funny how the so called "open source" engine is behind Trident in terms of standards support. So much for that openness.

Then again, Gecko has support too and that's open. I guess Webkit must not be as open as people claim then. ;)

Funny how the so called "open source" engine is behind Trident in terms of standards support. So much for that openness.

Then again, Gecko has support too and that's open. I guess Webkit must not be as open as people claim then. ;)

Funny, because Chrome is still ahead of IE10 on most HTML5 feature subsets (320 vs 468 on the HTML5 test) a difference of 46%

Also wins by a margin of 151 (out of 160) to 127 on this test:

http://wapsbttest2.m...net/html5/test/

And just FYI, no browser (still) has full HTML 5 support, and unlike Microsoft it's not taking Google and Mozilla a year for each new version, Chrome specifically is being developed very quickly. Eventually Microsoft's strategy will leave them always being 1 step behind.

Funny, because Chrome is still ahead of IE10 on most HTML5 feature subsets (320 vs 468 on the HTML5 test) a difference of 46%

Also wins by a margin of 151 (out of 160) to 127 on this test:

http://wapsbttest2.m...net/html5/test/

And just FYI, no browser (still) has full HTML 5 support, and unlike Microsoft it's not taking Google and Mozilla a year for each new version, Chrome specifically is being developed very quickly. Eventually Microsoft's strategy will leave them always being 1 step behind.

Ah I see, you're not an actual developer. If you were you'd realise that HTML5Test is completely useless for measuring compliance. (There is a reason why the education system has exams, and doesn't qualify based on what someone claims they know)

Like a myriad of other people have already said in this thread.

Phalluswaving so-called compliance tests doesn't address my point anyway. Webkit is significantly behind implementing support for a finalised standard. (And this is not the only case) If all your guff about Webkit's openness meant a damn thing (it doesn't), then such situations would not occur.

Sorry, I side with actual evidence over corporate shills. The evidence tells me that Chrome has better support for HTML5 and what's more I never run into problems with it.

Sorry, I side with actual evidence over corporate shills. The evidence tells me that Chrome has better support for HTML5 and what's more I never run into problems with it.

Or we could listen to http://samples.msdn....m/ietestcenter/ which tells me that IE10 has the best HTML5 support O.O

did you read the notice below the test results you posted?

The HTML5 test score is only an indication of how well your browser supports the upcoming HTML5 standard. It does not try to test all of the new features offered by HTML5, nor does it try to test the functionality of each feature it does detect. Despite these shortcomings we hope that by quantifying the level of support users and web developers will get an idea of how hard the browser manufacturers work on improving their browsers and the web as a development platform.

The score is calculated by testing for the many new features of HTML5. Each feature is worth one or more points. In some cases the tests go beyond the specification. In the case of audio and video there is are also specific tests for codec support. In these cases the most points are awarded for supporting the first codec. Each additional codec it supports does result in a couple of bonus points. Apart from the main HTML5 working draft, this test also awards points for supporting related drafts published by the W3C, such as Geolocation, Web SQL Database, Web Workers and many more. In the future new tests will be added for the pieces of the specification that are currently still missing. The maximum number of points that can be scored is 160 at this moment, but this is a moving goalpost.

It isn't a real representation of how well a browser supports HTML5, it's a combination of what the browser say they support, how important the site's author decides each feature is, and what the site's author wants to pick & choose to be included in the "spec"

Sorry, I side with actual evidence over corporate shills. The evidence tells me that Chrome has better support for HTML5 and what's more I never run into problems with it.

Same can be side with IE9/10 from a users point of view and even from a dev point of view.

HTML5 support is the art of foolishness. It is not that the goals of HTML5 are a bad thing, but the whole process and definition are at the heart of what is wrong with web standards.

Boz here likes to keep citing multi-vendors using their own engines as the root of the problem, but that goes to his lack of understanding of how standard bodies are supposed to work. Chrome is a symbol of the issues as well, and all of the "open web" developers as well.

The root of the issue is the lack of iterative standards that can be targeted properly. The lack of focus on getting browser vendors to fix the bugs for the HTML version targeted. The political discourse of the W3C bodies that make it inept to formalize a standard in an actual timetable that would be suitable for developers. The lack of control over the whole process. The disregard for backwards compatibility and the stale and fluent nature of the web.

If we just go to Wifi, there are 8 standards that have passed in the last 10 years. "Draft devices" were released as experimental implementations of the standards but usually upgraded to comply, or were clearly labeled as such for consumers to know it is not fully meeting standards. That is 8 standards passed without a major complication like web standards from multiple vendors with multiple implementations that conform to the standard.

What everyone here likes to ignore is that there is a difference between a standard and an implementation. However, you cannot have a good implementation if you do not force compliance through some kind of certification process. It is the crown achievement of Windows that they forced all the OEMs in the industry to confirm to the Windows logo and they kept making that process more strict to increase the quality of the hardware and drivers. You do not have that on the web. There is no certification process that deems this browser to meet the actual standard. Partially, because the W3C has a horrible definition of what becomes standard that takes years to meet "recommendation" status. This is the central argument to Microsoft who knows you cannot force the expense of e-commerce business to change their sites just so your browser can use a new feature. There has to be tests, certifications, and a finalized agreement of what that standard is.

The WHATWG coming up with the absurdity of calling everything HTML5 with no versioning control of the release is a great example of how broken the process is. I understand the idea of using a main branch of code like trunk, default, main, etc. to be where all features get developed but eventually there needs to be a tag that says this is HTML5.1, and now HTML5.2, etc. so that you can target the feature set and code properly to that standard. Though it does look like they have finally come up with a roadmap to get there, we will see.

I know people want to think with one engine you can enforce a perfect implementation, but you can only do that if all the parties are aligned with the same interests. Multiple companies being involved means there is no alignment. Google has WebM interests for video codec, Apple has H.264 and I'm sure H.265 interests and Microsoft has same interests as Apple in that regard since giving up their own codecs. That is just one aspect of the HTML 5 specification that has been at odds. Microsoft had a simple solution, support all of them so long as someone installs the codec. These interests will continue and grow to divide a "unified Webkit" as new innovations come about. Look at WebRTC. People look at Microsoft with disdain for daring to come up with something better which to me means anti-corporate.

And I just love all of these anti-corporate, propriety lingo from people who do not understand that your standard of living is better because of those evil corporations. Go away with that crap.

  • Like 2

<snip>

I don't disagree with you at all libertas83.. actually most of what you wrote I agree with 100%. I personally think that if browsers were unified under one rendering engine and that rendering engine was passed onto W3C or an official body that would standardize how things are rendered and actually made sure that each release is compliant with the latest spec would be something close to what you are saying there.. some level of certification in the process. There's no guarantees either way but it would eliminate corporate interests that browser vendors push now by developing their own browsers.

Sorry, I side with actual evidence over corporate shills. The evidence tells me that Chrome has better support for HTML5 and what's more I never run into problems with it.

Yet you're the one here on Google's paycheck. (See what I did here)

It's a shame your opinion can be bought for so little Javik, or maybe it's that you're too ignorant of the facts (And have to rely on facile point scores) to see the truth - Webkit is the new IE6.

  • Like 1

Not sure if having the same browser source code as IE someday is a very secure feeling. Now I don't know **** about code and programming like you guys but wouldn't a unified browser source code engine be more susceptible to virus attacks.

I don't disagree with you at all libertas83.. actually most of what you wrote I agree with 100%. I personally think that if browsers were unified under one rendering engine and that rendering engine was passed onto W3C or an official body that would standardize how things are rendered and actually made sure that each release is compliant with the latest spec would be something close to what you are saying there.. some level of certification in the process. There's no guarantees either way but it would eliminate corporate interests that browser vendors push now by developing their own browsers.

Ever heard of Amaya?

Ah I see, you're not an actual developer. If you were you'd realise that HTML5Test is completely useless for measuring compliance. (There is a reason why the education system has exams, and doesn't qualify based on what someone claims they know)

Like a myriad of other people have already said in this thread.

Phalluswaving so-called compliance tests doesn't address my point anyway. Webkit is significantly behind implementing support for a finalised standard. (And this is not the only case) If all your guff about Webkit's openness meant a damn thing (it doesn't), then such situations would not occur.

To explain why half these tests suck for the people playing along at home, they test whether a browser claims to support a feature, not if the feature actually works. The Acid3 test did some similar things with SMIL/SVG Fonts support, WebKit implemented just enough of both specs to pass the test, but not much more (i.e. WebKit claimed to support some of SMIL, but trying to use it would fail, and SVG Fonts worked just enough to pass the test, but not use on any web pages, etc.)

one rendering engine = no competition

You need competition to make developers develop.

When the race is over, everybody stops running...

The competition should be in the browser features, things they might could add to stand out from the crowd. Much like Android phone makers do with different interfaces and whatnot. The underlying core is still Android. I don't see having one rendering engine as doing away with competition. It means everything on the web renders the same for everyone.

The competition should be in the browser features, things they might could add to stand out from the crowd.

I don't follow this all too closely, so feel free to correct me, but aren't browser makers really trying to do away with all that stuff, and instead focus on improving the JavaScript/HTML support & performance? I mean, when Chrome first came out wasn't its big plus that it had an extremely fast core, and then only the most basic rest of the browser (password support, cross-device syncing, favorites, etc.)? If all browsers have the same rendering engine, and that causes them to implement more of these "extras," I'm not sure if I'd really appreciate that.

Much like Android phone makers do with different interfaces and whatnot. The underlying core is still Android. I don't see having one rendering engine as doing away with competition. It means everything on the web renders the same for everyone.

This part reminded me of an (admittedly unrelated) WIRED article I read a little while ago - http://www.wired.com...saving-android/ - that complained about the way Google was allowing that.

On top of that, taking the Android example a bit further, wouldn't the rendering still be dependent on what version of WebKit the browser maker is using? For example, what if Google wants to auto-update Chrome to the latest versions of WebKit, Microsoft wants to wait until it's been tested on all the other major browsers and then do updates once every few months, and Apple wants to update somewhere in between? Then wouldn't we have the same kind of fragmentation that's so prevalent on Android devices - large groups of devices running different versions of the same software, that's been modified so much by the OEM that, sometimes, it doesn't even run default Google apps?

There's something scary about a single codebase running the entire web, whether it's open-source or not. It certainly defeats the point of having web standards.

one rendering engine = no competition

You need competition to make developers develop.

When the race is over, everybody stops running...

Then obviously you are both running Opera as your main browser, right?

  • 2 months later...
No, 50/50 between IE and Chrome depending on website and device.

Then how can you justify your criticism of Opera? Why should everyone else have to carry the burden while you sit around on the sidelines and tell everyone else to "do the right thing"?

This topic is now closed to further replies.
  • Posts

    • Honestly... 4 wasn't fun, 5 had unlikeable, annoying, or dull characters... Yeah, to me the magic died with San Andreas.
    • Flameshot 14.0 Final by Razvan Serea Flameshot is a free and open-source, cross-platform tool to take screenshots with many built-in features to save you time. Using Flameshot is as simple as launching, dragging the selection box to cover the area you want to capture, making annotations as needed in on-screen and saving the shot to your computer, all with a very simple and straightforward interface. Flameshot allows users to simply upload their screenshots directly to the cloud in order to easily share it with others. You can upload your image directly to Imgur with a single click and share the URL with others. In-app screenshot editing - You can choose to add an arrow mark, highlight text, blur a section (blur or pixelate an area), add a text, draw something, add a rectangular/circular shaped border, add an incrementing counter number, and add a solid color box with Flameshot's built-in editing tools. Command-line interface (CLI) - Flameshot has several commands you can use in the terminal without launching the GUI via a command line interface. The command line interface lets you script Flameshot and use it as the subject of key binds. Flameshot 14.0 release notes: This release brings major improvements to multi-monitor support, fractional scaling support, new capture workflows, and a long list of bug fixes across all platforms. Changelog: New Multi-Monitor Capture Workflow New monitor selection screen before capture for better multi-monitor and mixed-scaling support. Option to auto-capture the monitor under the cursor (X11 & Windows). Tray menu can directly select a monitor. Linux Improvements XDG Desktop Portal is now the primary screenshot method. Added legacy X11 fallback option for minimal window managers. New D-Bus capture API for scripting and automation. Windows Enhancements Global screenshot hotkeys now supported (not limited to Print Screen). New portable mode stores settings next to the executable. Clipboard now always uses PNG format for better compatibility. CLI & Platform Updates Redesigned flameshot screen command with per-monitor capture support. Added native Nix Flake support. More compact launcher UI and improved update notifications. Major Fixes Multiple Wayland stability fixes, including KDE Plasma crash fixes. Clipboard compatibility improvements for GNOME, Wayland, X11, Windows, and macOS. Fixed D-Bus hangs, capture crashes, and HiDPI region issues. Other Changes Dropped Ubuntu 20.04 (Focal) support. Updated translations and build infrastructure. Intel macOS builds are no longer provided. [full release notes] Download: Flameshot 14.0 | 18.1 MB (Open Source) Download: Flameshot Portable | 53.0 MB Links: Flameshot Home Page | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
  • Recent Achievements

    • Reacting Well
      BizSAR earned a badge
      Reacting Well
    • First Post
      AndreaB earned a badge
      First Post
    • Week One Done
      Huge Trailer earned a badge
      Week One Done
    • Week One Done
      Classifyskilleducation earned a badge
      Week One Done
    • One Month Later
      eurospharma62 earned a badge
      One Month Later
  • Popular Contributors

    1. 1
      +primortal
      579
    2. 2
      +Edouard
      183
    3. 3
      PsYcHoKiLLa
      75
    4. 4
      Michael Scrip
      73
    5. 5
      neufuse
      64
  • Tell a friend

    Love Neowin? Tell a friend!