2010-06-03 16 views
35

Sé que en el momento de escribir estas líneas solamente Opera soporta una interfaz de usuario del navegador para¿Hay una manera de localizar input type = "fecha" en HTML5

<input type="date" name="mydate"> 

y tal vez mis intentos para localizar este campo han sido Me encontré con la frustración porque las sutilezas como la localización aún no se han incluido en su implementación, pero ni siquiera lo veo en las especificaciones de HTML5. ¿Hay alguna manera de especificar la localización? ¿Debo hacer lang = "fr" en un elemento padre?

Algunas notas sobre la aplicación del sitio en cuestión:

  • localización (idioma) es recogido explícitamente por el usuario, ya que son la gestión de datos en varios idiomas y no es razonable esperar que el navegador del usuario Chrome está en el idioma que se está viendo o que el navegador proporciona los encabezados de solicitud de idioma deseados.
  • Quiero estar seguro de que si la página se representa en francés, el selector de fechas proporcionado por el navegador Chrome muestra las opciones que tienen sentido para el idioma francés.
  • El plan es volver a caer a jQueryUI para los navegadores que no soportan type = "fecha", voy a utilizar el mecanismo de detección proporcionada en Dive into HTML 5

Respuesta

13

Por lo que sé, la idea detrás de lo que hacemos en Opera (descripción completa: yo trabajo para ellos) es que el selector de fecha es casi una extensión de Chrome, un control nativo del navegador. Como tal, se localizará de acuerdo con el idioma del navegador, en lugar del idioma de la página que se está viendo.

+4

3 problemas con que: 1. Se discordante como un usuario tenga que cambiar de idioma (cromo vs contenido) para un selector de fecha. 2. Los datos se mostrarán en la página en una localidad, ¿el chrome (en el modo inglés) entenderá el francés y el hecho de que Juin significa junio? 3. El lado del servidor esperará datos formateados en una configuración regional y analizará en consecuencia, si el selector de fecha formatea la fecha de la configuración regional esperada, el servidor la malinterpretará. Estos problemas no están limitados a las fechas. ¿Qué hay de los números? El francés usa una coma en lugar de un decimal. ¿Cómo manejará el cromo eso? El enfoque parece miope. – lambacck

+5

1 actúa como, por ejemplo, la entrada de tipo de archivo en todos los navegadores ... que también se localiza según la configuración regional del navegador, no la página. Puedo ver argumentos a favor y en contra de esto. 2 No entiendo exactamente lo que quiere decir aquí: suponiendo que esto se relaciona con 3 independientemente de cómo se muestre la interfaz de usuario para el selector de fecha, el resultado final (que luego se pasa al servidor) siempre está en el mismo formato ISO, independientemente de el lenguaje que muestra la UI. No intenté lo de los números (suponiendo que te refieres a input type = "number") ... pero aquí puedo ver que de hecho tendría problemas potenciales. no sé si eso está localizado actualmente, aunque. –

+0

No creo que el formato ISO sea una respuesta razonable para la mejora progresiva. Si el navegador vuelve a caer en un cuadro de entrada simple y no tienen Javascript habilitado (sí, esas personas existen), entonces tendrán que ingresar la fecha en formato ISO. Si el usuario no es técnico, es poco probable que quiera ingresar la fecha en formato ISO (incluso saber cómo). – lambacck

11

Estoy de acuerdo con lambacck. Actualmente estoy escribiendo un código Javascript para hacer que las nuevas funciones de formulario estén disponibles en el navegador, usando la interfaz de usuario de jQuery para esto.

Trabajo en Luxemburgo, que es un buen lugar para ilustrar el problema de localización con más detalle.

La mayoría de los sitios web que escribimos son multilingües de | fr | en. Según nuestras estadísticas, podemos decir que las personas usan el interruptor de idioma en el sitio para mostrar su idioma preferido, pero esta opción rara vez coincide con la configuración regional preferida del navegador.

Si el entorno local del campo de calendario, etc. se realiza por el sistema operativo, esto nos lleva de nuevo a la desafortunada < entrada   type = archivo > situación en la que la etiqueta se lee Subir un archivo y el botón dice Parcourir. No puede hacer nada con respecto a esta combinación de idiomas y siempre me pareció una gran molestia.

Conclusión, tengo que sobrescribir el calendario predeterminado con jQuery uno para asegurarme de que hace lo que quiero.

En mi opinión, una API configurable o al menos una forma de manipular la configuración regional en un nivel de HTML sería genial. Dado que los nuevos tipos de campo aún no han sido ampliamente adoptados por los otros fabricantes de navegadores, imagino que este problema aún podría tenerse en cuenta.

Gracias por leer esto.

+0

"donde dice la etiqueta Cargar un archivo y el botón dice Parcourir": Eso solo significa que su aplicación no respeta el idioma del navegador de los usuarios ... – feeela

+6

@feeela: ¿Qué pasa si su sitio web tiene un selector de idioma para permitir que el usuario anule el idioma predeterminado (proporcionado por el navegador) ... – fretje

3

Para dispositivos móviles, la mejor solución que hemos encontrado es usar una entrada de texto para ingresar la fecha, con un icono de calendario al lado que tiene una entrada de fecha invisible sobre el ícono.

Ventajas:

  • funciona en todos los navegadores y dispositivos
  • puede usar el botón junto a la fecha en iOS (si varios campos)
  • usuario puede escribir en la fecha (muy útil)
  • evita Errores de IU de iOS (1. edición de datos existentes con fecha en blanco, siguiente fecha, valor de fecha establecido hoy - arrrgh, 2. teclado mostrando, siguiente fecha, muestra emergente y el teclado desaparece - ouch)
  • usa una biblioteca de fechas para mostrar la fecha en la entrada como la localización configurada para la cuenta de usuario (no el navegador), y puede usar una biblioteca de fecha inteligente (escriba "mañana", etc.).
  • icono de calendario clic para ver la fecha como la localización del navegador
  • repliegue grácil incluso si input type=date no compatible con el dispositivo/navegador (por ejemplo, algunos dispositivos Android no son compatibles con fecha o tener errores graves).
  • para escritorio (detectado mediante soporte técnico sin contacto) mostramos nuestro propio menú desplegable de fecha personalizada.

HTML es un algo como:

<input type=text> 
<span style=position:relative> 
    <input type=date class=date-input tabIndex=-1> 
    <div class=date-input-icon>&#x25BC;</div> 
</span> 

CSS:

.date-input { 
    position: relative; 
    z-index: 1; 
    webkit-appearance: none; 
    display: inline-block; 
    opacity: 0; 
    width: 1em; 
} 

.date-input-icon { 
    position: absolute; 
    right: 0; 
    width: 1em; 
} 
+1

La pregunta es acerca de la localización y no otros problemas relacionados con el uso del tipo nativo = widgets de fecha. No se menciona la localización en la respuesta. – lambacck

+0

No importa, veo la parte de localización que es usar javascript (que es lo que ya es la solución aceptada). – lambacck

+0

¿Cuál es la ventaja de tener una entrada de fecha oculta en lugar de simplemente usar type = text cuando el botón proporciona la interfaz de usuario de selección? – lambacck

Cuestiones relacionadas