Este artículo proviene de un motor de traducción automática.
HTML5
Detección del explorador y de características
P. Sascha Corti
El sitio web que creamos no sólo debe verse espléndido hoy; también tiene que seguir deslumbrando a los usuarios durante mucho tiempo. Esto significa que el sitio no sólo debe funcionar con los exploradores actuales, sino que también con las versiones futuras. En este artículo presentaré algunas sugerencias y recomendaciones que le ayudarán a conseguir este objetivo.
Breve historia
Hoy en día, todos los exploradores Web se crean con un objetivo común: representan las páginas Web de forma óptima con arreglo a las especificaciones más recientes.
Esto no siempre era el caso. En el pasado, como proveedores de exploradores corrieron a convertirse en dominante, más implementa las características de alta demanda, incluso si ellos aún no se han estandarizado. Por supuesto, cada navegador hice a su manera. Éste es un ejemplo de cómo establecer la transparencia en CSS variado.
Internet Explorer versión 8 había entendido el CSS siguiente:
.transparent { /* Internet Explorer < 9 */
width: 100%;
filter:alpha(opacity=50);
}
mientras que Firefox tenía su propio atributo:
.transparent {
/* Firefox < 0.9 */
-moz-opacity:0.5;
}
como hizo Safari:
.transparent {
/* Safari < 2 */
-khtml-opacity: 0.5;
}
Ahora, sin embargo, en CSS3, hay una forma unificada para establecer la transparencia de un elemento:
.transparent {
/* IE >= 9, Firefox >= 0.9, Safari >= 2, Chrome, Opera >= 9 */
opacity: 0.5;
}
Aunque pueda parecer bueno para un explorador ir más allá para admitir las funciones no estándares, hace la vida de un desarrollador Web más difícil de ser necesario, porque tiene que tomar todas las distintas implementaciones de la función en consideración cuando se agrega a una página.
Marcado coherente
La mejor manera de asegurarse de que la página Web se representará de forma óptima en todos los exploradores es centrarse en el marcado que es seguro que se admita en todas las versiones actuales de los exploradores.Hasta hace poco, se trata de HTML 4.01, un estándar de 10 años con características muy limitadas.
Hoy en día, todos los exploradores convergen hacia el HTML5 de características, pero muchas de las nuevas especificaciones resumidas debajo de ese término general, incluyendo el marcado de HTML5, su API como, por ejemplo, DOM niveles 2 y 3, CSS3, SVG y EcmaScript 262, están aún en desarrollo y, por tanto, sujeta a cambios.Los proveedores de exploradores continuamente agrega soporte para las nuevas características de HTML5, pero a ritmos muy diferentes.
Firefox y Opera es generalmente muy rápido a adoptar nuevas especificaciones de HTML5, a veces incluso los de desarrollo temprano y sujeta a cambios o tienen problemas de seguridad.Si bien esto puede ser interesante para los desarrolladores probar nuevas características, puede conducir a páginas Web que romper entre versiones de explorador debido a cambios drásticos entre una especificación y su aplicación.Es una experiencia frustrante para los usuarios y desarrolladores.Un ejemplo de esto fue Websockets entre Beta 7 y 8 de la desactivación de Firefox 4 debido a razones de seguridad.
Cromo, que es también muy rápido a adoptar nuevas normas de HTML5, agita recientemente la Comunidad HTML5 con el anuncio que fue abandonar la compatibilidad con el códec de vídeo h.264 popular para HTML5 <video> elementos y en su lugar a la norma de WBEM libre de regalías.Aunque esto puede ser útil para los desarrolladores que pagan actualmente para las licencias de h.264, agrega otra opción que los desarrolladores tendrá que realizar un seguimiento de a compatibilidad con exploradores tantos como sea posible.
Microsoft es más lento aplicar las normas, pero pero trabaja estrechamente con el W3C para generar conjuntos de pruebas, ayudando a minimizar la ambigüedad en las especificaciones y creación de una base técnica para ayudar a los proveedores trabajar en homogeneizar la forma en que sus exploradores generar HTML5.Para ver el último trabajo en esta área, eche un vistazo a Internet Explorer 10 Platform Preview, que encontrará en IE Test Drive.También desea retirar el HTML5labs donde cuerpos Microsoft prototipos tempranas, inestables especificaciones de estándares Web como, por ejemplo, el W3C.Consulte la sección "interoperabilidad mejorada a través de la compatibilidad con estándares," de la Guía de Internet Explorer 9 para los desarrolladores para obtener información detallada sobre cómo Internet Explorer 9 soporta las diferentes especificaciones de HTML5 en la actualidad.
Aún así, porque los nuevos estándares de HTML5 siguen siendo un objetivo en movimiento, y porque la mayoría de los usuarios de Internet no utiliza las últimas versiones de los distintos exploradores Web, servir el marcado correcto es más importante que nunca.
Detección de explorador
Un método para controlar las diferencias entre ellos es utilizar la detección de explorador.La forma más común de hacerlo es usar JavaScript para consultar el encabezado de agente de usuario:
<script type="text/javascript">
if ( navigator.userAgent.indexOf("MSIE")>0 )
{
// Run custom code for Internet Explorer.
}
</script>
El problema con este enfoque es doble. En primer lugar, reúne varios supuestos sobre las funciones que admite el explorador en un cheque. Una única hipótesis equivocada puede romper el sitio. Así como desarrollador que hay que realizar un seguimiento de cada versión de un explorador específico de exactamente las funciones que admite.
El segundo problema es que esta comprobación de explorador no tiene las versiones de exploradores en consideración y por lo tanto, no es compatible con tecnologías futuras. Incluso si funciona con la versión actual de un explorador, no se necesite la próxima versión — o peor aún, puede quitar apoyo por completo para — una solución que se utilizó la detección de explorador para agregar al sitio.
Por lo tanto, si tiene que utilizar la detección de explorador, asegúrese de que la versión tenerse y sólo utilizar este método para detectar los navegadores antiguos, como se muestra en figura 1.
Figura 1 detección de exploradores de versiones anteriores
<script type="text/javascript">
functiongetInternetExplorerVersion()
// Returns the version of Internet Explorer or a -1 for other browsers.
{
var rv = -1;
if(navigator.appName == 'Microsoft Internet Explorer')
{
var ua = navigator.userAgent;
varre = newRegExp("MSIE ([0-9]{1,}[\.0-9]{0,})");
if(re.exec(ua) != null)
rv = parseFloat( RegExp.$1 );
}
return rv;
}
functiononLoad()
{
var version = GetInternetExplorerVersion()
if (version <= 7 && version > -1)
{
// Code to run in Internet Explorer 7 or earlier.
}
}
</script>
La página de MSDN Library, "detectar exploradores más eficazmente," tiene más información, y encontrará un completo artículo sobre cómo utilizar el objeto navigator y expresiones regulares para detectar los distintos exploradores y sus versiones exactas en Tutoriales de JavaScript.
A partir de la versión 5, Internet Explorer tiene la única manera de detectar exploradores que utilicen los comentarios condicionales. Esta sintaxis extiende a los comentarios HTML estándar. Puede utilizar estos comentarios condicionales con una CSS para implementar determinadas Internet Explorer-específicos reglas de CSS que desea que otros navegadores para omitir. En el siguiente ejemplo, "ie7.css" sólo se carga si se detecta Internet Explorer 7 o anterior:
<!--[if lte IE 7]>
<style TYPE="text/css">
@import url(ie7.css);
</style>
<![endif]-->
Puede encontrar información detallada sobre cómo utilizar los comentarios condicionales en la página de MSDN Library, "acerca de los comentarios condicionales."
Dado que todos los problemas y limitaciones de detección de explorador, no obstante, echemos un vistazo a una alternativa.
Detección de función
Una alternativa mucho mejor a la gestión de las diferencias entre los exploradores Web es utilizar la detección de característica. Antes de utilizar una función que tenga diferentes implementaciones en varios exploradores, ejecutar una pequeña prueba que busca la disponibilidad de un objeto específico, método, propiedad o comportamiento. En la mayoría de los casos esto puede hacerse al intentar crear una nueva instancia de la función en cuestión y si esa creación de instancias devuelve un valor distinto de null, el Explorador de ejecución sabe esta característica. Si no es así, puedes seguir comprobando la disponibilidad de una solución o una implementación propiedad heredada de la función.
Comparación de explorador y detección de función
Vamos a utilizar los diagramas en las figuras 2, 3 y 4 para ayudar a ver cómo funcionan los dos enfoques en diversas situaciones.
.png)
Figura 2 posibles rutas de código a través del sitio de prueba
.png)
Figura 3 resultados con las configuraciones de explorador conocido
Cuando se enfrentan con configuraciones de explorador conocido, ambos métodos funcionan, pero detección de explorador tiene fijo supone que la función a y b de la función son compatibles con el navegador, mientras que pruebas de detección de función para cada función individualmente.
.png)
Figura 4 configuración de explorador desconocido
Es cuando se enfrenta a una configuración de explorador desconocido cosas interesantes. Detección de función controla esta bien y descubre que el explorador es capaz de mostrar una función pero necesita código de reserva para la función B. Detección de explorador, por otra parte, toma una ruta de acceso basado en el nombre del explorador o elige la ruta predeterminada porque ninguna de las combinaciones de la versión de explorador consultado coincide con. En cualquier caso, en este ejemplo la página no se representará correctamente porque no hay ninguna ruta de acceso de código que conecta todos los segmentos de código válido, aunque la página contiene todo el código necesario para mostrar correctamente en esta configuración de explorador desconocido.
Ejemplos de detección de función
Hay dos recomendaciones muy importantes tener en cuenta cuando se utiliza la detección de característica:
- Pruebe siempre estándares primero porque a menudo, los exploradores admiten el estándar más reciente, así como la solución heredada.
- Siempre destino únicamente relacionada con las características de un único cheque, efectivamente minimizando las suposiciones de las capacidades del explorador.
Ahora veamos algunos ejemplos de detección de función.
El script siguiente crea dos rutas de acceso de código. Comprueba primero si el explorador admite window.addEventListener y si no, busca la disponibilidad del legado función window.attachEvent:
<script type="text/javascript">
if(window.addEventListener) {
// Browser supports "addEventListener"
window.addEventListener("load", myFunction, false);
} else if(window.attachEvent) {
// Browser supports "attachEvent"
window.attachEvent("onload", myFunction);
}
</script>
Otra buena consiste en encapsular la detección de función en un conjunto de funciones que puede utilizarse en todo el código. Aquí es una mejor práctica para detectar si el explorador admite el HTML5 <canvas> elemento y si es así, se asegura que el método canvas.getContext('2d') funciona así. Esta función simplemente devuelve true o false, lo que facilita la reutilización.
<script type="text/javascript">
functionisCanvasSupported()
{
var elem = document.createElement('canvas');
return!!(elem.getContext && elem.getContext('2d');
}
</script>
Hay que tener en cuenta cuando se utiliza la detección de función es siempre usar en recién creado elementos u objetos para evitar la posibilidad de que cualquier otra secuencia de comandos en la página ha modificado el elemento o el objeto desde que se creó, que podría conducir a resultados aleatorios o erráticos.
Detección de función también trabaja directamente para algunos elementos HTML, como, por ejemplo, HTML5 <video>, <audio> y <canvas> en el formulario de "reserva". El explorador muestra el primer subelemento compatible desde la parte superior y oculta visualmente los elementos siguientes.
La forma más sencilla tiene este aspecto:
<video src="video.mp4">
Your browser doesn't support videos natively.
</video>
Un explorador compatible con <video> elemento mostrará el vídeo "video.mp4" mientras que un explorador que no volverá al texto suministrado. Pero reserva también funciona para diversos formatos de vídeo en la etiqueta de vídeo:
<video>
<source src="video.mp4" type="video/mp4" />
<source src="video.webm" type="video/webm" />
Your browser doen't suppport videos natively.
</video>
En este caso, un explorador que admite HTML5 <video> primero intenta cargar el vídeo mp4. Si no admite este formato, recurrirá al vídeo codificado de WBEM. Debe ese formato no admitirse o el navegador no admitir <video> recurrirá al texto.
Por supuesto, tiene más sentido se retrocede a un Reproductor de vídeo Plug-in en lugar del texto, en caso de que el explorador no admite HTML5 <video> en absoluto. El siguiente ejemplo utiliza un Reproductor de vídeo de Silverlight:
<video>
<source src="video.mp4" type='video/mp4' />
<source src="video.webm" type='video/webm' />
<object type="application/x-silverlight-2">
<param name="source" value="http://url/player.xap">
<param name="initParams" value="m=http://url/video.mp4">
</object>
Download the video <a href="video.mp4">here</a>.
</video>
Una lógica similar funciona también en CSS. En CSS, simplemente se omiten las propiedades no reconocidas. Así que cuando desea agregar varias propiedades experimentales, el prefijo de proveedor, como se muestra con "border-radius" a continuación, simplemente puede incluir todas las variaciones en el código. Esto puede sentirse un poco imprecisa, pero es fácil de usar y el trabajo finalizado para casos como éste. Tenga en cuenta que es una práctica recomendada para poner los prefijos específicos del proveedor que desee incluir en primer lugar y el marcado estándar por última vez.
<style type="text/css">
.target
{
-moz-border-radius: 20px;
-webkit-border-radius: 20px;
border-radius: 20px;
}
</style>
Una boca grande para la detección de función es que también funciona con exploradores que aún no estaban pensando al crear la página y incluso con las futuras versiones de exploradores porque no depende de ninguna suposición sobre qué funciones admite un navegador.
Desarrollo y prueba de detección de función
El Herramientas de desarrollador de F12 en Internet Explorer 9 son excelentes para el desarrollo y pruebas de detección de función en muchos exploradores. Puede utilizar para depurar secuencias de comandos paso a paso y cambiar cadena user agent del navegador, así como para indicar a Internet Explorer para utilizar el motor de representación de las versiones anteriores**.**Figuras 5, 6, 7 y 8 muestran algunos ejemplos de cómo puede utilizar estas herramientas.
.png)
Figura 5 uso de puntos de interrupción durante la depuración de JavaScript en Internet Explorer 9
.png)
Figura 6 que se ejecutan en "modo de documento: agilizarán las normas," el bBrowser utiliza el método de addEventListener moderno
.png)
Figura 7 que se ejecutan en "modo de documento: estándares de IE7," el depurador cae Atrás para el método attachEvent de legado
.png)
Figura 8 se puede cambiar el agente de usuario de Internet Explorer sobre la marcha de la cadena e incluso agregar sus propias cadenas, los de exploradores móviles incluidos
Administración de detección de función en grandes proyectos
Al crear un proyecto Web complejo, crear y administrar todo el código de detección de función pueden ser tediosos. Por suerte, existen grandes bibliotecas de JavaScript disponibles que ayudan en este esfuerzo, es decir Modernizr y jQuery.
Modernizr tiene incorporado de detección para la mayoría de las características de HTML5 y CSS3 que es muy fácil de usar en el código. Ha adoptado ampliamente y constantemente mejorada. Modernizr y jQuery se envían con ASP.Herramientas de NET MVC.
Examine el código en figura 9, que detecta la capacidad del explorador para mostrar las fuentes de web sin utilizar Modernizr y, a continuación, el código de figura 10 que utilizan Modernizr.
Figura 9 sin Modernizr
function(){
var
sheet, bool,
head = docHead || docElement,
style = document.createElement("style"),
impl = document.implementation || { hasFeature: function()
{ return false; } };
style.type = 'text/css';
head.insertBefore(style, head.firstChild);
sheet = style.sheet || style.styleSheet;
var supportAtRule = impl.hasFeature('CSS2', '') ?
function(rule) {
if (!(sheet && rule)) return false;
var result = false;
try {
sheet.insertRule(rule, 0);
result = (/src/i).test(sheet.cssRules[0].cssText);
sheet.deleteRule(sheet.cssRules.length - 1);
} catch(e) { }
return result;
} :
function(rule) {
if (!(sheet && rule)) return false;
sheet.cssText = rule;
return sheet.cssText.length !== 0 &&
(/src/i).test(sheet.cssText) &&
sheet.cssText
.replace(/\r+|\n+/g, '')
.indexOf(rule.split(' ')[0]) === 0;
};
bool = supportAtRule('@font-face { font-family: "font";
src: url(data:,); }');
head.removeChild(style);
return bool;
};
Figura 10 con Modernizr
<script type="text/javascript" src"modernizr.custom.89997.js"></script>
<script type="text/javascript">
if(Modernizr.fontface){
// font-face is supported
}
</script>
Agregar compatibilidad para características ocultas
Detección de función no elimina la carga de contar con una solución cuando el navegador probado no admite una característica que necesita. En el ejemplo anterior vídeo de HTML5, utilizando Silverlight como reserva fue una solución obvia. Pero ¿qué ocurre con otras características de HTML5, como <canvas> o la nuevas semánticas etiquetas, como <nav>, <section> y <article>, <aside>, o el nuevo <header> ¿y <footer>?
Un número creciente de listos para usar "reserva" numerosas funciones de HTML5, conocido como correcciones y polyfills, puede facilitar esa carga. Estas vienen en forma de bibliotecas CSS y JavaScript o a veces incluso como Flash o Silverlight controles puede utilizar en el proyecto, agregar características de HTML5 falta para exploradores que de lo contrario no admiten.
La idea general es que los desarrolladores podrán desarrollar con las API de HTML5, y pueden crear secuencias de comandos de los métodos y objetos que deben existir. Desarrollo de esta forma de futuro significa que, como los usuarios actualizar, el código no tenga que cambiar y usuarios se moverá a la mejor experiencia nativa limpiamente.
La diferencia entre correcciones y polyfills es que correcciones sólo imitan una función y cada uno tiene su propia API propietaria, mientras que polyfills emular la propia característica HTML5 y su API exacta. Por lo tanto, en términos generales, utilizando un polyfill le ahorra la molestia de tener que adoptar una API propietaria.
El Polyfills del explorador de cruz de HTML5 colección en github contiene una lista creciente de correcciones disponibles y polyfills.
Modernizr, por ejemplo, incluye el "HTML5Shim" para la compatibilidad con etiquetas semántica, pero es fácil cargar otras correcciones y polyfills si Modernizr detecta que una función no es compatible.
Agregar compatibilidad con dinámicamente
Usted puede preguntarse, "No agregar todas las bibliotecas de secuencia de comandos que mi página muy grande y tarda en cargarse?"
Bueno, es cierto que en muchas de estas bibliotecas auxiliares puede agregar una carga notable al sitio Web, así que tiene sentido para cargar dinámicamente sólo cuando realmente se necesiten. En el caso de una corrección o polyfill, se recomienda cargar sólo cuando se ha detectado que el explorador no admite la función nativa de HTML5.
Nuevamente estamos de suerte porque hay una gran biblioteca que admite exactamente este escenario: yepnope.js
Yepnope es un cargador de recursos asincrónica que funciona con JavaScript y CSS y totalmente desacopla precarga de ejecución. Esto significa que tiene control total de cuando se ejecuta el recurso y puede cambiar el orden en el acto. Yepnope se integrará en Modernizr (2), pero también puede utilizarse por sí mismo. Vamos a echar un vistazo a su sintaxis:
<script type="text/javascript" src="yepnope.1.0.2-min.js"></script>
<script type="text/javascript">
yepnope({
test : Modernizr.geolocation,
yep : 'normal.js',
nope : ['polyfill.js', 'wrapper.js']
});
</script>
Este ejemplo desde la página de Yepnope prueba la capacidad del explorador para utilizar geolocalización de HTML5 mediante Modernizr.Si lo admite, se cargará su propio código (normal.js); de lo contrario, se cargará un polyfill personalizado (que consta de polyfill.js y wrapper.js).
Los puntos más importantes se resumen en figura 11.
Figura 11 Detección de explorador y Dos de detección de función y qué no hacer
| DO | NO | |
| Detección de explorador | Intente evitar por completo. o Prueba para un explorador específico y versión. |
Hacer suposiciones para futuros exploradores comprobando únicamente el nombre del explorador. |
| Detección de función | Probar en primer lugar para los estándares. | Asumir funciones no relacionadas en una prueba. |
Recursos:
Más información sobre el navegador y la función de detección en:
- Demostración de Internet Explorer
- HTML5 Labs
- Artículos MSDN:
- Bibliotecas de JavaScript:
- Polyfills / pule:
P. Sascha Corti funciona para Suiza de Microsoft como Evangelista developer centrándose en las herramientas de plataforma y desarrolladores de sistema de Microsoft, y presenta las últimas tendencias a la Comunidad de desarrolladores Suiza.Actualmente se dedica a las tecnologías Web y la plataforma de 7 de Windows Phone.
Sus estudios implicados informática en ETH Zurich y administración de la información de la Universidad de Zurich.
Durante siete años Sascha fue un desarrollador de software y el arquitecto para un importante banco suizo y ha trabajado como un especialista en sistemas de ingeniería y tecnología para varias compañías de alta tecnología estadounidenses, incluyendo Silicon Graphics y Microsoft.
Puede leer acerca de sus actividades más recientes sobre su weblogs en http://techpreacher.corti.com y https://blogs.msdn.com/swiss_dpe_team/ o seguirlo en Twitter @ TechPreacher.
Gracias a los siguientes expertos técnicos para la revisión de este artículo: Justin Garret yThomas Lewis