othermaciej

Manually specifying different HTTP ranges of the same resource is more verbose, more error-prone and more confusing than just specifying different resources. Other than that, I guess it would work.

When it comes to page load speed, extra network round trips are really bad. Even if you're loading the same total amount of data.

That's not so great for high-latency networks (like most cellular networks). If you use range requests, you add round trips. If you cancel the load partway, you're too late because your pipe is already filled with bits you don't need.

It matches the CSS equivalent feature, image-set().

SVG is fine for assets that can easily be described in vector form, but it's not the best choice for all image types. For example, photographs (where you might have an ultra high resolution original that you're scaling down) are not easily representable in SVG other than to embed the bitmap.

In the case of Web standards in particular, you can usually see the checkins in our public source tree well before we ship it. But per policy we will rarely publicly commit to shipping something or not ahead of time.

WebKit did fine before Google ever joined the project, and I'm sure it will do fine with them gone.

In WebKit, we have macros to always inline or never inline for our target compilers, so we can force the issue if the compiler won't take the hint in a place that matters.

Do you have any specific feedback about things you have problems with?

Try the version in WebKit nightlies and the OS X Mavericks developer preview. It's much improved from Safari 6.

I expect other browsers could greatly improve JSBench performance if they focused on it. But I would be quite surprised if they matched Safari's current results in a month. It took a lot more than a month and significant architectural work to get those results in the first place.

It's not in the keynote, but if you get the Developer Preview you can see what's new.

Other JS benchmarks are not based on highly-trafficked real-world sources at all, so perhaps "real" is relative.

Its's real. You can try the benchmark yourself here, and learn how it is different from other JS benchmarks <http://jsbench.cs.purdue.edu/>.

I looked up th case you cited, a copy of the opinion of the court may be found here: http://law.justia.com/cases/california/caapp4th/30/943.html

As far as I can tell, it doesn't say what you claim it does. There is no mention of burden of proof or prima facile case at all. It merely states that truth is an absolute defense, but that is only the case because it precludes the plaintiff meeting their burden of proof to show falsity.

Since you mention a distinction between private and public indviduals, I suspect you are confusing the issue of burden of proof with the "actual malice" standard, which must be met to establish defamation of a public figure but not a private figure. This is established by Supreme Court precedents Arthur v Sullivan and Getz v Robert Welch Inc, both of which are cited in the law review article I mentioned and both of which maintain falsity as a required element of the offense. (In case you were wondering, Supreme Court precedent trumps Circuit Court precedent in the US, so even if the case said what you claimed it would not be informative about the state of the law of defamation.)

Correct that truth is a defense. But, as I understand it, the defendant does not at any point have a burden of proof in a civil case, even if the plaintiff has made a prima facie case. That's just not how burden of proof works for any tort under US law. The burden is essentially always the plaintiff's by a preponderance of the evidence. Many defendants try to prove truth of their claims so that the plaintiff cannot meet their burden of proof to show falsity. But that doesn't mean they have the burden of proof, in the sense in which it's typically used.

Here's the wikipedia article: http://en.wikipedia.org/wiki/United_States_defamation_law

Here's a random scholarly article on the topic: http://scholarship.law.wm.edu/cgi/viewcontent.cgi?article=22...

I believe they do not support your position.

That being said, I'm not a lawyer and for all I know maybe you are, so perhaps I am failing to understand the issue.

> As in all defamation cases, it is Ms. Allen's job to prove that the allegedly defamatory statements (the accusation of rape) were true and the photo is a significant obstacle for her to overcome.

That's not the case under US libel and defamation law. As with any other tort, the plaintiff has the burden of proof (and thus must prove, among other elements of the tort, that the statement was false). The UK and some other jurisdictions have a reversed burden of proof for defamation or libel, but not the US.

1) The answer wasn't "we'd like to do this but we're super busy right now, how about later" or "that's super complicated, will you guys put in a lot of the effort". It was a pretty direct no. We would have been willing to do much of the work.

2) My recollection is that we talked about it around a year after Chrome was released. Chrome Beta release date: September 2, 2008 Date of WebKit2 announcement: Thu Apr 8, 2010 (after <1 year of development) I don't have records of the meetings where we walked though.

3) Does the reason for saying no affect whether our choice to make our own thing was reasonable?

My interest in this thread was only to report on some history that I knew about personally, to correct what I thought was an incomplete version of events. I think a bunch of people found that information useful and interesting.

I regret that this thread has turned into such a back-and-forth. It's not my goal to detract from the Blink announcement. I feel like it would be rude to leave you hanging on mid-thread. However, I feel like: (a) You are trying to argue with my version of specific events where I was present in person and you (as far as I recall) were not. (b) You are trying to argue with my stated motivations for decisions that I was part of and you were not. (c) You seem to want to assign blame.

Maybe my impressions are wrong. But given this, I find it hard to reply in a way that would be constructive and would not further escalate. I hope you will forgive me for not debating about it further.

Thanks, Mike. And sorry also if my reply was too lengthy or pedantic or otherwise out of place. I feel bad for getting into a back-and-forth about this.

You're right that Chrome's multiprocess architecture is more mature than the WebKit2 design. I wish we hadn't ended up in a position where we felt we had to make our own. But stay tuned - we have some great stuff coming up.

>> We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon. > Yes, I'm aware of that, but the work had been underway for a long time and was about to be dropped by the time there was a real heads up. So the core of the architecture was already being frozen from a larger perspective.

Are you aware of the earlier conversation that occurred before we wrote any lines of code or even had a name? Where we talked about the possibility of just using Chromium's model if Google was willing to contribute it back? I have mentioned it twice - maybe you overlooked those parts of my remarks.

> Chromium's architecture was public and available, but we assumed it wasn't used because it didn't fit the needs of WebKit2. There's no malice in that. We designed Chromium from the beginning for SFI (as Adam tried to convey), and that incurs quite a bit of complexity.

It had nothing to do with SFI (which wasn't brought up at the time) or complexity. It was for the reasons I stated upthread.

If we took Chromium's multiprocess code and put it in the WebKit tree after the Chrome folks specifically said they did not want to do that, that would have been super rude. Don't you think? That's why I say "hostile fork". I am judging our own path not chosen, and do not mean to cast aspersions on Google's actions.

To be clear, I do not consider Blink to be a hostile fork. I wish the Blink developers good luck & godspeed.

We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon.

I don't know if the contents of these conversations were ever shared with the whole Chrome team as som Chrome people seemed super surprised at our announcement.

It is true that when we announced our effort, it came with a rough working prototype and not just an empty directory. Basically because we did not know if we could do it until we tried.

BTW I am not trying to pick a fight here. I think mikewest's comment gave the impression that Apple built a multiprocess architecture out of cussedness or NIH. But that's not how it was.

Google had the right to make their choices and we had the right to make ours.

As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes.

Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.

At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever. (At the time, there wasn't really an API-stable layer of the Chromium stack that packaged the process support.)

Writing our own seemed like the least bad approach.

If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently.

I'd also add that I disagree with Mike about the architectures being really different. In fact, they are quite similar in broad strokes, but with many differences in details (and with the significant difference that the Chromium model isn't in WebKit per se).

The Constitution uses the word "privilege", but it does not mention the concept of privilege as you are using it. "Privileges" in the constitution aren't distinct from or weaker than rights - they are considered fundamental rights. The Supreme Court said so and I think their interpretation counts for more than yours.

That is probably why you got down voted - your citation is factual, but completely misleading in context.

To address the specific example you mention here: the privilege of immunity from arrest for members of Congress cannot be infringed except for specific enumerated exceptions. It's not the kind if "privilege not a right" that may be arbitrarily harshly regulated that you were talking about.

The law is not stupid. Courts understand that words have more than one meaning and that context matters. Given how rude and condescending you have been on this thread, you should learn more about how constitutional law actually works.

These uses of the word "privilege" are all defining rights, not privileges in the sense you mean. Here is an example of Supreme Court jurisprudence on the Privileges and Immunities Clause (from the landmark Slaughterhouse Cases):

[P]rivileges and immunities....are, in the language of Judge Washington, those rights which are fundamental. Throughout his opinion, they are spoken of as rights belonging to the individual as a citizen of a State....

Or were you claiming above that flying is one of those rights which are fundamental?

Keep in mind that MPEG (which defines codecs) and MPEG-LA (which gives you one-stop shopping for some of the patent licnses) are completely separate entities.

MPEG-LA even arranges patent licensing for some codecs not developed by MPEG, such as SMPTE VC-1.

They may have a vested interest in the royalty-bearing license regime but not necessarily in supporting any given codec family.

MPEG-LA doesn't claim to have all possible H.264 patents in their patent pool. Nokia has an FRAND obligation for H.264, so it's obligated to license on fair, reasonable and non-discriminatory terms, but it has chosen not to be part of the pool.

MPEG-LA did not claim to have all possible VP8 patents either.

Note that MPEG-LA is basically a group that sets up convenient one-stop licensing, there's no such thing as being a "member" per se. You can be part of any of their patent pools, or not, if you believe you have essential IP.

I think http://marketshare.hitslink.com/report.aspx?qprid=8&qpcu... is more believable based on correlation with other sources of data.