Framework CSS/XHTML para iPhone

Cuando apenas faltan unos días para la esperada llegada del iPhone 3G, Diego Martín Lafuente ha anunciado en su blog un framework XHTML/CSS para el iPhone, para que sea aprovechado de modo libre a la hora de construir la interfaz de cualquier aplicación que se desarrolle para el iPhone. Se puede ver aquí.

Soporte de CSS en el e-mail

CSS y e-mail

Alguna vez me he referido a las dificultades que presenta el diferente soporte de HTML/CSS por parte de las diferentes aplicaciones de e-mail (tanto standalone como basadas en web) y a la ausencia de un estándar. Por ello va muy bien contar con recursos como la impagable y valiosísima tabla de compatibilidades entre propiedades de CSS y gestores de correo de Campaign Monitor, que ha sido recientemente actualizada. Un recurso fundamental para todos los que realizan e-mailings dentro de sus campañas de marketing online.

Soporte de CSS en Internet Explorer 7

Markus Mielke escribe en su blog las mejoras de CSS que saldrán en Internet Explorer 7:

Details on our CSS changes for IE7
We are currently locking down IE7 for shipping and I wanted to give an update on the CSS work that went into IE7. Chris originally outlined our plans for IE7, and we listened to a lot of feedback (blog, connect database, conferences, our WASP partnership etc.) to help us address the most grievous bugs and prioritize which features to put in for IE7. I like to thank especially the contributors on this blog for their participation. Your feedback made a difference in deciding what issues to address.

We understand that we are far from being done and we know we have still a lot of work ahead of us. IE 7 is a stepping stone in our effort to improve our standards compliance (especially around CSS). As an example, in the platform we did not focus on any proprietary properties – though we may try out new features in the future using the official –ms- prefix, following the CSS extension mechanism. We also work very closely with the W3C CSS working group (which I am a member of) to help clarify assumptions in our implementation and drive clarifications into the spec. I really like to thank everyone who helped us here.

In all, we made over 200 behavior changes (bug fixes or new features) under strict mode to improve CSS2.1 compliance. All this work (with the exception of transparent PNGs) has been done under the < !DOCTYPE> switch only, since all changes required behavioral updates to be more in line what the CSS spec specifies. To preserve application compatibility we will not make any behavioral changes to “quirks mode” as it has been established since IE6.

Here is the list of CSS features and changes for IE7:

Bugs we fixed

All bugs on positioniseverything.net except the “escaping floats” bug (which is planned for the future)
Peekaboo Bug
Internet Explorer and Expanding Box Problem
Quirky Percentages
Line-height bug
Border Chaos
Disappearing List-Background bug
Guillotine Bug
Unscrollable Content bug
Duplicate Characters Bug
IE and Italics
Doubled Float-Margin bug
Duplicate Indent bug
Three pixel text jog
Creeping Text bug
Missing First letter bug
Phantom box bug
Details on some of the other bugs (from sources other than the positioniseverything.net list) that we fixed:

Overflow now works correctly! (That means boxes do not automatically grow any more.)
Parser bugs: * html, _property and /**/ comment bug
Select control: CSS style-able and not always on top
Auto-sizing of absolute positioned element with width:auto and right & left (great for 3 column layouts)
Addressed many relative positioning issues
Addressed many absolute positioned issues
% calculations for height/width for abs positioned elements http://channel9.msdn.com/ShowPost.aspx?PostID=191182
< ?xml> prolog no longer causes quirks mode
HTML element truly independent of the Body (now gets its own width, height etc.)
1 px dotted borders no longer render as dashed
Bottom margin bug on hover does not collapse margins
Several negative margin issues fixed
Recalc issues including relative positioning and/or negative margins are fixed now
CLSID attribute of tag no longer limited to 128 characters
:first-letter whitespace bug described in http://blogs.msdn.com/ie/archive/2005/09/02/460115.aspx fixed
Descendant selector now works properly for grand children when combined with other selectors
First-line and first-letter now applies when there is no space between word :first-line and opening brace {
Pseudo-classes now are working as expected if selector is excluded
The :link selector works now for anchor tag with href set to bookmark
Addressed !important issues
PositionIsEverything piefecta-rigid.htm now works
List-item whitespace bug fixed
Fixed Absolutely Buggy II
Absolute positioned elements now use always correct containing block for positioning and size information
Nested block elements now respect all overflow declarations (hidden, scroll, etc)
Fixed the opposing offset problem (absolute positioned element whit all four top, bottom left and right are present)
tags nested within LI elements will no longer add extra bottom margin when hover occurs
We no longer lose the image aspect ratio on refresh
Cleaned up our ident parsing according to CSS2.1 rules
Fixed parsing bugs for multi- class selectors and class selectors that are combined with id selectors
And many more
We also extended our existing implementations to comply with W3C specifications:

Enable :hover on all elements not just on
Background-attachment: fixed works on all elements – so Eric Meyer’s complexspiral demo works
Improved fallback

Finally, we added new features from CSS2.1:

Min/max width/height support (also for images, which did not work in IE7b2)
Transparent borders
Fixed positioning support
Selectors: first-child, adjacent, attribute, child
A couple of CSS 3 attribute selectors: prefix, suffix and substring since we were working already in the code base (also the general sibling selector)
Alpha channel PNG support (Not a CSS feature but too important for designers to not call it out J)
Better Standards Support…
But as we’ve been continually reminded, better standards support in IE also means some pages break. As we struggle to balance the needs of our user customers with the desires of web developers, we need your help. The only way for us to continue to improve our standards support is to get your help in changing your sites for IE7. We have provided a set of documentation and tools to help you transition your pages to IE7:

The IE 7 Readiness Toolkit pulls together documentation, tools, and guidance for developers, testers, and ITPros to prepare sites, extensions and applications for IE 7.
The Cascading Style Sheet Compatibility in Internet Explorer 7 – documentation on common breaking patterns and techniques you can do to avoid them.
Developer and ITPro Checklists
The IE Developer Center is the clearinghouse for all (past and present) IE developer information.
We have an Application Compatibility Toolkit that logs and identifies changes in behavior due to changes in IE 7 and Vista.
All of this is wrapped up for you in the Information Index for IE 7.
Finally, as we’ve talked about before, we have a Web Developer Toolbar, which is a great aid during the development and debugging of a website.

We are already planning for the next IE release and will continue down the road of improving our CSS support.

Una traducción: CSS cross-browsing

Una traducción: CSS cross-browsing

Copiado de www.virtualityinblack.com

Una traducción: CSS cross-browsing

Una aclaración primero:

Este artículo lo encontré publicado en Friendly bit. Su autor, Emil Stenström, me ha autorizado a traducirlo al español. En mi opinión es tremendo que la comunidad de desarrolladores web de habla hispana se pierda materiales de esta calidad sólo porque la barrera del idioma nos lo impida. Este es mi granito de arena pues para que esa barrera sea, cada vez, más pequeña.

———————————————————-

En este artículo hablaré sobre un par de técnicas que uso para conseguir que mis sitios web se vean iguales en distintos browsers. Es relativamente simple armar distintas versiones de tus sitios para cada browser. Pero esta manera de enfrentar nuestro problema debe evitarse, pues al final se termina manteniendo un sólo sitio como si fueran varios. Además, es un contrasentido al uso de los estándares pues ¿qué necesidad hay de ellos si en vez de usarlos uno termina adaptándose a las características de cada browser? En mi opinión, una buena codificación “cross-browser” se basa en encontrar el set de estándares que son soportados por todos los browsers y usarlos.

Valída tu sitio

La validación es un área ampliamente debatida y muchos “Jefes Nivel 2” dudan que este procedimiento realmente ayude en algo. Sin embrago, sí ayuda. Te asegura que no has cometido ningún error de tipéo, por ejemplo, en el código que has estado escribiendo -errores que son increíblemente difíciles de detectar manualmente-. Los validadores también chequean por errores de nesting (¿metiste un

dentro de un anchor (ancla)?) y por cualquier tipo de cosas extrañas que hayas tipeado. Te entregan información sobre cada error que encuentren y links a los lugares donde ellos aparecen. Sólo clickealos y estás en camino de aprender algo.

La Validación es el más simple de los trucos que uso para asegurar que todo está yendo bien. Existen validadores tanto para (X)HTML como para CSS. ¡Usa los! Cualquier error que te aparezca puede ser un potencial problema de “cross-browsing” y si decides ignorarlos debes estar muy seguro de lo que estás haciendo. Los validadores tienen sus razones para mostrarte los errores que tengas. Por esto: Valida. Arregla. Valida. Arregla.

Mantente en “standards mode”

Este truco no es tan obvio como el anterior. Los browsers modernos tienen dos maneras de renderizar el modo en que muestran los sitios web: Standars mode y Quirks mode. El primero está hecho para trabajar lo más de acuerdo posible a las especificaciones del W3C y el segundo es más cercano en su funcionamiento a los bugs (errores) propios de los browsers más antiguos. ¿Por qué hacer una modalidad que se base en errores? -te preguntarás. La respuesta es muy simple: es el modo que tienen los fabricantes de browsers de mantener a sus clientes felices. Si se hicieran cambios demasiado grandes en los motores de render de los browsers muchos sitios “viejos” corren el riesgo de desarmarse por completo. Algunos, inclusive, pueden pensar que esto está bien. ¿Por qué estos sitios mal codificados debieran funcionar bien, después de todo? Si tu eres uno de los que piensa así, entonces has olvidado para qué es la web. La web no es un sitio “For Experts Only”. Existe para todos los tipos de usuarios, o sea, para cualquiera que tenga un browser.

Entonces, si se libera un nuevo browser con un motor de render más apegado a los estándares, muchas páginas y sitios simplemente dejarían de funcionar como debieran. Eso sería tremendo para los usuarios. Es por esto que los fabricantes de browsers los construyen de modo tal que, primero identifiquen las páginas que han tratado de seguir los estándares y, si estas lo hacen, se cambian al modo mejorado de renderizar páginas web (Standards Mode). Ahora probablemente entenderás por qué sugiero el uso de la modalidad estandar. Todos los browsers tratan de renderizar lo más cercano posible a las especificaciones de los estándares cuando están en esta modalidad. Cuando están en la modalidad “Quirk” mantienen su viejos bugs (errores) sólo para ayudar a los usuarios cuyos sitios no cumplan con las especificaciones antes mencionadas.

Pero ¿cómo saben los browsers qué sitios siguen los estándares y cuáles no? Para esto usan el doctype. Si no estás muy interiorizado con los doctypes, no te preocupes, son muy fáciles de aprender. El doctype es un tag que se encuentra en la primera línea de código de cualquier página web y que le dice al browser que tipo de “lenguaje de marcas” (markup language) usarás en tu sitio. Existen, básicamente, dos tipos de doctypes entre los cuales deberías escoger:

HTML 4.01 Strict (el que recomiendo):

< !DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">

XHTML 1.0 Strict (sin < ?xml …> en la línea anterior)

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Al usar cualquiera de estos dos te aseguras que tu browser se cambiará a “standards mode” y tu diseño no arrojará errores. Usar el “doctype strict” significa que harás tu mejor esfuerzo por mantener separadas la estructura del diseño, y los validadores, de los que hablábamos al principio, tratarán de detectar errores en esas áreas. ¡Esto es muy útil! (Nota pequeña: el XHTML Transitional también puede cambiarse a “Standards Mode” pero mientras uses el Transitional como base no vas a obtener buenos chequeos de validación. Así que no los uses no más)

Hay un último punto del que es necesario hablar cuando de doctypes y standards mode se trata: el doctype necesita ser el primer tag en todo documento web. Si colocas cualquier otro elemento HTML (comentarios o caracteres extraños) antes que él, IE se volverá loco y se cambiará automáticamente a “Quirks Mode”. Hacer esto le ha traído incontables horas de dolor de cabeza a más de algún desarrollador web. Entonces: no lo hagas.

Elimina los estilos por defecto en los elementos

Otra de las causas de encontrarse con desarrolladores web gritando a las 3 de la mañana es el CSS que por defecto los browsers aplican a los elementos que muestran. Aún cuando no colocáramos ningún estilo CSS en nuestras páginas, los elementos de esta conservarían cierto look. Los headers serían más grandes que el texto de los párrafos y los blockquotes conservarían su padding. El tamaño de los textos es algo que funciona de manera relativamente similar en todos los browsers, pero no ocurre lo mismo con los paadings y margins.

Aquí va un ejemplo:

Un

    sin estilos se muestra con padding en Firefox pero margin en IE. ¿Y qué solución hay para eso? Colocarle margin o padding igual a cero y al otro colocarle el indent necesario para que ocupe la posición que queremos. O sea, de alguna manera hay que eliminar los estilos que por defecto el browser coloca para conseguir que se muestren por igual en todos ellos.

    Este tipo de problemas pueden consumir una buena cantidad del tiempo de desarrollo si no son manejados con cuidado. “¿La definición de listas (

    ) en el Opera tiene margin o padding?” “¿Qué pasa con los headers de segundo nivel en IE6?”. Hasta ahora existen dos métodos principales para manejar estos problemas. La primera de ellas plantea que desde el principio hay que “resetear” todos los margins a cero en el archivo CSS que estemos usando. Esto se puede hacer muy fácilmente escribiendo lo siguiente en el principio de nuestro CSS:

    * {

    margin: 0;

    padding: 0;

    }

    En este caso, el * funciona como un Selector Universal y aplica la misma regla para todos los elementos de la página.

    Problema resuelto, ¿cierto?

    Es aquí donde el segundo método aparece. Este método plantea que usando el método del *, se resetean demasiados margins. ¿Por qué deberíamos complicarnos con los margins de, por ej., los form fields si para poder usarlos vamos a tener que crear nuevos valores en nuestro CSS? En vez de esto, deberíamos resetear a cero sólo aquellos elementos que vayan a tener cierta diferencia en el modo en que los browsers los muestran, y dejar tranquilos el resto. El asunto es que para conseguir esto se requiere de bastante trabajo y por ello Faruk Ate? construyó su “starting css” template que puede ser fácilmente incluida en el de nuestros documentos. Personalmente, prefiero el método del * pero prueba ambos y decide por ti mismo.

    Los bugs de los browsers

    Esta es el área donde el CSS se pone difícil. A pesar de que los fabricantes de browsers hacen su mejor esfuerzo para seguir los estándares, muchas veces no lo consiguen. Esto nos deja a nosotros, los desarrolladores, lidiando con un montón de bugs que, si logramos solucionar, sólo es para activar otros nuevos bugs tanto en el mismo browser como en cualquier otro. O sea, las cosas se pueden complicar muy fácilmente.

    Uno de los peores browsers existentes (y que es ampliamente usado) es el Microsoft Internet Explorer versión 6. Muchos dicen que al ser ocupado por cerca del 80% del mercado no es un browser que uno pueda ignorar y punto. IE fue un buen browser en sus primeras versiones pero bajo los estándares de hoy día, ciertamente no lo es. Ningún otro browser me provocó tantos dolores de cabeza cuando estaba desarrollando este mismo sitio. Y realmente se comporta de manera terrible cuando se trata de renderear layouts CSS muy complejos.

    Entonces, ¿qué hacer con estos bugs? El método más fácil (y más rápido) es no tratar de solucionar los problemas por uno mismo. Buscar y leer las soluciones que ya mucha gente ha encontrado. “Holly ‘n John” ha juntado los bugs más frecuentes en su página Explorer Exposed!. Ahí encontrarás ejemplos de cómo detectar un bug, cómo funciona y (a veces) por qué. Y lo más importante: cómo solucionarlo. A veces la solución es tan simple como setear position:relative; o display:inline en algunos elementos. Otras veces hay que manejar códigos un poquito más extraños y difíciles. El punto aquí es que si encuentras algún bug en tu página no pierdas el tiempo tratando de descubrir qué pasa y cómo solucionarlo. Busca respuestas y las encontrarás (en esa lista y en otras muchas que hay esperando por ti en el web)

    Pero ¿qué hacer si “mi” bug no parece en esa lista?

    Obviamente: usa Google para encontrar una solución. Él se va a demorar un par de minutos en traerte lo que necesitas. Esto es nada comparado con la hora que vas a perder tratando de encontrar una solución por ti mismo. No menosprecies este paso.

    Si definitivamente no logras encontrar ninguna solución, entonces vas a tener que encontrarla por ti mismo. Para hacer esto, has una copia de tu página y elimina la mayor cantidad posible de código pero mantén el bug. Descubre cuál o cuales son las líneas de código que lo provocan y, finalmente, trata de encontrar otras maneras de hacer lo que ya tenías pero sin repetir aquellas que provocaban el bug. Esto es mucho más fácil que empezar a meter hacks en tu código, te permite mantenerlo y vas a aprender mucho más que si empiezas a meter código inentendible desde el principio.

    Si por alguna razón esta técnica tampoco te ayuda a solucionar tus bugs, tienes dos caminos: o re-piensas los que has hecho o echas mano a tu arsenal de hacks. Asegúrate que tus hacks validan bien. El que yo uso para IE cuando nada más me resulta es el hack “* html”. Tu también puedes usarlo, pero escribiéndolo de este modo:

    * html #element { code; }

    Este selector opera sobre todos los tags que tienen el child #element. Pero como el “html” es un elemento superior en la jerarquía, no se selecciona nada a menos que IE así lo decida. Por lo tanto este código sólo se aplica en IE. Es importante señalar que este hack es CSS perfectamente válido. Tan sólo que no selecciona nada. Recuerda: Los hacks son la última de las opciones que deberías usar. Echales mano cuando nada más te dé resultado.

    Update: 18 de Enero:

    En los comentarios, Richard señala que también se pueden usar comentarios condicionales para manejar ciertos