Everything else just flows from that.
Which versions of IE? I can't see much effort being put into anything less than IE8.
Regards,
Aparajita
www.aparajitaworld.com
"If you dare to fail, you are bound to succeed."
- Sri Chinmoy | www.srichinmoy.org
I've made simple apps work on IE6 and 7 and they just don't have the
javascript horsepower to work reasonably under any circumstance (and IE6
image transparency stuff would be crazy to try to fix and maintain).
Mike
Noted. Are you a regular IE user yourself?
I think your point that there is a limit to what can be done with some
of IE's problem areas is a good one. But we don't seem to make any
serious effort to sort out which ones are truly unfixable, and which
ones are just IE specific bugs that will require workarounds.
I'm just suggesting that it should be more of a priority - and yes I
understand that it is a pain in the neck to develop with IE as I've had
to do a fair amount of it for my work.
Mike
On 11-09-09 11:02 AM, Aparajita Fishman wrote:
>> As far as I can tell not much testing/development is done on any
>> version of IE. So any version would be better than none. IE8
>> onward for serious work is probably a good baseline.
>
> Noted. Are you a regular IE user yourself?
Only for development purposes. But plenty of my customers are IE users.
Mike
Of course I agree, but there is more than one IE, and the majority of IE's internet (vs. intranet) market share is IE8+. Limiting Cappuccino to >= IE8 makes a huge difference in the amount of resources necessary.
I think "tragic" is a better word for it. But look on the bright side -- at least it doesn't have to work on IE6! :-)
> I'm having a
> hard time getting it running acceptably.
> I don't know if this will
> actually have an impact or IE7 just sucks :-/
IE7 just sucks unfortunately. Its Javascript engine is just too slow. Right now your only hope is google Chrome Frame.
In the future I think we will have to state openly that only IE8+ is supported, this is the second time in a few weeks that someone has gotten towards the end of a project only to discover that it won't work acceptably on IE6/7.
It remains to be seen how much Objective-J 2.0 will improve the situation, but you should not wait for that, there is currently no target date for its release.
--
You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J Development List" group.
To post to this group, send email to objecti...@googlegroups.com.
To unsubscribe from this group, send email to objectivej-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/objectivej-dev?hl=en.
That depends on what version of IE you talking about and what you mean by "support".
If you are talking about IE < 8, then honestly it is supported only in the sense that a Cappuccino app will run. But it is not supported in the sense that anything but a trivial Cappuccino app will run fast enough to be usable.
Real-world users who have staked their reputation on Cappuccino are telling us over and over again that Cappuccino's performance is not acceptable -- and thus Cappuccino is not usable -- in IE6/7. And if we don't say that up front and honestly, people who depend on *usable* IE6/7 support may not find out until it's too late that such support doesn't exist, which may have serious negative consequences on their careers. That just isn't fair to our users.
Until we have a proven solution to this *in hand*, we cannot in good conscience continue to say that IE6/7 are supported for anything but trivial applications; the facts just don't support it. And no matter what *may* be possible theoretically with better Cappuccino technology, until that technology is being worked on actively, is realistically close to completion, and has proven to solve the problem, we have to deal with the reality we have right now.
In the not-too-distant future hopefully we can formally put this question to the community. If you look at IE internet market share, IE8 has the largest share right now, so I think we should try to support it.
When it comes to intranet market share, IE6/7 probably predominate, but they are missing out on all modern web technologies, not just Cappuccino, so what can we do...
Obviously 280 Slides is using an older version of Cappuccino, but in so much as it might get slower if upgraded, that seems like an issue worth working on in Cappuccino. To whatever extend we may have spent personal time making the 280 Slides application level code faster in IE, perhaps that's also a reasonable requirement for someone writing any app and trying to target older machines or browsers.
Obviously, no matter what we do, you can still write a slow application using Cappuccino.
280 Slides is unfortunately not a representative example. First of all, knowing the implementation of the framework allows you to make a lot of unconscious design decisions based on performance. Second of all, a lot of people are making applications that have significantly more complex UIs with CPTableView, multiple splitviews, etc.
> Obviously, no matter what we do, you can still write a slow application using Cappuccino.
Well, people tend to make their interfaces much more cluttered than perhaps they should be. And since Cappuccino is running within a single platform window, the temptation is to cram as much as possible into that one window. This leads to extremely complex screens and slow performance.
What did Safari change with resize events that killed performance? Is it just Safari or all WebKit browsers such as Chrome?
We should be able to use the profiling tools in WebKit to figure out where the performance bottleneck is.
https://github.com/cappuccino/cappuccino/issues/1325
Alexander
I would like to point out that it has *nothing* to do with Cappuccino and *nothing* to do with JavaScript. I loaded a file which had nothing more than this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<title>Test</title>
</head>
<body>
Hello.
</body>
</html>
Resizing is *horribly* slow -- 1 second behind the mouse. Chrome 14 beta does *not* share this problem at all.