Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
ASP.NET Server Controls - behaviour
Message
Information générale
Forum:
ASP.NET
Catégorie:
Autre
Divers
Thread ID:
00687116
Message ID:
00687240
Vues:
14
>Sure, but what about FUTURE versions of non-MS browsers???? Now I am to trust MS code to do a best-render job for those (that they want out of the way)?

Microsoft does have an incentive to make ASP.NET work with future non-MS browsers, just the same as they have an incentive to make VFP work with Oracle, IBM, etc. databases. If they don't, word will spread, and they are going to get some negative publicity. And with .NET still not taking off, that is one of the last things they want. While MS owns the browser market, they are still competing with Sun, IBM, etc. in the web services area. It wouldn't make sense for them to totally ignore the other browsers, since they have alreay won that battle.

>From your cautious opening I'll assume that you are guessing here. But assuming that it *IS* MS that writes the code for future versions of non-MS browsers (to deliver vest-rendering via ASP.NET), does it makes sense to trust them to do a BEST-POSSIBLE rendering in all cases? And what about lead times to get this done?... Do they have to obtain pre-release copies of other browsers in order to be able to do this?...Is that likely to happen?... What about bug-fix releases for those other browsers?

Yes, I am guessing. But it makes sense that someone at Microsoft does it, rather than someone at AOL, or Opera. I don't think it is that difficult of a task. The capabilities and anomalies of the major browsers are known to a lot of web developers.

>OK. But browsers are not released on the same schedule as ASP.NET or the .NET framework or anything else related to MS. Will they have to be now?...Will other browser suppliers live to this? Or will the components in question have to have some other 'update' facility tied to such things as new/revised OTHER browser releases?

No, but generally, browsers are backward compatible. A page that displays well in Netscape 4.x is going to display in a new version, unless there is a bug. So if a new version of Netscape comes out that the framework does not recognize, I imagine that it would drop back down to the version it does recognize.

>No, Chris, I'm talking about that part of the internal ASP.NET (or framework) code that is responsible for the "best-render" capability INTERNAL to the MS component(s) implied. As OTHER browsers are fixed or enhanced or released in new versions then either new code is required OR old code needs to be changed to do the "best-render" job. Can we identify, add/update/remove THAT code so that, if it should happen to break some existing and working (under the old code) stuff it can be replaced?

My guess is that if the framework does not recognize the new browser, it will drop back to the version it does recognize. And you will still get a good-looking page. And although both MS and Netscape were notorious for adding there own HTML tags, hasn't that somewhat ended? I think with MS owning the broswer market, it is unlikey, or at least unwise, for AOL or Opera to add a bunch of new tags, then complain when the new tags are not supported.

>Well it looks to me that I may need to be able to do this stuff, and it is mainly because of these concerns that I posed the question I did at the end of my original (can someone who knows enlighten me as to how MS plans to accomplish this).

Why do you think you may need to do some of it?

>I agree that that is a most fine objective. I'd like to know how MS plans to accomplish this in the context of new/revised non-MS browser releases, how they plan to distribute such changes that may be needed as a result, and how I can manage them (especially when things go buggy, as is bound to happen from time-to-time).
Chris McCandless
Red Sky Software
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform