51–60 of 87 posts
Great read, not so sure why your page was awkward to scroll though. Here is more about Heap Profiling from the horses mouth https://developers.google.com/chrome-developer-tools/docs/he...
Disclaimer: I'm on the Chrome team and specifically focus on the Inspector/DevTools Majd and I have talked a lot about tooling and the Chrome DevTools in particular. He ends up tweeting me a few requests or bugs a day that I'm routing to the engineering team. I love it. Majd's writeup here is incredible. I hope to find a way to augment our existing documentation with this very thorough roundup. He's done a similar th…
Otherwise, thanks to the team for the improvements that I've been seeing lately!
"Modern Web Development" does not mean "Works in Webkit", and it does a disservice to future/novice developers to reinforce that notion. What's dominant now was not in the not-too-distant past, and may not be in the not-too-distant future.
When Mozilla ships better developer tools than Chrome, I'm sure there will be posts just like this one. The fact that developers prefer Chrome is not a failing of developers; it's a failing of Mozilla to provide compelling tools.
I'm not sure if docking to the right is really the best default; it really depends on your setup. On big, wide displays it's indeed a good way to do it. On small displays (notebooks) docking on the bottom is better. If you have multiple displays, detaching and moving the detached window to the other display works best. I think it's a good idea to assume the worst (tiny display) and dock to the bottom; the browser wil…
How many netbooks have anything other than a 16:9 display (even the MB Air 11")? Vertical pixels are precious in landscape mode. Dock to the side is far more efficient with current reality of displays. Let's put aside any frustration that 16x9 is even usable much less desirable for any office work.
Earlier quoted context omitted.
Thanks for letting me know, I didn't realize I broke that. I just pushed up a fix
Dunno if you've had that fix go live yet, but it's still unusable. The actual little scroll tracker (what's the name for that thing?) isn't discernible from the background. When you scroll up and down, the bar turns white and the cursor is white. I'd send a ss, but I don't see anyone else complaining so it's probably a me problem. Might be because I'm on Linux.
Earlier quoted context omitted.
Dunno if you've had that fix go live yet, but it's still unusable. The actual little scroll tracker (what's the name for that thing?) isn't discernible from the background. When you scroll up and down, the bar turns white and the cursor is white. I'd send a ss, but I don't see anyone else complaining so it's probably a me problem. Might be because I'm on Linux.
So the reason is because I have a black background color on body. When I said it's fixed, I just realized it's only fixed on Chrome Canary. It looks different on Chrome 18, and it looks different than that in Safari. Welcome to the Web. I'll try to fix it again after work.
"Modern Web Development" does not mean "Works in Webkit", and it does a disservice to future/novice developers to reinforce that notion. What's dominant now was not in the not-too-distant past, and may not be in the not-too-distant future.
When Mozilla ships better developer tools than Chrome, I'm sure there will be posts just like this one. The fact that developers prefer Chrome is not a failing of developers; it's a failing of Mozilla to provide compelling tools.
"Modern Web Development" does not mean "Works in Webkit", and it does a disservice to future/novice developers to reinforce that notion. What's dominant now was not in the not-too-distant past, and may not be in the not-too-distant future.
Earlier quoted context omitted.
When Mozilla ships better developer tools than Chrome, I'm sure there will be posts just like this one. The fact that developers prefer Chrome is not a failing of developers; it's a failing of Mozilla to provide compelling tools.
I don't know much, but I don't understand Mozilla's effort to reimplement firebug natively. Right now their solution seems unusable and far beyond firebug.
Earlier quoted context omitted.
It's true- I've spent a lot of time developing HTML5-based apps (i.e. in a webview) and am already surprised at how much worse the Android web engine is than the iOS one. Google should be all over this (and with the release of Chrome of Android, perhaps they finally are) but it baffles me that it took this long. Meanwhile, it took Mozilla to create Boot To Gecko, a true web OS.
The Chrome beta on ICS is great, but it's only accessible to Chrome Beta needs to be backported to at least 2.3
Can anyone explain why this is such a problem? Does Android not have a proper hardware abstraction layer or driver model that would allow OS updates immediately, as long as these layers remained compatible and a build existed for your processor family?
Windows has supported disparate hardware configurations for many, many years. Yet, generally, you can run out and buy the new version and install it. Why can't Android do this (albeit with a version for each processor)?