一个网站,FF浏览器、NS、IE浏览器都可以兼容吗?用什么语言编写?

因为对网站代码和浏览器解析方面的理解不是很多，目前只制作过一些网站的模版，所以这个问题，我就以我目前的经验和理解来解答一下，希望对楼主有帮助
正如楼上所说，不同内核的浏览器对于代码的解析不同，不同内核浏览器对代码的解析不同，他们对规则的理解或执行不同造成了网页变形等情况。而对于这种变形走位的情况，我在之前做网站模版的时候在IE和Chrome浏览器上面遇到过，这些也多数是网站布局CSS样式表的问题。
一般而言，确实没有什么捷径，皆需要在不同的浏览器之间经过不断的测试，所以跟语言并没有多大关系

Managed extensions in C++.NET

对Microsoft Visual C++语言进行扩展可以生成．NET代码，这些扩展称为C++．NET托管扩展。C++是惟一一种可以在同一个源文件中混合．NET代码和非托管代码的语言，是真正的．NET系统语言。
　　C++托管扩展是微软为了让Visual C++可以支持托管的引用程序的开发而对传统C++语言进行的扩展，是新一代Visual C++开发工具的语言核心。
　　C++引入托管扩展的原因是既可以保持与原有C++特性的充分兼容；又可以提供足够的对.NET应用开发的支持
　　托管C++应用程序开发之概述
　　1、什么是托管C++
　　托管是.NET的一个专门概念，它倡导一种新的编程理念，因此我们完全可以把“托管”视为“.NET”。由托管概念所引发的C++应用程序包括托管代码、托管数据和托管类三个组成部分。
　　托管代码
　　.Net环境提供了许多核心的运行(RUNTIME)服务，比如异常处理和安全策略。为了能使用这些服务，必须要给运行环境提供一些信息代码(元数据)，这种代码就是托管代码。所有的C#、VB.NET、JScript.NET默认时都是托管的，但Visual C++默认时不是托管的，必须在编译器中使用命令行选项(/CLR)才能产生托管代码。 
　　托管数据
　　与托管代码密切相关的是托管数据。托管数据是由公共语言运行的垃圾回收器进行分配和释放的数据。默认情况下，C#、Visual Basic 和 JScript.NET 数据是托管数据。不过，通过使用特殊的关键字，C# 数据可以被标记为非托管数据。Visual C++数据在默认情况下是非托管数据，即使在使用 /CLR 开关时也不是托管的。
　　托管类
　　尽管Visual C++数据在默认情况下是非托管数据，但是在使用C++的托管扩展时，可以使用“__gc”关键字将类标记为托管类。就像该名称所显示的那样，它表示类实例的内存由垃圾回收器管理。另外，一个托管类也完全可以成为 .NET 框架的成员，由此可以带来的好处是，它可以与其他语言编写的类正确地进行相互操作，如托管的C++类可以从Visual Basic类继承等。但同时也有一些限制，如托管类只能从一个基类继承等。
　　需要说明的是，在托管C++应用程序中既可使用托管类也可以使用非托管类。 
　　在托管C++中，托管类和非托管类是可以相互使用各自的特征，但托管类能够封装.NET框架中的组件，且最大限度地使用.NET框架中的特性，而传统的C++类是使用MFC和ATL来设计的，用来编制基于Windows环境的应用程序。
　　2、为什么使用托管C++
　　除了可以充分发挥.NET框架新特性外，使用托管C++还有下列好处：
　　(1) 由于在同一个应用程序中，甚至是同一个文件中，我们可以同时使用托管C++和传统的非托管C++来编写，因而我们可以充分利用两种C++所带来的好处，并且可将代码和组件快速移植到.NET框架中。
　　(2) 使用托管可以从任何一个.NET框架兼容语言中调用一个C++组件，也可调用非托管DLL、其它库以及类等。
　　(3) 可以直接从非托管代码中访问.NET框架。
　　总而言之，使用托管C++是C++程序员编写.NET框架应用程序最好的一种选择，在充分理解.NET框架基础上，避免了使用其他语言如C#、VB.NET所带来的额外开销。
　　为什么使用C++托管扩展
　　微软既要考虑Visual C++的兼容性，又要让传统C++语言具备足够的能力开发.NET应用程序，于是在新版本的Visual C++中，引入了C++托管扩展。
　　在整个Visual Studio开发套件中，微软为了迎合.NET应用程序开发模式的要求，几乎对每个工具都作了或大或小的改进。其中，VB的变革力度应用微软各种软件产品之最。但是太大的变革往往会带来兼容性问题，特别是新版本的VB宣称其只能开发托管的应用程序(也就是.NET应用程序)，所以对开发人员来讲，这肯定意味着过去使用VB编写的代码在新版本VB上进行重新构造的难度会很大。VB以前就在版本兼容性方面有着不如人意的历史—— 在VB4、VB5、VB6之间进行升级，会让开发人员付出很多辛苦。现在，由于VB的体系进行了很大的改动，所以版本兼容性问题会更严重一些—— 笔者已经在微软几个官方讨论组中看到了一些开发人员和相关人士对此表示出来的担忧，并看到不止一个开发人员对新版本VB在兼容性方面存在问题提出质疑甚至是批评。
　　作为微软开发套件中的另一位“元老”—— Visual C++，我们对其提供完整的.NET开发支持感到高兴的同时也同样担心它的版本兼容性问题—— Visual C++该不会也和VB一样，彻底与MFC和ATL分裂吧？答案是：不可能！
　　这是一个令人振奋的回答，下面就让我们花一点时间来了解新版本Visual C++是怎样处理变革和向下兼容之间的关系的。
　　另外，之所以微软对VB进行那样大的改革，是因为微软认为VB通常适用于快速应用程序领域，这些领域一般包含对效率要求不是很高的数据库前端应用程序或后端业务组件。当更为优秀的.NET框架发布之后，微软就为VB换了换“心脏”，以期大幅度增强VB的功能，使之成为快速开发.NET应用程序的主力军。而对于Visual C++这样一个在许多传统领域依然宝刀不老的工具，当然不能急躁冒进，将已有的功能丢弃。所以，在新版本的Visual C++中，采用了一种更为折衷的方法—— 扩展现有C++语言，让Visual C++在编写纯粹的.NET应用程序的同时，依然可以利用其成熟的技术进行未托管的应用程序的开发。
　　C++托管扩展是一个对现行C++语言进行扩展的集合，这个集合可以帮助Visual C++的开发人员编写.NET Framework应用程序。由于是对语言做了扩展，而不是彻底去掉原先C++语言的功能，所以在托管扩展中，开发人员可以在同一个应用程序中混合使用传统未托管的代码和新型的托管的代码。这样做得到的一个直接好处是，应用程序既可以享受未托管的代码特性也可以享受托管的代码特性。对组件开发也是一样，传统组件可以很容易被包装(wrapper)成.NET 框架组件，充分保障已有工作的投资。
　　在实际工作中，如果开发人员遇到下列开发需求，使用托管扩展将是最佳选择：
　　● 需要快速地将未托管的C++应用程序合并到.NET框架中
　　对于以前开发的传统未托管的C++应用程序，因为开发人员可以在同一个应用程序中(甚至是在同一个文件中)混合使用两种类型的代码，所以托管扩展为实现两种代码的无缝转化提供了一种平滑的转化方式。
　　开发人员可以继续使用未托管的C++来编写组件，以利用语言本身强大的功能和灵活性。然后，为了让.NET 框架应用程序顺利访问这个传统组件，开发人员可以使用托管扩展编写一个很小的、转换效率很高的包装(wrapper)程序。
　　● 需要让任何一种与.NET框架相容的语言可以访问C++组件
　　托管扩展支持从任何.NET 框架相容语言来调用C++类。调用之所以可以实现，是因为使用托管扩展可以编写简单的包装类来对访问方暴露对应的C++类和方法。这些包装类都是托管的，并可以从其他.NET框架相容程序中进行调用。在调用过程中，外包类在托管的类和未托管的类之间扮演了映射层的角色—— 它让方法调用直接传递到未托管的类中。另外，需要特别指出的是，托管扩展支持对任何未托管的DLL或库的调用。
　　● 需要从未托管的代码中访问.NET框架类
　　为了得到更多的功能，在未托管的代码中，可以访问.NET 框架中的类。使用托管扩展，可以从C++代码中直接创建、调用一个.NET 框架类。在实际编程中，可以像处理普通未托管的C++类一样对待对托管的类的处理。另外，在.NET框架中提供了对未托管的COM的调用支持，可以编写未托管的代码直接访问。
　　因为托管的代码和未托管的代码各有优点，在实际工作中，开发人员可以根据项目的实际情况，灵活选择两者的使用。在某些追求访问效率的情况下，通过.NET 框架提供的COM接口进行访问可以收到比较好的运行效果；而在某些需要快速完成任务的情况下，利用.NET 框架提供的简便性进行工作会让开发人员倍感轻松。
　　托管C++并非独立存在的编程语言，而仅仅是微软对C++的一个语法扩展，允许C++程序员在.NET框架和CLR的基础上进行托管编程。与C#和Visual Basic .NET相比，其主要优点是旧代码可以比较快地移植到新的平台上，而且即使不完全重写代码，也可以通过互操作在同一个模块中无缝整合托管和非托管代码，从新的.Net框架中获益。.Net框架封装了大量的API，例如网络访问、字符串操作、数据访问、XML服务、图形界面控件库、邮件服务、加密服务、文件输入/输出，甚至是WMI管理，也使得应用程序员可以编写更加简洁的代码。目前只有托管C++及其后继者C++/CLI可以做到无缝整合托管和非托管代码，而在托管代码中调用COM的速度又相当慢，所以经常被用于其他语言和非托管代码之间的桥梁。
　　托管C++允许程序员编写托管代码，内存管理的工作现在可以让CLR去自动处理，访问时也增加了类型检查，减少了缓冲区溢出和内存泄漏的危险，增加了程序的稳定性，但是在性能敏感的应用中，庞大的.NET框架和缓慢的自动内存管理并不是必要的，传统非托管代码仍然是一些人的首选。