<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comentarios en: 10 errores comunes en los css</title>
	<atom:link href="http://www.tufuncion.com/errores_css/feed" rel="self" type="application/rss+xml" />
	<link>http://www.tufuncion.com/errores_css</link>
	<description></description>
	<lastBuildDate>Wed, 17 Mar 2010 19:42:39 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Por: Anónimo</title>
		<link>http://www.tufuncion.com/errores_css/comment-page-1#comment-6</link>
		<dc:creator>Anónimo</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">#comment-6</guid>
		<description>Los 10 puntos están bien, pero no sólo de minimizar bytes vive el hombre.

Considero que introducir /* comentarios */ en la hoja de estilo puede ayudar mucho a su mantenimiento.</description>
		<content:encoded><![CDATA[<p>Los 10 puntos están bien, pero no sólo de minimizar bytes vive el hombre.</p>
<p>Considero que introducir /* comentarios */ en la hoja de estilo puede ayudar mucho a su mantenimiento.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Anónimo</title>
		<link>http://www.tufuncion.com/errores_css/comment-page-1#comment-7</link>
		<dc:creator>Anónimo</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">#comment-7</guid>
		<description>Todos estos comentarios están bien, pero alguno reduce la legibilidad del código y llevarlos al extremo es absurdo. La hoja de estilo si está en un archivo css separado se cargará una única vez y se almacenará en la cachí© del navegador, por lo que la reducción de bytes es mí­nima. Creo que hay errores mucho más graves y más comunes que estos, y que afectan realmente a la visualización de la página. El principal desde mi punto de vista es no probar la página desde distintos navegadores y plataformas, y caer en el ya clásico problema del defectuoso modelo de cajas del explorer.

El primer consejo me ha dado problemas con algún navegador (no recuerdo cual ahora mismo). Y para el número 9 no ha elegido un gran ejemplo... pues ya me contará el autor quí© diferentes tonalidades de blanco existen entre los navegadores. Se pueden usar nombres sólo para los 16 soportados por la W3C: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow. Para el resto, mejor utilizar los códigos hex. </description>
		<content:encoded><![CDATA[<p>Todos estos comentarios están bien, pero alguno reduce la legibilidad del código y llevarlos al extremo es absurdo. La hoja de estilo si está en un archivo css separado se cargará una única vez y se almacenará en la cachí© del navegador, por lo que la reducción de bytes es mí­nima. Creo que hay errores mucho más graves y más comunes que estos, y que afectan realmente a la visualización de la página. El principal desde mi punto de vista es no probar la página desde distintos navegadores y plataformas, y caer en el ya clásico problema del defectuoso modelo de cajas del explorer.</p>
<p>El primer consejo me ha dado problemas con algún navegador (no recuerdo cual ahora mismo). Y para el número 9 no ha elegido un gran ejemplo&#8230; pues ya me contará el autor quí© diferentes tonalidades de blanco existen entre los navegadores. Se pueden usar nombres sólo para los 16 soportados por la W3C: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow. Para el resto, mejor utilizar los códigos hex.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
