Posts Tagged ‘html’

HTML5: Pasen y vean

Friday, April 23rd, 2010

Llevo más de 1 año sin escribir. Realmente llevaba un año preparando un sesudo artículo sobre el HTML5 y cómo cambiaran nuestras vidas XD. Pero todo tirado por la borda tras ver esto:

consejo: usar un navegador que entienda algo de HTML5, preferentemente Safari o Chrome

Presentación interactiva del HTML5

Botón reset en formularios

Friday, September 4th, 2009

Hay cosas que uno lleva años pensando y luego llega alguien y lo sintetiza en dos líneas

There was a time when many, many, forms on the web had a reset button. Thankfully, reset buttons are not quite as common these days, but there are enough of them out there to cause users lots of frustration.

Mira que tiene que estar mál diseñado un formulario para que haga falta un botón que borre todo lo que has rellenado!

Maquetando sin tablas, pero como con tablas: display inline block

Monday, October 27th, 2008

Aviso: lo que se explica en el siguiente artículo forma parte de lo que denomino “la maquetación web del futuro“, es decir, cosas que podremos hacer dentro de un tiempo pero que, dado el uso que aún tienen algunos navegadores antigüos, hoy por hoy no es recomedandable utilizar

Actualización!: Anieto2k publica un hack que permitiría utilizar esta técnica en todos los navegadores. 

Esta semana he leído dos artículos (artículo 1, artículo 2) donde unidos a la palabra maquetación se usan términos como “Table”, “Cell” o “Row”. ¿Qué pasa? ¿Se ha vuelto a poner de moda la maquetación basada en tablas? Evidentemente no, esto no tiene vuelta atrás aunque todavía haya demasiados sitios webs table based.

La idea central de estos artículos es la posibilidad de poder aplicar a elementos que no son tablas propiedades de éstas. Esto se hace mediante los valores “table”, “table-cell” y “table-row” de la propiedad display. Se vuelve a hablar de esto ahora que Internet Explorer 8 admite y funciona con estos valores, aunque no lo hace de forma totalmente correcta (hablamos de la beta 2).

En la práctica lo que esto supone es que podemos hacer un elemento HMTL como, por ejemplo, un DIV, tenga el comportamiento de una tabla. Es decir, sin hacer atentados semánticos podemos aprovechar las propiedades de la maquetación con tablas. Un claro caso de uso es poder hacer algo que trae de cabeza a cualquier maquetador CSS: que un conjunto de elementos flotantes tengan una altura común. Dos imágenes valen más que 2.000 palabras

Caso 1: (ver html)

Caso 2: (ver html no en Internet Explorer < 8)

Para el segundo caso lo que hemos hecho es usar en los siguientes valores de la propiedad display:

  • display: table->le dice al elemento que se comporte como una tabla.
  • display: table-row-> le dice al elemento que se comporte como una fila de una tabla
  • display: table-cell->  le dice al elemento que se comporte como una celda de una tabla

Ojo, por si no has leido atentamente: esta técnica se podrá usar cuando la gente

Más sobre este tema:

Impedir traducciones de Google en nuestras webs

Wednesday, October 15th, 2008

Google permite desde ahora que podamos decidir si nuestra web o una parte de ella no debe ser traducida. Me parece una decisión estupenda ya que, en ocasiones, hay partes de nuestro contenido que no tiene sentido traducir a otros idiomas al tratarse de giros o expresiones realmente intraducibles.

Si queremos que nuestra página no pueda ser traducida por Google Translator lo haremos a través de una etiqueta META:

HTML:
  1. meta name="google" value="notranslate"

Si no queremos que un texto concreto no sea traducido usaremos un "class='notranslate' ":

HTML:
  1. si yo digo que<span class="notranslate">esto es la leche</span> mejor no lo traduzcas... puede confundir

Yo sigo maquetando con Dreamweaver ¿Y tú?

Saturday, September 27th, 2008

Aprovechando la inminente salida de la nueva generación de aplicaciones de Adobe quiero tocar este tema que siempre suscita cierta controversia cuando hablamos entre desarrolladores web.

No escribo este post para defender a Dreamweaver como la mejor herramienta para maquetar. Ni siquiera sé si lo és, ni me importa demasiado. Lo que es evidente es que desde que comencé en esto de la maquetación trabajo con él (tras un efímero comienzo con Adobe Golive) y que he ido probando otras herramientas a lo largo de estos años pero al final siempre vuelvo a los brazos de Dreamweaver.

Y aclaro también que mi defensa es como herramienta para maquetación, no para programación. Posiblemente un programador PHP se encuentre mucho más cómodo en un sistema que le permite explorar sus clases, debuguear su código dentro de lo posible y que le ayude un poco más a la hora de programar... desde luego para ese tipo de trabajo Aptana parece una alternativa más seria.

Personalmente uso Dreamweaver para el desarrollo de las maquetas desde 0. En ese momento en que me pasan el diseño y tengo que convertirlo a código abro dreamweaver y me pongo a trabajar. Una vez que he maquetado mis plantillas dejo de usarlo.

A partir de ese momento, para debuguear, corregir o hacer cambios que me propongan los designers... uso otras herramientas: concretamente la combinación Transmit + Bbedit + Firefox / firebug es mi opción básica en Mac y trabajando en Windows Filezilla con Notepad++; por supuesto siempre está la opción básica y salvavidas de trabajar directamente en el servidor con Vi.

¿Por qué me encuentro cómodo maquetando con Dreamweaver?

Su maravillosa integración con el gestor de FTP: el gestor en sí no es de lo mejor y es frecuente que se atasque... pero a mi me gustra trabajar en local, guardar y subir al servidor. Una vez configurado el sitio remoto la combinación de teclas Cmd + Mayus + U (o Ctrl en windows) me resulta bestialmente cómoda... y el hecho de que me avise de que "hay una versión más reciente en el servidor" del archivo que estoy editando me da una gran seguridad.

La vista mixta diseño / código me resulta esencial. Eso de poder seleccionar un elemento en la vista diseño y que me lo marque en código me ayuda muchísimo. La vista diseño integrada es algo que no he visto en ningún otro editor; normalmente el resto se limitan a incorporar un navegador para previsualizar, pero no se puede interactuar con él.

El editor de código, que no es el mejor, pero  es muy aceptable tanto para HTML como para CSS gracias. Con el sistema de sugerencias para atributos y propiedades y el cierre automático de etiquetas me basta. Aunque echo muchísimo de menos, y me revienta, su incapacidad para detectar  dónde se cierra una etiqueta, llave o paréntesis al seleccionarla. Eso casi me hace pasarme a Aptana.

Son 3 tonterías, lo sé, pero a mi me hacen mi trabajo mucho más facil. Dreamweaver tiene mil funcionalidades más que no uso para nada pero esos detalles unidos a un interfaz de usuario en general muy muy cómoda en casi todos sus aspectos hacen que me sienta bien trabajando con él.

Finalizando

Este post no es para recomendar Dreamweaver a los maquetadores, sobre todo porque hay alternativas gratuitas que son muy buenas; para mi la mejor posibilidad, con diferencia, es Aptana. Es simplemente la exposición de un hecho que estoy seguro que muchos maquetadores comparten.

Un disclaimer: vaya a pensarse alguién que tengo que ver algo con Adobe, ojalá, pero no; tampoco patrocinan este post ;)

PD: a lo mejor algún día hablo de porqué uso Fireworks y no Photoshop :)

PD2: verás como aparece por aquí la clásica y estéril discusión "Yo programo con notepad"... Dreamweaver es para débiles y lamers.

Algunas agencias y ciertas webs:

Wednesday, September 24th, 2008

No me gusta escribir posts en caliente y cabreado... así que no sé si publicaré esto al final; lógicamente si lo estás leyendo es que he roto la norma y he publicado.

Estoy realmente cansado de trabajar haciendo webs para agencias de comunicación, publicitarias, branding masters o como demonios se quieran llamar.

En general se trata de empresas de cuya calidad no dudo a la hora de hacer campañas de publicidad, cartelones impresionantes, identidades gráficas de la ostia, folletos que venden solos, etc. Saben muchísimo marca, de comunicación de emoción... para determinados productos web son la elección correcta. Un caso clarísimo: el pueblo en el que nunca pasa nada.

De lo que yo estoy cansado es de que me lleguen trabajos pensados en Flash pero en los que esta tecnología es innecesaria o simplemente no se puede utilizar.

El caso típico: me llega un diseño cuya estructura y funcionalidad pueden ser desarrollado perfectamente en HTML pero con detalles tipográficos o efectos sutiles (casi siempre innecesarios) que obligan a utilizar Flash.

Te encuentras con una web de estructura clásica: cabecera, contenido a dos columnas y pié; menú en el lateral corriente y un desarrollo de las secciones en la otra columna cuyo contenido es texto e imagen... pero está diseñado para una altura fija, cuando seleccionas una sección encuentras un maravilloso y único efecto fade-out para que desaparezca el contenido actual y aparezca el nuevo; la tipografía es una helvética neue o similar...

Y yo siempre me pregunto... ¿para esto hay que hacer esa web en flash? ¿Ganamos algo? Porque perder sí que se pierde:

  • Indexación
  • posicionamiento en buscadores
  • Facilidad para gestionar los contenidos
  • Posibilidad de tener estadísticas de uso de la web aceptables
  • Posibilidad de medir incidencia de campañasa para secciones concretas
  • etc., etc., etc.,

¿Cual es el problema?

Que encargan ese tipo de webs a agencias que no tienen desarrolladores webs: programadores, maquetadores, etc.. tienen un plantel de diseñadores profesionales, que se mueven muy cómodamente diseñando en flash y que utilizan esa tecnología hasta para poner un 404.

¿Solución?

Si se van a meter en proyectos web deberían contar en su equipo con algún diseñador - maquetador con conocimientos de HTML que sepa orientar ese desarrollo. Es conveniente además que los diseñadores se pongan al día de las posibilidades que ofrecen los frameworks de javascript (Jquery, prototype - scriptaculous, Dojo y demás) que són muchas y cubren la mayoría de los efectos simples para los que utilizan Flash.

Otra opción es no coger ese tipo de trabajos si no tienes los profesionales correspondientes. Si a mi me vienen pidiendo una campaña de comunicación les remito a la empresa correspondiente, procuro no meterme. Pero no es infrecuente que se les encargue una campaña de comunicación en papel o TV y que la agencia de paso diga: "oiga... y si me contrata le regalo la web". Al final me llega a mi la web regalada para que la dinamice, le ponga un cms, y les pase estadísticas de usuarios que han utilizado el formulario de contacto.

PD: para que hablo... acaba de llegarme un caso de estos-> acción de márketing -> campaña en medios -> microsite en flash