mikewest

8 ms·

31.
by mikewest 14y ago
http://trac.webkit.org/wiki/WebKit2 outlines the technical differences between the architectures pretty well. Suffice it to say, the model runs deep, and has real impact on the way things like WebCore are put together.
32.
by mikewest 14y ago
Chrome 28 will be the first blinking release.
33.
by mikewest 14y ago
http://www.chromium.org/blink#new-features has some detail about how we plan to add features to the platform. We're certainly hoping to be pretty transparent about how things get into Chromium.
34.
by mikewest 14y ago
Yes! Prefixes are damaging. We're hiding things behind flags instead, which gives savvy developers the chance to experiment without the risk that sites will begin to depend on those experiments.
35.
by mikewest 14y ago
"Whatever it wants" within reason. We're actually quite concerned about how new features are added to the web platform, and recognize the need to be careful about what we commit to support forever. See http://www.chromium.org/blink#new-fea
36.
by mikewest 14y ago
WebKit2 is a similar, but different, multi-process model. Chromium never compiled it in, but the integration imposed various constraints both on Chromium and on WebCore. That's certainly one of the reasons we've introduced Blink.
37.
by mikewest 14y ago
With regard to open, Chromium is a nicely open source project, and we're really quite committed to transparency in the project. See http://www.chromium.org/blink#new-features for some of our policies in this direction.
38.
by mikewest 14y ago
http://www.chromium.org/blink/developer-faq has a bit more information, as does http://www.chromium.org/blink#architectural-changes . There really are good architectural reasons to go in this direction.
39.
Google Developer Day Berlin: The HTML5 Demos(mikewest.org)
2 points by mikewest 15y ago|0 comments
40.
by mikewest 15y ago
CSP doesn't block you from using social networking widgets: it does insist, however, that you specify up front which widgets you'll be using, and to whitelist those domains. If you trust Facebook's JavaScript, for example, you can certainly
41.
by mikewest 15y ago
As long as it's in an external JS file, sure. CSP simply prevents you from calling script inline. `<script>#('something').hide();</script>` wouldn't work: you'd have to move your JavaScript code into an external file. For ex
42.
by mikewest 15y ago
The big advantage over MacVim is that Vimroom works from the terminal, anywhere. I can use the plugin no matter which machine I'm logged into, which is pretty valuable to me. I fixed the only issue that was on the project before today (erro
43.
by mikewest 15y ago
And now it's there: http://www.vim.org/scripts/script.php?script_id=3766
44.
by mikewest 15y ago
I'll take a look at getting it up to vim.org. Thanks for your interest!
45.
by mikewest 15y ago
It is implemented using splits, so you're right: if you're already using split windows then your results will be a bit off. :) Regarding your settings, would you mind filing a bug report with some detail? I'm happy to try to fix things if t
46.
by mikewest 15y ago
Ok. Would you mind dropping me an email (mkwst@chromium.org) with details? I'm happy to file the ticket for you.
47.
by mikewest 15y ago
That will be possible with the WebRequest API, yes: http://code.google.com/chrome/extensions/trunk/experimental.... For example, you'd be able to intercept and block network requests from a particular tab that didn't hit the same domain.
48.
by mikewest 15y ago
Can you file a bug at http://new.crbug.com/ please? That doesn't sound like the behavior I'd expect.
49.
by mikewest 15y ago
Given that I'm responding to "I'm pretty sure Chrome send URLs to Google at least for indexing purposes." let's first agree that there's been no evidence provided that I can respond to. :) I mean both Chrome and Chromium. The source is ther
50.
by mikewest 15y ago
1. I wrote Keep My Opt-Outs. It has exactly the practical effect you're looking for with regard to DoubleClick and about 60 other ad networks _right now_. Installing it opts you out of interest based tracking in exactly the way that clickin
51.
by mikewest 15y ago
In `about:flags` there's an option to change third-party cookie blocking behavior to prevent reading third-party cookies as well.
52.
by mikewest 15y ago
Fingerprinting is a problem, and it's difficult to address. There's been some discussion around mechanisms for disabling features to make the browser signature less unique, but it's a very tough problem. Take a look at https://trac.webkit.
53.
by mikewest 15y ago
Thanks. It's now sitting in the Sync team's queue.
54.
by mikewest 15y ago
Chrome does not collect user information, unless you explicitly opt-in to sharing aggregated usage information and crash reports with Google. If you do opt-in to these metrics (and you have to opt-in, it's disabled by default), you can opt-
55.
by mikewest 15y ago
Chrome does not arbitrarily send URLs to Google. We go out of our way to avoid doing that, actually. Look at the implementation of SafeBrowsing, for instance, which does some clever work with hashes to ensure that Google never knows exactly
56.
by mikewest 15y ago
The main dev on the WebRequest API sits right behind me, and is making steady progress. It's the first synchronous extension API that interacts with the network stack, and it's a nontrivial effort to get it running. I can assure you, howeve
57.
IndexedDB: An Introduction to the JavaScript API(mikewest.org)
7 points by mikewest 16y ago|1 comments
58.
Suboptimal CSS Optimising (CSS pre-processing algorithms)(marknormanfrancis.com)
2 points by mikewest 17y ago|0 comments
59.
The Case for Context(newsless.org)
1 points by mikewest 17y ago|0 comments
60.
The Conversation: Ad Block This (Podcast)(5by5.tv)
1 points by mikewest 17y ago|0 comments

More ›