What does Sencha 2 only work in Webkit browsers? I understand they require the Webkit engine, but why do they do this, what does this webkit engine have which the engines in Firefox / IE doesnt have? A browser consists of a HTML engine, CSS engine and Javascript engine - just for curriosity, is it the Javascript engine which is special with Webkit in respect of Sencha ?
When Sencha Touch started development, iphone, android and blackberry were the main platforms. All of them use a webkit based browser as default.
There were reasons told at that time like css transistions and image masking weren't supported by other browsers. I guess things might have improved now.
Size is also an issue. To support more browsers, more workarounds are required which increase the size of the framework.
From a business perspective, there isn't really a demand for supporting any other browser. If ie10 becomes big with Windows 8, they might support it as people have already asked about it their forums.
Someones already trying to make it work on Firfox. Here is the link.
Here are some posts from the forum
Post1, Post2
Related
I'm looking for an offline software that can speed up the testing of a website in different browsers.
Yes, I can install Opera, Firefox, Chrome, IE and Safari and test in each one, but this slow down the process because there are a lot of changes to be done in the website I am working and each change must be tested in all browsers.
More specifically, I am looking for something similar to IETester, but for different browsers. I'm not interested in online services (there are a lot), but offline.
So, someone knows something like this?
I find the Selenium tool [ http://seleniumhq.org/ ] very useful for such needs:
there are drivers for almost all modern and not-so-modern browsers: firefox, IE, Opera, Chrome, Safari..
scales quite well through the webdriver thing (remote control execution of tests on many different hosts), and
is well established: there are many resources available around to develop and deploy it.
Main drawback, as for my own experience: the learning curve is somewhat tough.
There is also a nice test management tool especially targeted at Selenium: Bromine (disclaimer: I did not yet use Bromine, but saw great comments on it).
Regards,
--
boris
Adobe BrowserLab for Desktop Browsers (Free) As noted in the comments, this has been discontinued. But they recommend Sauce labs, and Browser Stack instead.
Adobe Edge Inspect aka Shadow is also available and does all the above quite well. It is primarily for Mobile Browser testing and debugging.
Microsoft's Expression Suite also has its own Cross-Browser Testing utility, called Expression Web Super-Preview.
In Microsoft's words,
You can view browser renderings side-by-side horizontally or
vertically, or overlay them to identify differences. You can use
rulers and guides to measure and highlight visual problems. You can
zoom in and out of a page and see all the browser renderings update in
tandem.
You can try BrowseEmAll (http://www.browseemall.com) which is a desktop application for windows (and sadly windows online).
Still it contains all major browsers and simulators for iOS and Android which should make the testing easier than switching between different browsers manually.
If you like groovy, then try Spock.
I've experimented with Spock and Gem for BDD tests.
I am looking for some start up guidelines to share their experience on XUL development in web application. How good is the option to develop the interface in XUL ?. Can IE understand XUL interface?. I have started reading about XUL and I am liked confused a lot.
Please share your development experience on XUL development.
Thanks
XUL is a Mozilla-only technology meaning that it will only work in Firefox and other browsers based on the Gecko engine. I have bad news for you though: Firefox 4 (meaning Gecko 2.0) disabled support for remote XUL for security reasons, so using it in web applications will no longer be possible. It was arguably a bad idea in the first place.
Take a look into Ample SDK UI Framework, XUL (see examples) is just one of the several XML-based technologies it enables across all browsers, also in IE6.
The ZK web framework (www.zkoss.org) is based on XUL. Actually the web pages you built, using this framework, have the extension ZUL. It produces html + ajax code capable to run in all modern browsers. We are using it in my company for two years now and i have to say it changed my view about XUL.
I spoke to the boss of a major music software company a few years ago. He told me that if they were going to start again from the ground up, they might look at WebKit for their UI. This totally surprised me. But I'm wondering if other folks are thinking and acting this way. Is webkit working its way in to truly non-web software?
RealPlayer, iTunes, and many other applications are using it, so are some non-"web" apps such as desktop widget programs:
http://trac.webkit.org/wiki/Applications%20using%20WebKit
Designing "web-apps" with HTML/Webkit UI is beneficial for Mobile users, since many devices have Webkit built in. Even if it is currently only used on a PC, you would have the possibility of hosting it on the web or local network later, with less work to convert it.
Gwibber, a Gnome twitter client that ships with Ubuntu, uses WebKit for displaying timelines (although it uses normal GTK+ widgets for the surrounding UI).
I would consider WebKit a viable option for many pieces of UI, particularly if the program shell exposes appropriate hooks into the surrounding platform to do things like launch a real browser or hook in to system notifications. You run the serious risk, however, of building an application that doesn't fit well in the UI conventions of the user's operating system.
It's not WebKit, but building a UI on a rendering engine is essentially what Mozilla does - Firefox, Thunderbird, etc. are built in XUL rendered with Gecko.
Anything you can do on webkit can be wrapped as an application easily with PhoneGap or other tools.
For example, store.sonyentertainmentnetwork.com could be wrapped as an OSX app, an Android app, and still act as a regular website very easily.
Also: https://products.sel.sony.com/opensource/source_webkit.shtml
If my app has been tested in Firefox 3, Safari 3 & IE 7 will it need additional testing for Chrome?
If there are areas that'll need further testing -- then are there any online guides I could share with my designers & developers?
At what point will Chrome be considered to have sufficient market share to be treated as a mainstream browser?
If it's working fine on Safari, it will probably work on Chrome as well. The only difference is the JavaScript engine, but I've yet to see a real world example of some legitim JavaScript code not working on Chrome.
Personally I test my stuff with Chrome because I use Chrome intensively for development. It is good practice to test your pages with at least one WebKit (or KHTML) based browser though.
Chrome uses the WebKit rendering engine, which is also used in Safari and some other small browsers. Overall with both Chrome and Safari gaining in market share it is definately a browser to test (you only really need to test one). It's very standards compliant and is constantly having updates to keep up with new CSS drafts.
Webkits main Site - http://webkit.org/
Browser Market Share
http://www.w3schools.com/browsers/browsers_stats.asp and http://en.wikipedia.org/wiki/Usage_share_of_web_browsers are good places to look for market share of browsers although they show very different responses on Chrome.
According to Wikipedia roughly 7.96% of poeple are using WebKit based browsers however W3C shows that in November only 5.8% did.
Theoretically, because Google Chrome uses the same engine as Safari (WebKit), you've already tested. But Google has made several changes to the engine, including rewriting the JavaScript interpreter completely. Additional testing never hurts and it wouldn't take long to confirm that everything works as expected.
Now that GMail suggests people switch from IE to Firefox and Chrome, I'm guessing we'll see IE lose more and more market share to those browsers. Chrome doesn't have much of a user-base now, but I can imagine that will change.
Better test on it. I've already run across sites that work in Safari but don't in Chrome. I have IE8b2, FF3, Safari, and Chrome all installed on my machine. Not for testing reasons, but because of the websites that I visit. Takes all 4 of those to get all the websites to show right...
if you don't have PNG24 with opacity changed from CSS, all things should be fine.
However, i always try in all modern browsers (ie6/7, ff2/3, opera 9.x, safari and chrome).
According to Wikipedia, Chrome has a 0.78% usage rate right now. Depending on your audience the actual number of users might be low, and not really require testing.
Chrome uses the WebKit engine, which as I recall is the same engine used by Safari. So in theory, if your site works for Safari it should work for Chrome, as well.
Refer to this Google's Chrome page for details.
Chrome already got a small percentage of the community. However as far as I know, Chrome follows the standards from W3C and all websites that work in IE6, IE7 and FF2 / 3 has worked perfectly for me.
So by that said, i think you should already be testing your applications in chrome as well.
Always test in these browsers nowdays:
Internet Explorer 6, 7, 8
Firefox 2, 3
Chrome
Opera
Safari
Lynx
Tools like Selenium are good for testing user interactions on the web UI. However, I was curious what are people approaches for strictly testing and verifying that web pages are rendered correctly across a set of browsers?
Is this even possible?
May I recommend browsershots where you can submit pages and have them rendered out in a variety of browsers with various things set on or off such as Flash and JavaScript. At the end of the day you will still want to install FF, IE6-8, Opera and Safari/Chrome for testing manually. Also, if you've got a friend with a Mac (or a PC if you're using a Mac) get them to test in Safari too as I've personally found differences in the way both of them render the same page.
I'd also recommend that you develop mainly in Firefox and regularly check it in IE6 as you work. IE6 is the one that will mostly screw up so if it's working in both it's more likely to be working in all.
When you find rendering weirdness try and fix it in your markup and CSS first before resorting to CSS hacks as they can lead to 'interesting' problems later or in other browsers.
There is only a handful of browsers you need to test, as some share a common rendering engine (Gecko or Webkit). Without explaining which or why, here's the current wisdom (2009):
Build your site using Firefox or Opera (on any platform). BTW Opera uses its own Presto engine;
Test in whichever of the above you didn't use.
Validate the (X)HTML and CSS (important!).
Test it in >=IE7 and note the glitches, if any.
Use conditional comments in separate stylesheets for each version IE - never use CSS hacks as they'll go out of date.
Test in IE <7 if you like and do the same, or use conditional comments to ask users (politely) to upgrade their version of IE.
Test in Safari (Webkit).
Don't test in Chrome, you already have by proxy (Webkit)!
Don't test in IE for Mac - the share is too low and it's no longer updated.
Finally, try enlarging the text in Firefox, Opera, IE and Safari. Opera also has a hand-held emulation mode for mobiles.
You will have now covered (theatrical guess) 99.9% of browser setups. If you're on OS X or Linux, you can run Windows in a virtual environment like Parallels or Wine. Apparently Wine also has a Windows binary, but I couldn't find it. Caution: you'll need to be sure that your virtual environment allows IE to read conditonal comments.
In practice, I find that if a site has valid code and works in Firefox, Safari and Opera, it'll probably be okay in IE7 up. The only HTML/CSS gotcha is IE's 'haslayout' handling. If you don't have the browsers, BrowserStack is an excellent online testing service.
Finally, if you're using Javascript, you'll need to go through a similar process, problem being that as a rapidly developing area, newer versions of some browsers handle Javascript in increasingly effective ways, so functions in older versions might break or fail quietly.
If you just want to see if layout is correct, just submit your website to BrowserShots.org and visit later to see the screenshots.
If you want to test the functionality (JavaScript, etc.) then you'll need to test manually.
Manually?
I do not see an alternative if you want strict testing. Just install as many different browsers as possible and test in all of them. Of course this includes different versions of most popular browsers, and you need to check on Windows, Linux and Macintosh.
Previously I was use WM for different versions of IE, but I find out some new tool for testing layout, and UI as well with this tool, link for FF use fire bug extension, those tools are for manually testing.