It most likely should be something like "Safari (stable build)", and similar for the others.
Thanks for the write-up.
61–70 of 87 posts
It most likely should be something like "Safari (stable build)", and similar for the others.
Thanks for the write-up.
This is a great resource and I'm glad Majd wrote it. However, this is really the kind of content that should be coming out of Google itself. Google is in an interesting position. Of all of the major Silicon Valley tech companies, I think Google is the one most seen as the "web" company, and yet they've staked a lot of their future on Android. Android, instead of making the web a first-class citizen, has in fact set t…
Android, instead of making the web a first-class citizen,
has in fact set the mobile web back by years.
I don't know how you can come to this conclusion. Android has made an excellent mobile web browser available to over a quarter of a billion people.And how is the web not first-class? Google even started Web Intents to interoperate web apps with native apps.
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…
Earlier quoted context omitted.
AFAIK it also doesn't make any difference to apps that use webviews. I mean, it's just as well- if you changed the underlying engine without notifying devs insanity would ensue. But it would be good to be able to set a flag that says "use the decent engine".
You're correct. But no reason google couldn't add a ChromeWebView lib as part of the install of the new browser for PhoneGap to wrap.
Earlier quoted context omitted.
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.
I don't know, I definitely prefer scrolling vertically (in both panels) on my MBA 11" to horizontally scrolling every time I need to read a line in its entirety. 680px wide just isn't enough for the inspector. That said, 1366x768 is certainly not on optimal resolution for development, period!
Earlier quoted context omitted.
The Chrome beta on ICS is great, but it's only accessible to Chrome Beta needs to be backported to at least 2.3
"ICS has been out for months, and the providers are completely dragging their feet on it." 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…
For example, I worked on an app to be included with the device by the OEM. The OEM had roll a custom OS and kernel to handle their hardware and replace/update the mail and calender app because they are very tied to Google by default. We needed hooks into the the mail and calendar app in ways that are not supported by Google so the OEM also had to add those hooks for us. At this point, we were deep into unsupported territory by Google, but supported by the OEM. These things change unexpectedly with minor OS updates from Google which make them brittle to maintain. An update to a newer OS would be a hell of a lot of work.
All that said, if we could have based off of 3.0 instead of 2.3, many of these issues would not exist because of some abstraction layers added just for this purpose. I expect 4.0 to make that even nicer.
Earlier quoted context omitted.
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.
They're reimplementing it because Firebug is an unmaintained mess.
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.
Don't get me wrong, I do the same thing, but you have to admit there is a certain dry humor in the fact that you recommended as a best practice to develop exclusively in a cutting edge build of a standards-based browser, only to find that your website is broken in every browser except your development one.
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…
I hope Chrome will have this feature in the future.
Earlier quoted context omitted.
I acknowledge WebKit's monopoly on the mobile landscape today, I make no claim whether it's a good thing or a bad thing, that argument would distract from the reality that if you want to make a mobile web app work well, you need to build it on webkit and debug it on webkit
... and test it cross-browser. WebKit has a majority on mobile (around 75%) but not a monopoly. (Source: http://gs.statcounter.com/#mobile_browser-ww-monthly-201103-... )