3 ms·
A couple reasons not to do this: 1. Your frameworks are out of sync with the the rest of the system, could cause problems updating. 2. You're now running supe
by JacksonGariety 14y ago
A couple reasons not to do this:
1. Your frameworks are out of sync with the the rest of the system, could cause problems updating.
2. You're now running super-buggy development WebKit. The code you're using was written a few hours ago, remember that.
3. The old WebKit inspector doesn't have retina support. If you've got a rMBP and care about how it looks, don't do this.
4. The article gives no information on how to go "back" after you've done it.
- philfreo 14y agoMy comment on the post shows how to go "back"
- jarek-foksa 14y agoIt's developement version, but I wouldn't call it super-buggy. WebKit project has strict development process, each commit is rigourously reviewed and tested before merging. You will likely run into problems if you enable experimental flags though.
- bdash 14y agoWhile the WebKit project has a strict review process and a substantial amount of regression testing, code reviews can't catch all issues and WebKit doesn't have complete test coverage for all aspects of web technology. Changes can, and often do, introduces regressions from subtle rendering errors to all-out crashes. These sorts of temporary issues aren't that a big deal if it's in a separate application that you use only for testing, but they're a darn sight more painful when you replace your system WebKit frameworks and they start impacting things like your email client or the system installer stack.