Slashdot Mirror

Then again that might encourage advertisers to look for other ways of fingerprinting the device.

That's the reason that Apple argued in favour of making the HTML5 pingback function mandatory and impossible to disable. Yes Google got the flak for it but Apple made the same argument. If it's removed then advertisers will just find some other way to do it, making things worse.

Every time advertisers find a way to track the user, it must be countered. Giving up is not an option. They "they'll just find another way to keep doing it anyway" argument doesn't fly -- it is imperative that we keep this cat and mouse game going until they screw up so badly that it ends in their own ruin, or at least regulation.

Make them work to track us. Make it cut into their operating budgets. Force them to get worse, and worse, and worse, so when the day comes that they're just straight-up rootkitting our phones out of frustration (and mark my words, they will,) we can raid their offices with armed SWAT officers for breach of the CFAA.

Advertisers are an insidious, parasitic sub-human form of life. Just look at that previous article about what they want to do to the fucking night sky. They need to be brought down hard. Perhaps a SWAT team with orders to paint their office walls red if they so much as blink would force them into being good corporate citizens for the first time in their miserable existence.

Tough love is the only way to deal with scum like this.

Maybe it would be better to connect the function call to a random number generator.

Then again that might encourage advertisers to look for other ways of fingerprinting the device.

That's the reason that Apple argued in favour of making the HTML5 pingback function mandatory and impossible to disable. Yes Google got the flak for it but Apple made the same argument. If it's removed then advertisers will just find some other way to do it, making things worse.

Wasn't this in WebKit (and therefor Chrome) 10 years ago?

https://webkit.org/blog/427/we...

If you don't control both end points though H.264 is now almost universal as long as you're willing to use Cisco's OpenH264 patent licensed binary or one of the many other open source decoders, which is 99.99% of the market. That was as late as 2013 though, so it's only been 5 years since missing codecs actually was an end user problem.

Here's one: Video calling between end users. This requires both sides to have an audio encoder, video encoder, audio decoder, and video decoder for the codec suite used for the call.

As for audio: Apple WebKit appears to support Opus (webrtcHacks).

As for video: Apple WebKit supports only H.264 (webrtcHacks; bug 173141) and therefore doesn't fully conform to WebRTC (RFC 7742 section 5). If one end of a WebRTC video call is an iOS device running Safari or another Apple WebKit wrapper, then the call must use H.264, and the other device must also include a licensed H.264 encoder. Does OpenH264 encode, or is it only a decoder?

P.S. VP8 in WebRTC was added to Apple WebKit 37 days ago (bug 189976), but it may take months for this fix to reach the version of Apple WebKit included with iOS.

If you don't control both end points though H.264 is now almost universal as long as you're willing to use Cisco's OpenH264 patent licensed binary or one of the many other open source decoders, which is 99.99% of the market. That was as late as 2013 though, so it's only been 5 years since missing codecs actually was an end user problem.

Here's one: Video calling between end users. This requires both sides to have an audio encoder, video encoder, audio decoder, and video decoder for the codec suite used for the call.

As for audio: Apple WebKit appears to support Opus (webrtcHacks).

As for video: Apple WebKit supports only H.264 (webrtcHacks; bug 173141) and therefore doesn't fully conform to WebRTC (RFC 7742 section 5). If one end of a WebRTC video call is an iOS device running Safari or another Apple WebKit wrapper, then the call must use H.264, and the other device must also include a licensed H.264 encoder. Does OpenH264 encode, or is it only a decoder?

P.S. VP8 in WebRTC was added to Apple WebKit 37 days ago (bug 189976), but it may take months for this fix to reach the version of Apple WebKit included with iOS.

For most enterprise devices, they aren't going to be having other apps installed. They probably aren't going to be running anything but company apps, the web browser if at all using company web pages. So it hardly matters if this security issue is present.

The problem is that running JavaScript is enough, see for example: https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/. And most devices that do have a browser will at some point in time use it to access untrusted hosts...

Meltdown cannot be exploited using Javascript.

Yes it can, even WebKit says so...

Meltdown means that userland code, such as JavaScript running in a web browser, can read kernel memory. Not all CPUs are affected by Meltdown and Meltdown is being mitigated by operating system changes. Mounting a Meltdown attack via JavaScript running in WebKit requires first bypassing branch-based security checks, like in the case of a Spectre attack. Therefore, Spectre mitigations that fix the branch problem also prevent an attacker from using WebKit as the starting point for Meltdown.

REF: https://webkit.org/blog/8048/w...

Most browser vendors are implementing many changes to mitigate Meltdown and Spectre, including things like reducing the precision of high-fidelity timers from 5us to 20us +/- 20us, disabling SharedArrayBuffers and recompiling with Spectre-aware compilers.

I looked into notifications for iPhone webapps somewhat recently, it is not *currently* possible. Sevice workers are in development but not currently available.

Since iOS 8, Apple recommends everybody uses the new WKWebView which replaces UIWebView: https://developer.apple.com/re...

However, WKWebView is not as flexible as UIWebView; more specifically, there is no support for a custom NSURLProtocol. Basically to get the performance gains of using WKWebView, you can't do the things you want to do.

For Opera specifically, this bug filed against webkit lays out the features they would like to implement, but are unable to: https://bugs.webkit.org/show_b...

Opera on iOS implements a custom HTTP(S) protocol to do:
1. Data savings (see http://www.opera.com/turbo ). This greatly improves connectivity under crappy network conditions for millions of users. It's especially important for people in countries which can only dream about 4G.
2. Peer-to-peer inobtrusive security. For that we collect bits of site security information that is only available via low-level network APIs.
3. Presenting sites as icons (and grouping multiple pages into the same icons). For that we hook into the HTML data stream to parse meta data ASAP. In addition we intercept and react on HTTP redirects. This is a part of the http://operacoast.com/ app identity.
4. Progress loading reporting, automatic retries on bad networks. For that we do traffic QoS monitoring.
5. Fast going back and offline content. That is controlled partially by a custom cache, and partially in NSURLProtocol.
6. Ad-blocking.

Apple wants everyone to collaborate a technology that will sit above metal, Direct3D, and Vulcan that talks down to those disparate technologies. They provided a sample to show possibilities that they said they don't expect to be the standard. https://webkit.org/blog/7380/n... Relevant quotes to dispel the paranoid ramblings posted by others. "In order to expose a modern, low-level technology that can accelerate graphics and computation, we need to design an API that can be implemented on top of many systems, including those mentioned above." "We don’t expect this to become the actual API that ends up in the standard, and maybe not even the one that the Community Group decides to start with, but we think there is a lot of value in working code."

So if the compatient's beef is that WebKit doesn't support the "latest" HTML5, WebM, "whatever is hot today" standard. Why not actually help improve the WebKit engine, since you know, its Open Source. They can first begin by first reading the Getting Started page. And for those individuals that want to know the Licensing WebKit page indicates that "WebKit is open source software with portions licensed under the LGPL and BSD licenses."

Is WebKit the best rendering engine under the sun, not really, but then none of them are. They all encompass a series of compromises that the developers try to balance as they're developing the software. Most of them boil down to simply the number of hours available. Each project can only develop based upon the number of people willing to contribute to the common goal.

If they don't like the pace at which the software is being developed, then either shut-up, or help. No one is making you develop any software for a specific platform. If you don't like it you can always take your toys elsewhere and hope the grass is greener on the other side. :)

So if the compatient's beef is that WebKit doesn't support the "latest" HTML5, WebM, "whatever is hot today" standard. Why not actually help improve the WebKit engine, since you know, its Open Source. They can first begin by first reading the Getting Started page. And for those individuals that want to know the Licensing WebKit page indicates that "WebKit is open source software with portions licensed under the LGPL and BSD licenses."

Is WebKit the best rendering engine under the sun, not really, but then none of them are. They all encompass a series of compromises that the developers try to balance as they're developing the software. Most of them boil down to simply the number of hours available. Each project can only develop based upon the number of people willing to contribute to the common goal.

If they don't like the pace at which the software is being developed, then either shut-up, or help. No one is making you develop any software for a specific platform. If you don't like it you can always take your toys elsewhere and hope the grass is greener on the other side. :)

So if the compatient's beef is that WebKit doesn't support the "latest" HTML5, WebM, "whatever is hot today" standard. Why not actually help improve the WebKit engine, since you know, its Open Source. They can first begin by first reading the Getting Started page. And for those individuals that want to know the Licensing WebKit page indicates that "WebKit is open source software with portions licensed under the LGPL and BSD licenses."

Is WebKit the best rendering engine under the sun, not really, but then none of them are. They all encompass a series of compromises that the developers try to balance as they're developing the software. Most of them boil down to simply the number of hours available. Each project can only develop based upon the number of people willing to contribute to the common goal.

If they don't like the pace at which the software is being developed, then either shut-up, or help. No one is making you develop any software for a specific platform. If you don't like it you can always take your toys elsewhere and hope the grass is greener on the other side. :)

Check the status page

... Since the target audience consists mainly of programmers building websites and web applications, it doesn't make sense to limit it to developers building native apps for iOS and OS X. ...

Another limitation which has been a source of annoyance for me personally is that desktop Safari is exclusively available on the Mac. There was a time when a fully supported version of Safari for Windows existed... that has since been discontinued. So here's to hoping that this Tech Preview version also manages to properly resurrect Safari on Windows.

(Note that I'm a MacHead at home, who is forced into the Windows mold at work... and I'm quite certain that many other MacHeads share my fate. There is, of course, a lengthy method for installing Webkit nightly builds under Windows... for those who are extremely dedicated. Unfortunately, that method has the proverbial snowball's chance in hell of making it past the corporate software approval processes... for those of us who just want it, rather then need it for business purposes.)

No different for webkit open bugs, or Chromium.

The Webkit team is quite awesome, it's just that there's far too few of them.

This page would beg to differ.

Which makes some sense if you're Tim Cook. You want people writing iOS apps in the walled garden instead of cross-platform Web content, and for now you can expect they will, especially if that Web content doesn't work well in Safari.

But at some point, in some markets, that strategy may break down.

This is an interesting conspiracy theory, but Apple only accounts for around 1/3rd of all Webkit commits.

I also use Safari, though I'm still pissed off with them for combining the URL bar and search box (which means that I keep typing one-word search terms and having it try to resolve them as domains, which then go in my history and so become the subject of autocomplete. The only way to avoid it is to get into the habit of hitting space at the end of a search, which is no saving on hitting tab at the start to jump to the search box). Chrome doesn't properly integrate with the keychain. I use Firefox on Android (self destructing cookies makes it the first browser I've used with a sane cookie management policy), but overall the UI for Safari does exactly what I want from a browser: stay out of the way.

TFS is nonsense though. Developers don't know what's going to be in the next version of Safari? Why don't they download the nightly build and see?

Apple won't even provide free virtual machines to web developers. They expect you to pay for the privilege of finding out their products don't display your sites properly.

I don't know Apple's official policy on that subject (it would not surprise me if your statement was true), but in reality you can verify your web site development against Safari for free fairly easily:
https://www.webkit.org/

Now if you mean iOS websites in Safari, then the above won't be a good option, but for iOS development it isn't an issue as you already have Safari and an iOS emulator installed with Xcode on your development system, so it is a moot point.

• Chrome: Chromium
• Safari: WebKit.
• IE users are SOOL, but they were already SOOL just by using IE.

Microsoft wants a monoculture (with Trident) and that's bad. Microsoft avoids a monoculture (by not using Webkit) and that's bad too I really pity the Spartan developers. To people like you, there is literally nothing they can do 'right'.

I hate to Reply twice to the same message; but THIS illustrates my point:

List of WebKit-Based Browsers (and other Applications)

Safari offers *four* tiers with their FTL (Fourth Tier LLVM). Lots of detail here: https://www.webkit.org/blog/33....

My understanding is that Apple have done the work to make it viable to use LLVM for certain levels of Javascript JITing so it is now feasible to use LLVM to compile long running dynamic code. Said code needs to be long running to a) build up information about the instructions being run b) offset the overhead of compilation.

There is a diversity of approaches to GC, with different trade-offs. The short-object-lifetime conjecture works out pretty well in practice (and can be explicitly coded and/or compiled towards), and extremely fast handling of a small first generation arena has led to many approaches which takes advantage of what underlying hardware actually does (stack->hidden registers, cacheline colouring, etc.). Threading is commonplace in modern GCs, so there is no need to stop the world even for a full collection; anti-collision approaches involving write barriers, random selection of which page at a given hotness should be scanned, and so forth, mean that one has to try hard to hit the worst case of the the GC scan & sweep or scan & move with one's code.

The important point about GC is that it reduces the time to allocate memory initially; the typical case is a pointer increment and no further bookkeeping. The cost of freeing and compacting can be amortized over time during idle periods, or where there is room for one or more GC threads to sift through older objects to see if they're still referenced.

Reference Counting is not real GC.

That's an unusual opinion. Automated reference counting implementations are essentially an optimization over simple mark & sweep; you can skip tracing down through objects who have nonzero reference counts until you are desperately short of memory, at which point you can trace down through those object trees and prune them (and there is where automated reference counting can really win with weak referencing, low-memory handlers or finalizers, and so forth - objects which are referenced but which are permitted to be purged in response to system behaviour are almost always part of a modern ref counting design.) Such approaches are orthogonal to precise vs conservative collection strategies.

Not very many languages can have tens or even hundreds of gigabytes (yes GB) of heap with GC pause times of 10 ms.

There are several large functional programming runtime environments which have worst-case bounded pauses measured in tens of machine instructions, and there is active research into avoiding ccNUMA waits during those worst-case periods.

JVM GC is getting better and is benefiting from the ongoing and diverse work in automatic memory management. However not even Hotspot is not a shining beacon of awesome memory management modernness. Its performance is poor compared to proprietary JVMs such as Azul Zing, which benefits from its continuous concurrent compacting collection (C4) GC system.

A better example of a big and popular open-source project beginning to use modern memory management techniques (and has actually been using even more modern JIT compilation (and dataflow-driven and profile-driven recompilation in frequently used code paths)) is the work Pizlo et al have been doing in WebKit (e.g. https://www.webkit.org/blog/33... or http://blog.llvm.org/2014/07/f... ). One of his slide decks makes the (pretty accurate) claim: "We took a dynamic language and made it fast!". Node.js is also a good example of increasing use of modern memory management in open source, lifting lots of material from V8.

The official Webkit blog has a post about it.

The original poster said there were Chrome only websites. I asked him for a link to one. You answered a question I didn't ask on his behalf. As you're acting on his behalf please provide me with a link to a Chrome only website as I requested, not a lot of whinging about how the Apple project, Webkit, is taking over the world. Seems we both have trouble reading.

Anyone know how many clones of WebKit and related projects are on GitHub? Because I can imagine that pretty much skewing the statistics for C++ due to this: https://trac.webkit.org/browser/trunk/Source/WTF.

Why would you point to the tarball location, when the revision control system is online?

Or just use a client-side contact form (created using this generator)

Or just use a client-side contact form (created using this generator)

No, it hasn't been blocking third party cookies for years. This is the core of why such policies are a bad idea. It says it blocks third party cookies, but there are actually lots of exceptions to that rule in order to avoid as the summary says "false positives". You can read about what really happened with Google on Lauren Weinstein's blog, it's very different to how you paint it (there was no "trying to circumvent" involved).

This uses a C64 font among others for generating captchas

The removal of Chrome specific code from WebKit, and non-Chrome code from Blink will benefit everyone in the long run. Both code bases and rendering engines will be smaller, faster, less buggy, etc.

Please explain to me: What negative impact do cleanly separated platform adaptions have? So WebKit devs will delete the chromium directory in https://trac.webkit.org/browser/trunk/Source/WebCore/platform and Google will delete all directories except chromium (and probably android) but I don't see why a buggy BlackBerry adaptation would have any negative impact on the Chromium adaptation and vice versa.

Couldn't they even say "thank you"?

.

Full text:

I’m writing to say thank you, personally, and on behalf of the Chromium project.

Chromium could not have happened without WebKit and the help of its
contributors.

As you likely have seen, Adam just posted
http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html
announcing Blink, which is a departure from our previous WebKit
workflow.

I hope that others will see Blink as I do: as a chance to take the
WebKit codebase to exciting new places. I hope someday that many of
the ideas we pursue in Blink will find their way into many platforms,
including WebKit.

For those interested in the technical details, we’ll be posting more
of our thoughts and plans to blink-dev at chromium.org.

WebKit and Chromium have a long, shared history, and we hope to
continue our relationship. We will be available on #webkit and
webkit-dev and hope to continue our connections with this great
community for years to come.

Thank you again.

Eric

p.s. Adam and I are happy to work with other reviewers to remove
PLATFORM(CHROMIUM) code and other messes we may have caused over the
years from webkit.org. Adam and I are still running queues.webkit.org
and associated EWS/CQ/sherriff-bot and plan to do so for the next few
weeks as we work to transition them to new owners.

Funny that you didn't keep the title (I put back again) ...

Couldn't they even say "thank you"?

.

Full text:

I’m writing to say thank you, personally, and on behalf of the Chromium project.

Chromium could not have happened without WebKit and the help of its
contributors.

As you likely have seen, Adam just posted
http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html
announcing Blink, which is a departure from our previous WebKit
workflow.

I hope that others will see Blink as I do: as a chance to take the
WebKit codebase to exciting new places. I hope someday that many of
the ideas we pursue in Blink will find their way into many platforms,
including WebKit.

For those interested in the technical details, we’ll be posting more
of our thoughts and plans to blink-dev at chromium.org.

WebKit and Chromium have a long, shared history, and we hope to
continue our relationship. We will be available on #webkit and
webkit-dev and hope to continue our connections with this great
community for years to come.

Thank you again.

Eric

p.s. Adam and I are happy to work with other reviewers to remove
PLATFORM(CHROMIUM) code and other messes we may have caused over the
years from webkit.org. Adam and I are still running queues.webkit.org
and associated EWS/CQ/sherriff-bot and plan to do so for the next few
weeks as we work to transition them to new owners.

Why not just make the choice of rendering engine user configurable?

I have just been digging around and think I can answer this question. It seems that the reason for this is to do with the upcoming webkit2 Apple project taking a very different approach to how multiprocess stuff should work. They have some pretty diagrams here showing the differences: http://trac.webkit.org/wiki/WebKit2

Google have long taken the approach it seems to just have entirely separate processes for each page talk to a webkit subprocess via api calls.The webkit2 project are taking a different approach by trying to put multiprocess stuff actually into the webkit2 api itself.

Since Apple will probably throw webkit out the window anyway when webkit2 is ready it seems that everyone moaning about Google here may be a bit backward. It seems that when Webkit2 is ready then everyone except Chromium will use it. Chromium won't need to use webkit2 because it is already designed to do what webkit2 does anyway.

I have to admit, I have a gut feeling here that wrapping the multiprocess stuff around webkit ala chromium is actually a better idea than trying to do what WebKit2 is trying so I think the chromium devs might be making a better choice from a technical perspective even though it probably is a bit more resource hungry.

Of course much of this about Apple adopting webkit2 for Safari all pure speculation, but then it has to be when you are talking about a closed source product like Safari and don't work for Apple.

For reference, the WebKit team's main page for WebKit2 describes some of the differences between its approach and the approach that Google took when developing their own process architecture. It more or less struck me as an indication that WebKit2 would be a point of divergence for Apple and the people switching to WebKit2, and for Google, which would likely stick with WebKit and their investment in the architecture that they had already developed. Apple switched from using WebKit to WebKit2 in Safari quite some time ago, though by all indications it has not yet done so with iOS.

The fact that forking WebKit will likely allow Google to drop support for iOS (among other platforms) as they add more features and establish a competitive advantage for themselves is more than likely a larger motivating factor than this, but it's still something worth considering.

Not so fast - MathML's in WebKit already.

Google just decided to remove MathML from Chrome 25, so much for "great competition and rapid evolution" for academic e-books.

Looks like it's going to be restored as part of WebKit though.

Webkit is riven with architectural compromises, technical debt, lousy infrastructure, competing corporate agendas, mistrust and factionalism that will probably destroy it sooner or later. This recent post on the Webkit dev mailing list is illuminating. Eric Seidel is an almost-decade-long contributor to Webkit, both as an Apple and Google employee, and he has a laundry list of problems with the Webkit project. Perhaps most telling is that there is almost no trust between Google and Apple, with each having developed an "us" and "them" attitude, and also that there is essentially no management of the project's overall direction. Contributors just work on what they want, when they want, without telling anyone else, and the first and only way their supposed collaborators hear about it is by seeing changesets show up in the Webkit trunk.

Here's another Webkit dev post by Google employee Adam Barth, regarding Apple's attempts to upstream its iOS Webkit port, which for the duration of iOS's existence has been Apple-internal. It's pretty illustrative of the level of discourse between Google and Apple on Webkit:

I don't really know how to respond to this thread. I feel like I'm being offered the following choice: 1) Give up the ability to have technical input to how WebCore works and simply accept all the design choices made in the iOS fork, whether they be good choices or bad. 2) Keep the iOS port in an Apple-internal fork for a number of years. I feel like I'm being asked to make this choice in the context of a growing trend of unilateral action by Apple in this project. Given that trend, I don't see how I can choose option (1). As much as I would like the iOS port merged into trunk, I'm not willing to give up having a technical say in the project. Therefore, reluctantly, I'm forced to choose option (2).

"A growing trend of unilateral action" does not seem like a healthy place for a collaborative project of this sort to be in. I get the impression that these kind of conflicts are become more common not less, as Google and Apple compete more strongly and openly, and their patience with each other runs out.

In fact, in some respects, Google and Apple already maintain their own forks of Webkit, albeit stored under the same source tree. How does that work? Well every feature that is implemented in Webkit nowadays is done behind what is called a feature flag. This means it can be turned on or off in a particular Webkit port at compile time. The set of features enabled by Google's Webkit ports (in Chrome and Android), differs wildly from those enabled in Apple's ports (in iOS and Safari), but basically can be summed up as, Google uses features developed by Google, and Apple uses features developed by Apple, with just occasional crossover. This means anything you read about "Webkit browsers" is meaningless, because one Webkit browser can be totally different from another in capability, even if it was compiled from the same source.

This situation, coupled with the apparent nightmare they have encountered trying to construct infrastructure to support building and testing Webkit, makes you suspect each will eventually conclude the diminishing benefits of shared labor are not worth the myriad headaches and loss of control, and go their separate ways. They'll maintain separate trees, with occasional cherry picking of features from each other, but also growing incompatibility as each pursues their own independent vision.

Webkit is riven with architectural compromises, technical debt, lousy infrastructure, competing corporate agendas, mistrust and factionalism that will probably destroy it sooner or later. This recent post on the Webkit dev mailing list is illuminating. Eric Seidel is an almost-decade-long contributor to Webkit, both as an Apple and Google employee, and he has a laundry list of problems with the Webkit project. Perhaps most telling is that there is almost no trust between Google and Apple, with each having developed an "us" and "them" attitude, and also that there is essentially no management of the project's overall direction. Contributors just work on what they want, when they want, without telling anyone else, and the first and only way their supposed collaborators hear about it is by seeing changesets show up in the Webkit trunk.

Here's another Webkit dev post by Google employee Adam Barth, regarding Apple's attempts to upstream its iOS Webkit port, which for the duration of iOS's existence has been Apple-internal. It's pretty illustrative of the level of discourse between Google and Apple on Webkit:

I don't really know how to respond to this thread. I feel like I'm being offered the following choice: 1) Give up the ability to have technical input to how WebCore works and simply accept all the design choices made in the iOS fork, whether they be good choices or bad. 2) Keep the iOS port in an Apple-internal fork for a number of years. I feel like I'm being asked to make this choice in the context of a growing trend of unilateral action by Apple in this project. Given that trend, I don't see how I can choose option (1). As much as I would like the iOS port merged into trunk, I'm not willing to give up having a technical say in the project. Therefore, reluctantly, I'm forced to choose option (2).

"A growing trend of unilateral action" does not seem like a healthy place for a collaborative project of this sort to be in. I get the impression that these kind of conflicts are become more common not less, as Google and Apple compete more strongly and openly, and their patience with each other runs out.

In fact, in some respects, Google and Apple already maintain their own forks of Webkit, albeit stored under the same source tree. How does that work? Well every feature that is implemented in Webkit nowadays is done behind what is called a feature flag. This means it can be turned on or off in a particular Webkit port at compile time. The set of features enabled by Google's Webkit ports (in Chrome and Android), differs wildly from those enabled in Apple's ports (in iOS and Safari), but basically can be summed up as, Google uses features developed by Google, and Apple uses features developed by Apple, with just occasional crossover. This means anything you read about "Webkit browsers" is meaningless, because one Webkit browser can be totally different from another in capability, even if it was compiled from the same source.

This situation, coupled with the apparent nightmare they have encountered trying to construct infrastructure to support building and testing Webkit, makes you suspect each will eventually conclude the diminishing benefits of shared labor are not worth the myriad headaches and loss of control, and go their separate ways. They'll maintain separate trees, with occasional cherry picking of features from each other, but also growing incompatibility as each pursues their own independent vision.

We were actually discussing that very issue on the MobileRead forums just a couple of weeks ago. Part of the problem is that most of the EPUB readers don't properly support page-break-inside: avoid. For sure, WebKit doesn't support it yet, and AFAIK, neither does ADE. Between those two, that covers almost all the EPUB readers, Kindle, etc.

You might be successful by forcing a page break before the image (but your success would depend on the aspect ratio of the reader's screen), or you could use SVG that contains both the caption and the image (but SVG is kind of buggy on some readers, particularly when it comes to text, so this is potentially problematic as well). Neither of those is a particularly good alternative to what ought to have been solved by a single line of CSS on the container. And that's why every single eBook you've looked at is broken....

Better and free: You can generate PDFs by installing qtwebkit http://trac.webkit.org/wiki/QtWebKit.

> with an active community that cares about
> standards,

Sometimes. And sometimes not so much. Compare Gecko and WebKit's CSS 2.1 support (based on the official test suite) at http://www.w3.org/Style/CSS/Test/CSS2.1/20110323/reports/results.html for example.

Or note the behavior of the editors of the Transitions and Animations spec drafts (who did nothing for a few years, until editors who were not associated with Apple took over the job).

The WebKit community has many members who deeply care about standards. How much the community overall and the project as a whole care is very variable.

> has an explicit policy of trying to behave like other
> browsers where possible

For various values of "possible". e.g. https://bugs.webkit.org/show_bug.cgi?id=36084 is a long-unfixed spec-compat and other-browser-compat issue that's "impossible" to fix because there are Dashboard widgets and such depending on the current WebKit behavior.

> listens to feedback, and fixes bugs.

Unless it's inconvenient to one of Apple or Google to
do so, of course.

But yes, generally speaking it's a reasonably run development project, which means it listens to feedback and bugs generally get fixed eventually.

> They are the opposite of IE in those critical
> respects.

You must be thinking of IE6 circa 2004 or so, when there was no IE team.

The IE team did quite a bit of listening to feedback and fixing of bugs in the late 2000s, and is doing it again now that it exists again. Of course they're not fixing them in IE6 no more than WebKit is fixing bugs in whatever fork it is Android 2.2 is shipping. But you might want to take a look at IE9 and IE10 sometime if you haven't already.

https://bugs.webkit.org/show_bug.cgi?id=79680#c3
http://kalev.fedorapeople.org/midori_about_widgets.png

http://www.mail-archive.com/webkit-gtk@lists.webkit.org/msg01200.html

And webkitgtk is at 1.10.2 now, but this particular bug is still not fixed.

Yes - you can "fix" this by compiling webkitgtk against gtk3, but then the audio and video tags are messed up. They are transparent and have no slider.

which open source solutions are applications like iTunes, Safari, Angry Birds, Keynote, et al taken from?

I wasn't saying everything at Apple was based on Open Source the GP was doing a comparison. What I was comparing was how they handled GUIs in terms of and in comparison to open source. That is on Apple many open source applications need to focus on interface first. Safari which you wanted as a counter example is actually an example. Safari is a GUI wrapper around WebKit ( http://www.webkit.org/ ) which is a wrapper around the KHTML engine from KDE's http://www.konqueror.org/features/browser.php .

  As for iTunes: iTunes as it exists today is a bunch of integrated services. It isn't really a selling point for great interface rather it is something Apple is working around. However iTunes started as a music player, a DAAP server / client combination. Amarok, Banshee, Rhythmbox... are example clients. In terms of the server mt-daapd / Firefly, or Tangerine is an example server. Though I don't think there is any code dependency. Apple was too far ahead of the Open Source community on this one.

  Angry Birds isn't Apple. Keynote has even less to do with Open Source but is based on a closed source program from NeXT, Concurrence.
____

In terms of Linux's lack of success I don't think it has failed. There are too many areas where it has been incredibly successful:
-- it has become 2nd place server OS
-- it is far and away the 1st place Super Computing OS
-- it has become a major virtual environment for mainframe software
-- it is a substantial player in embedded and likely the largest player though still nothing like dominant market share
-- it is the most popular phone tablet OS and a player in a few of the lesser known alternatives (Tizen, Sailfish)

In terms of desktop I always felt the Linux community was underestimating the complexity because the failed to understand how many verticals there were. I assumed the progression would end up looking for Windows like it did for Sun:

1) People are running exclusively closed source software on closed source OSes
2) People are running some open source software on closed source OSes
3) People are running mainly open source software on closed source OSes
4) People are running mainly open source software on open source OSes

On the desktop with Firefox, we moved from (1) to (2). That's opened the door for the motion from (2) to (3) which is what is happening with programs like Open Office. We also see solutions for most verticals being created. It is happening.

Um, *cough*, perhaps you should read this, regarding the first graph.

The Linux stack processes GL in userspace? Que? My only familiarity with this is the source code for the Rasp Pi GL drivers, and they send GL to kernelspace. It makes no sense to do GL processing in userland (um, and access the GPU hardware how?)

In summary, what are you smoking?

All of the people commenting "Apple HAS browser competition!" may not be correct (they are just Safari skins) but neither is the OP.

Dolphin, Sleipnir, Maxthon are all available on iOS in *the same* incarnation as on Android - as skins of the stock engine. The fact is - while many might criticise Opera and Firefox for various reasons, they're the ONLY two mobile browsers actually competing with stock offerings.

The OP mentions Dolphin Jetpack which is - according to Dolphin - a plugin "which provides extensive canvas/GPU/JavaScript performance enhancements". How they do this is not mentioned anywhere on the web I can find, which is somewhat odd. Standard issue Dolphin wraps the phone's stock Webkit - if they're including some new updated Webkit fork packaged into the Jetpack plugin, then where's the source-code? Isn't Webkit supposed to be open source?

So yeah, no surprise here. Please, someone, make a browser that doesnt suck.

True. As a web developer I like HTML5 and CSS3 but it's interesting how browser engines are often still lacking in fairly basic things. For instance, WebKit apparently can't handle hover states on pseudo-elements properly.

Perhaps the browser/engine devs should spend some time on making sure that the existing functionality works well before trying to one-up each other in who supports the latest first-draft CSS feature. Then again that's not how competition works so I guess I'll be looking forward to CSS5 Accessible Teledildonics support while hoping that all engines support position: relative properly...

Perhaps I should move towards a field where there's at least one working implementation of my language of choice.

The obvious ones are WebKit and CUPS, but finding each project that an Apple employee is involved with is not simple.

Apple resources: https://developer.apple.com/opensource/ http://www.apple.com/opensource/
Commentary: http://www.techrepublic.com/blog/opensource/steve-jobs-effect-on-open-source/3101 http://trac.webkit.org/wiki/Companies%20and%20Organizations%20that%20have%20contributed%20to%20WebKit http://blog.openinnovation.net/2011/10/apple-contributions-to-open-innovation.html
And, for a negative to balance things out, http://www.h-online.com/open/features/Kernel-Log-Apple-streamlines-CUPS-1435991.html