google-chrome - play - mejor bloqueador de publicidad chrome
¿Las pequeñas empresas deben codificar sus sitios para ser compatibles con Chrome? (18)
Como usuario final, me molesta un poco si algún sitio no admite Chrome: básicamente, empiezo a ignorarlo, pero no antes de escribir una queja primero. Dicho esto, a veces es culpa de Chrome, no de los diseñadores. Sin embargo, realmente no me importa de quién es la culpa, ya que todo lo que quiero es que la página se reproduzca correctamente y funcione como se espera.
Trabajo en sitios pequeños para salones de bronceado y esas cosas. No admitimos material específico de ActiveX en IE, y admitimos Firefox. He notado un comportamiento extraño con Chrome. Las estadísticas de mi navegador dicen que <1% de mis visitantes usan Chrome.
Escuché a la gente decir que no está ni cerca de ser el mejor en su clase. Pero me gusta la forma en que todo se ejecuta en su propio proceso y esas cosas.
¿Chrome va a ser lo suficientemente popular como para tener que codificarlo? Cuando se haga popular, ¿se arreglará su extraña representación?
Conozco a varias compañías grandes que han prohibido el uso de Chrome hasta que permita la instalación en otro disco que no sea el C. Supongo que si Chrome supera esto y algunos de los problemas de UI mencionados en otra parte, se volverá muy popular. Creo que deberías planear apoyar a Chrome.
La clave es escribir en estándares, utilizando marcas semánticamente correctas y bien formadas. Haga que la implementación base funcione para la mayoría de los navegadores (tantos como sea posible) y realice ajustes para manejar los restantes.
Escribir sitios que están diseñados para ser "vistos mejor" con un navegador determinado perpetúan la incapacidad del vendedor de buscar el cumplimiento de los estándares.
Probablemente aún no: Chrome todavía está cambiando bastante rápido, y apuntan a cumplir totalmente con los diversos estándares y pruebas. Si intentas seguir Chrome ahora mismo, probablemente estarás rastreando muchos pequeños cambios que eventualmente querrás revertir.
Si está trabajando con Javascript y esto está dando lugar a diferencias notables entre navegadores, entonces definitivamente recomendaría utilizar un marco de terceros como jQuery para que pueda trabajar con una interfaz común de navegador independiente. Sin embargo, si sus diferencias se deben a HTML / CSS en sus páginas, siempre daré prioridad a los navegadores más populares de acuerdo con las estadísticas de su sitio. Si <1% usa Chrome, consideraría seriamente dedicar el tiempo a otras tareas en lugar de investigar algo que en realidad podría ser un problema con un nuevo navegador que aún se encuentra en una fase beta muy temprana.
Yo probaría las páginas con Chrome. Si has hecho un buen trabajo, no debería haber tantos problemas.
En realidad, ES posible escribir un código que funcione en todos los navegadores (bueno, tal vez no IE 6 o anterior);)
es una buena razón para mejorar la compatibilidad con los navegadores WebKit en general (¿no tienes clientes usando Safari en una Mac?)
Incluso si Chrome está fuera de beta, para mí todavía está en versión beta. Debido a que Chrome no puede mostrar bien png24 con cambio de opacidad (intenté hacer un fadeIn / fadeOut con jquery en una imagen png y recibí un ANNOYING blanco flash antes de la animación de la imagen; aquí puede ver el problema)
Chrome todavía está en la versión beta inicial y su renderizado no está exento de errores, también tengo problemas críticos con la interfaz de usuario en Chrome. Planeo que mis aplicaciones web funcionen en Chrome, pero tomé la decisión de no cambiar nada hasta que Chrome llegue a un nivel más maduro.
Google dijo recientemente que llevarán Chrome a un estado no beta muy pronto (a diferencia de su historial anterior de dejar las cosas en beta durante 5 años más o menos).
Además, si planea usar Chrome para webdev en este estado beta, querrá instalar el "Canal de desarrollador" que le da acceso a versiones más nuevas que la versión pública, muy importante en esta etapa del navegador. A partir del 12/10/2008, la versión dev de Chrome es 0.4.154.33
Chrome usa WebKit, un motor de renderizado bastante estándar. Safari también lo usa y no parece que WebKit se vaya. Si tiene los recursos necesarios, le aconsejaría que lo solucione.
Debe dirigirse a navegadores según lo que estén usando sus clientes . Si el 80% de sus clientes utilizan IE, entonces sería prudente probar su sitio principalmente en IE. Si sabe que sus clientes están utilizando FF, sería prudente probar su sitio principalmente en FF.
Dicho esto, la cuota de mercado de Google Chrome es básicamente un error de redondeo, por lo que no, no me molestaría. A menos que, por supuesto, sepa de antemano que una gran cantidad de sus usuarios lo están usando.
(por ejemplo, para una aplicación de iPhone que escribí, descubrimos que la mayoría de nuestros usuarios navegaban a nuestro sitio desde un iPhone). Sé que es un concepto totalmente asombroso. Por eso, comenzamos a realizar la mayoría de nuestras pruebas en el sitio web. el buscador de iphone)
Jimmy tiene un muy buen punto allí, Chrome y Safari están basados en WebKit. Si falla en Chrome, hay buenas posibilidades de que se rompa en Safari, el navegador Nokia S60 y el resto también.
No creo que debas codificar nada específico para Chrome. Si dicen que los estándares web son importantes para ellos, Chrome eventualmente seguirá esos estándares a la perfección.
Tampoco creo que Chrome sea muy popular. Cuando lo vi, lo primero que pensé fue "Guau ... Mozilla con una G impresa". Y no he estado muy impresionado desde entonces.
En pocas palabras: debe intentar que su sitio sea compatible con los principales navegadores. Opera, IE, Firefox. Por lo general, cumplir con los estándares web y las mejores prácticas lo logrará. Otras veces necesita crear soluciones alternativas o forzar a los navegadores a actuar de una determinada manera. IE Firefox e IE usan un modelo de borde diferente. Puede obligar al menos a FF a utilizar el mismo modelo de borde que IE.
Nunca código para admitir productos beta. Espere a que terminen de hacer su software antes de comenzar a cambiar el suyo para que lo soporte.
Primero escriba el código en los estándares, luego, para los diferentes motores de renderizado si es necesario. Nunca diseñes sitios web para navegadores específicos, es una pendiente muy resbaladiza.
Tanto las empresas web más grandes como las pequeñas empresas web con las que personalmente trabajo no hacen nada con Chrome. No está en su radar de navegador. Y algunos de los más grandes son grandes ecommerce.
Por lo tanto, no dedico tiempo de codificación para soportar Chrome. Lo ejecuto con fines de investigación y desarrollo de mercado.
En primer lugar, apunte al estándar actual, luego priorice según el alboroto que hagan sus usuarios (si tiene un 1% muy vocal sigue siendo un 1% muy vocal de su base de usuarios)
En mi opinión, todo depende de tus clientes y sus usuarios. Verificaría tus weblogs y vería si es un porcentaje significativo.
Si se está volviendo significativo, hasta el punto en que sus clientes podrían estar perdiendo dinero, lo discutiría con ellos y vería si están dispuestos a pagar más para alinear sus sitios con Chrome.
Personalmente, no me preocuparía hasta que llegue al menos al 1% de manera consistente. Y aún así, todavía hablaría con tus clientes sobre eso primero.
Por otro lado, es bastante posible que obtenga un 5% de cuota de mercado en el próximo año más o menos. Es Google después de todo.