Google
 

viernes, 18 de enero de 2008

No todos son iguales, pero hay que saber elegir


Puede que este post no este directamente relacionado con la tematica del blog, que es facilitarte códigos y soluciones en css y javascript para hacer que tus desarrollos web sean mas sencillos, pero creo que a cualquiera le puede ser de utilidad lo que les dejo a continuación.
SoloE.




Clientes

En el camino de los negocios conocemos cantidad y diversidad de clientes, personas, proveedores, que como seres humanos y empresas, tienen diferente ideología. Nos encontramos con clientes buenos, y otros no tanto.

De una experiencia desagradable que tuvimos con una empresa, aprendimos varios puntos importantes que debemos tomar en cuenta antes de enredarnos en un contrato para prestar nuestros servicios.

1. Historial de la empresa: Es el punto más importante, hay que investigar el historial de la empresa para ver si es confiable, si ha tenido problemas con clientes pasados y que tal anda su “reputación” dentro de su giro. Si nos enteramos que tienen un historial no muy agradable o malo, pensemos realmente si nos traerá beneficios. En ocasiones es mejor alejarnos porque podremos perder mucho más.

2. El contrato: Es de vital importancia que nuestro contrato sea, concreto, claro y que tenga fechas en las cuales vamos a terminar de prestar los servicios, fechas de pago y por supuesto tener una taza de interés por pago atrasado, esto para “presionar” a la empresa a que pague a tiempo.

3. Las llamadas telefónicas: Es importante estar al tanto de las actividades de la empresa con regularidad, llamar una vez por semana para preguntarles que les ha parecido el servicio y cuando podemos pasar por el pago siguiente. Nunca confiar demasiado y dejar pasar hasta la fecha acordada. Puede ser que la empresa desaparezca de un momento a otro sin avisar.

4. Hacer citas: Para ir a recoger un cheque o el efectivo, es de gran importancia hacer citas, de no ser así podemos perder mucho tiempo y dinero en dar vueltas que no servirán de nada

5. Ser paciente: No desesperarnos si a la segunda llamada no nos han pagado, probablemente tuvieron problemas, pero si se atrasan 2 semanas entonces las cosas cambian, sin embargo es muy importante no perder la cordialidad, suele suceder que ya estamos artos de llamar y no recibir una respuesta válida, pero recordemos que la reputación y la imagen de nuestra empresa está en juego si perdemos la paciencia y les gritamos en la cara lo malos que han sido. Ahora que si pasan 3 meses y no hay respuestas, mejor llamamos a un abogado o un policía para que vayan con nosotros por el pago.(Es broma…pero podría ser)

6. Y la más importante. Retroalimentación: Al término del contrato, debemos evaluar si realmente queremos continuar prestando servicios a la empresa, si nos costó trabajo cobrar los cheques, si fueron amables, etc. Suele pasar que una empresa es muy mala con los pagos, y al término del contrato nos solicitan otros servicios nuevamente, y esta vez de una suma interesante, hay que pensar si realmente nos conviene continuar o mejor despedirnos cordialmente. Por lo general nunca cambian.

Conocimos a una de las empresas más irresponsables del estado, tuvimos la oportunidad de ver como empresas nacionales, les gritaban en la cara lo malos que eran. Con decirles que tardamos casi un mes en cobrar un saldo de $450.00 PESOS. Eso nos pasó por no investigar, pero aprendimos que los puntos ya mencionados son importantes al momento de hacer negocios con cualquier empresa.

No todo lo que brilla es oro.

Fuente: http://www.closip.com/blog/noticias/2008/01/17/no-todos-son-iguales-pero-hay-que-saber-elegir/

Selección avanzada de elementos en CSS 2 y CSS 3

Generalmente, cuando queremos seleccionar un elemento 'especial' de nuestro HTML con CSS, llenamos este con id, class, span, que muchas veces son completamente inútiles, y casi siempre, para nada semánticos.

Este tip, que se complementa con el de pseudoclases y pseudoelementos, nos ayudará en la tarea de tener un HTML limpio y sin mucho class="" o .

Ver articulo completo en Cristalab.

Cómo reducir el peso de los archivos de estilos CSS

En proyectos enormes, nos encontramos con que nuestros archivos CSS no son 100 lineas, sino 1000 y su peso no es 3KB sino 100KB.

Cada segundo de carga es vital, así que voy a dar unos tips de como arreglar esto. ¿Cual es la base de todo esto? Legibilidad a cambio de tamaño y/o segundos al cargar la página. Es decir, cambiaremos la facilidad de lectura e identación de los archivos .css (algo innecesario con un .css en producción) por un ahorro considerable en el peso de nuestros estilos.

El selector * selecciona todos los elementos.

Este es mi favorito, solo vean:
* {
margin:0;
padding:0;
font-family:Verdana, Helvetica, Arial, sans-serif;
font-size:12px;
text-decoration:none;
}
Al principio defines las propiedades que la mayoría de las veces pones, y te ahorras ponerlas en el resto del código. ¿Quien no ha definido en millos de etiquetas margin:0 y padding:0?, ¿Quien o ha puesto text-decoration:none, a cada una de las pseudoclases de < size="3">Se pueden resumir las etiquetas en una sola.Background-image, background-position, border-style, border-color... todas esas etiquetas se pueden resumir en una sola.

#menu {
position:absolute;
background-color:#889900;
background-image:url(menu.jpg);
background-position:top;
background-repeat:repeat-x;
border-color:#000000
border-style:dashed;
font-family:Arial;
font-size:12px;
float:left;
}


Pasa a ser.
#menu {
position:absolute;
background:#889900 url(menu.jpg) top repeat-x;
border:#000000 1px dashed;
font:12px Arial;
float:left;
}

Las etiquetas coinciden sin importar la clase o id.

li.headmenu {
list-style:none;
display:block;
color:#FF9900;
background:#666666;
}
li.menuizq {
list-style:none;
display:block;
color:#FF9900;
background:#666666;
float:left;
}
li.menuder {
list-style:none;
display:block;
color:#FF9900;
background:#666666;
float:right;
}


Pasa a ser:

li {
list-style:none;
display:block;
color:#FF9900;
background:#666666;
}
li.menuizq {
float:left;
}
li.menuder {
float:rigth;
}

Se pueden seleccionar diversos elementos separados por comas.

#bg1 {
position:absolute;
width:150px;
height:80px;
border:#454545 1px solid;
color:#222222;
}
#bg2 {
position:absolute;
width:150px;
height:80px;
border:#454545 1px solid;
color:#333333;
}
#bg3 {
position:absolute;
width:150px;
height:80px;
border:#454545 1px solid;
color:#FF9900;
}


Se puede convertir a:
#bg1, #bg2, #bg3 {
position:absolute;
width:150px;
height:80px;
border:#454545 1px solid;
}
#bg1 {
color:#222222;
}
#bg2 {
color:#333333;
}
#bg3 {
color:#FF9900;
}

CSS no lee los espacios en blanco.

¿Tengo que explicarlo? Usemos el mismo código anterior.

#bg1, #bg2, #bg3 {position:absolute;width:150px;height:80px;border:#454545 1px solid;}
#bg1 {color:#222222;}
#bg2 {color:#333333;}
#bg3 {color:#FF9900;}


Ahora, aplicamos dos puntos mas:
  • Se pueden obviar las comillas en la última propiedad de una etiqueta.
  • Se pueden reducir algunos colores a 3 dígitos.

#bg1, #bg2, #bg3 {position:absolute;width:150px;height:80px;border:#454545 1px solid}
#bg1 {color:#222}
#bg2 {color:#333}
#bg3 {color:#F90}


Ahora nuestra tarea es elegir y poner en una balanza cuanto queremos cambiar a cambio del otro. Si aplicamos todos, nuestro código va a ser una masa sin sentido. Hay que ser sensatos.


Fuente: http://www.cristalab.com/tips/51134/como-reducir-el-peso-de-los-archivos-de-estilos-css

Contrato de diseño web

Si eres desarrollador web ¿cuantas veces has tenido la necesidad de hacer un contrato de desarrollo de sitio web? esto es algo muy necesario para evitar malos entendidos y formalizar la relación con el cliente. Yo antes cada contrato lo hacía diferente y sinceramente sin respaldo legal.

ley-en-linea.png

Existe un proyecto dentro del sitio de ley en línea llamado El Contrato de Desarrollo de Sitio Web este es un proyecto abierto que acepta opiniones para mejorarlo ya que cuenta con un wiki y está publicado con licencia Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Mexico License el autor de este contrato es Jorge Ringenbach sin duda este proyecto va ser de muchísima utilidad para muchos desarrolladores web.

Lo que no sé es si este contrato tenga validez completa en otro país que no sea México porque en la sección de resolución de controversias dice que se somete a la legislación vigente de la ciudad de México.


Descarga el contrato de Desarrollo de Sitio Web, visto en Maestros del Web


Descarga alternativa.


Fuente: http://www.carlosleopoldo.com/post/contrato-de-diseno-web/

lunes, 14 de enero de 2008

Libro Gratis: Introducción a AJAX de Javier Eguíluz Pérez

El término AJAX se acuñó por primera vez en el artículo "Ajax: A New Approach to Web Applications" publicado por Jesse James Garrett el 18 de Febrero de 2005. Hasta ese momento, no existía un término normalizado que hiciera referencia a un nuevo tipo de aplicación web que estaba apareciendo.

En realidad, el término AJAX es un acrónimo de Asynchronous JavaScript + XML, que se puede traducir como "JavaScript asíncrono + XML".

El artículo define AJAX de la siguiente forma:

"Ajax no es una tecnología en sí mismo. En realidad, se trata de la unión de varias tecnologías que se desarrollan de forma autónoma y que se unen de formas nuevas y sorprendentes."


Descarga desde LibrosWeb.es

Descarga Alternativa


Fuente: http://planetalibro.com.ar/ebooks/eam/ebook_view.php?ebooks_books_id=1505

miércoles, 12 de diciembre de 2007

Tutorial básico de XHTML


XHTML es una reformulación del HTML 4.01 aplicandole XML que se ha convertido en un estándar aprobado por el W3C desde el 26 de enero del 2000. La principal razón de su uso es la creación de código limpio, separando el contenido del diseño, además dado que está basado en XML, es posible su lectura e interpretación en cualquier dispositivo móvil que soporte XML. Anteriormente Pedro, nos dió una introducción breve a lo que es XHTML.

¿Qué es exactamente XHTML?

  • Es un reemplazo del HTML tradicional
  • Es una versión más estricta y limpia del HTML
  • Se define como una aplicación XML
  • Es una recomendación del W3C

Reglas básicas del XHTML

Al ser una recomendación y un estándar, es necesario observar que nuestros documentos XHTML deben respetar ciertas reglas básicas :

1. Todos los elementos deben estar debidamente jerarquizados
2. Todo documento debe estar bien formado
3. Los nombres de las etiquetas deber estar en mínusculas
4. Todas las etiquetas deben cerrarse
5. Los nombres de los atributos deben ir en minúsculas
6. Los valores de los atributos deben ir entre comillas
7. El atributo id reemplaza al atributo name

El DOCTYPE

Todos los documentos XHTML válidos deben llevar un elemento llamado DOCTYPE, el cual no es parte del documento en sí, sino que define el tipo de DTD (Document Type Definition o Definición de tipo de documento) a emplear en nuestros documentos, es obligatorio.

  • XHTML 1.0 Strict: Se usa cuando se desea utilizar al 100% XHTML, su nombre lo dice bien claro, es XHTML estricto.

  • HTML 1.0 Transitional: Es el más usado ya que permite manejar elementos de XHTML y HTML 4.01, además de que se debe usar cuando nuestro navegador no soporta correctamente CSS(¿No les recuerda a una E azul?), su declaración es la que sigue:

  • XHTML 1.0 Frameset: Se debe usar cuando se manejan frames


Conclusión

Como desarrolladores y diseñadores web debemos siempre apegarnos a las normas y estándares internacionales ya que con esto no sólo logramos que nuestras aplicaciones sean 100% compatibles, sino que nos hacemos más profesionales, espero que este breve minitutorial les haya servido de ayuda

Enlaces de Intéres

Tutorial de XHTML de la W3Schools.

Referencia del XHTML

Validador XHTML de la W3C



(Recomendado) Fuente. http://www.cristalab.com/tutoriales/143/tutorial-basico-de-xhtml

Insertar SWF de Flash en XHTML valido


Los evangelistas del código abierto (open source) y estandaristas (evangelistas por lo estándar) siempre han estado en plena guerra a ciegas contra flash por muchos aspectos ya discutidos en el articulo "Usas flash, entonces te odio". Pero creemos que flash puede ser muy bien usado y complementar una web basada en estándares.

Por lo tanto, este tutorial expondrá brevemente cómo introducir flash en páginas XHTML y mantener el código estándar.

Nota: Para éste tutorial necesitas tener previos conocimientos sobre XHTML.

¿Por qué usarlo? Pros y Contras

Pros:
Nuestro código será XHTML estándar, el código pasará satisfactoriamente las pruebas de validación, el código será más chico, fácil de entener, escribir y memorizar.
Contra:
Aunque no todo es maravillas, Internet Explorer no crea el streaming en la animación flash, pero tiene solución y hablaremos de ésto más adelante.

Método Twice-Cooked

Éste es el nombre del método que usan los programas de Macromedia para insertar una animación flash en una página HTML.

Algo complejo ¿No creen? Ahora veamos una forma más sencilla y estándar, el método Satay.

Método Satay

Ahorrandonos las largas explicaciones técnicas, veran que éste código es mucho más simple, sencillo y fácil de manejar. Lo único que habrá necesidad de modificar es:
data, movie :
En este atributo agregaremos la URL del archivo flash (.swf).
width, height :
El ancho y alto del archivo flash y la imagen.
img:
Agregamos una imagen por si el usuario no tenga el flash player instalado.

Y eso es todo, para Firefox, Opera, Safari y el resto de navegadores con el mismo nucleo, pero recuerden que hay un ligero problema con Internet Explorer. No hay streaming.

Agregandole streaming

¿Qué necesitamos para que funcione correctamente y obtenga streamming nuestra animación flash? La respuesta es, un contenedor.

Para lograr esto crearemos un flash completamente vacío, excepto por el siguiente código actionscript en el primer frame.

_root.loadMovie(_root.path,0);

Y variamos un poco la ruta del XHTML

Enlaces

El método Satay fue creado por Drew McLellan y publicado por primera vez en A List Apart. Para mayor información tecnica sobre este "método" pueden revisar el artículo en A List Apart, Flash Satay: Embedding Flash While Supporting Standards.


Fuente: http://www.cristalab.com/tutoriales/154/insertar-swf-de-flash-en-xhtml-valido

lunes, 10 de diciembre de 2007

7 reglas de oro para hacer un javascript no obstructivo

Con la llegada de Ajax, la llegada de la lógica de negocio a las aplicaciones web y sobretodo al cliente han producido un incremento del javascript usado en las mismas. El motivo es la funcionalidad que se puede llegar a conseguir en el cliente aligerando el número de recargas de página en nuestras aplicaciones.

Al incrementarse el javascript, innevitablemente estamos haciendo Javascript dependientes nuestras aplicaciones. Mucha gente me dice que el 96% de los usuarios de Internet tienen Javascript activado en su navegador y tienen razón, pero ¿que pasa con ese 4% restante? ¿nos olvidamos de ellos?

Para evitar tener que hacernos esta comprometida pregunta, ya que no creo que ningún cliente quiera pensar… ¿no han pensado en mi?, podemos salir del paso haciendo un uso inteligente de Javascript y dando siempre un camino alternativo a los usuarios que no disponen de este lenguaje activado en su navegador. Para ello, siguiendo una serie de pautas podremos conseguir que nadie se quede fuera de nuestra aplicación.

No hagas suposiciones

Como dicen en todas las pelis deportivas sensiblonas, “La mejor defensa es un buen ataque”. Por ese motivo, una aplicación debería desarrollarse sin javascript, hacer que esta funcione y posteriormente mejorar la usabilidad y añadir funcionalidades extras con javascript. Para ello a la hora de desarrollar planteate:

  • El javascript no tiene por que estar activado, ¿funcionará sin él?
  • Piensa que aunque tenga Javascript activo, puede que no soporte ciertos métodos o funciones. ¿será compatible?
  • Mantener la funcionalidad de forma independiente al dispositivo de entrada
  • Piensa que otros scripts pueden interferir con tus scripts.

Busca las relaciones

Antes de ponernos a desarrollar debemos asegurarnos que tenemos un HTML estructurado y correctamente etiquetado. De esta forma nos ahorraremos líneas de código intentando acceder a nuestros elementos, una base sólida nos dará tranquilidad.

Para ello hemos de tener una serie de puntos bien sabidos:

  • El ID de los elementos es único por página, tener 2 elementos con el mismo ID causará problemas en nuestros scripts, métodos como getElementById() no funcionarían correctamente.
  • Si nos vemos obligados a tener 2 elementos similares, siempre podemos usar elementos class, para referenciarlos. Implementaciones como getElementsByClassName() hacen posible que trabajemos con este tipo de atributos.
  • Planteate la forma más rápida de acceder a un elemento con el menor número de pasos por el DOM.
  • O, ¿que elemento debes modificar para acceder al mayor número de hijos que quieres modificar?
  • ¿Qué atributos o que información me ayuda a enlazar elementos?

Recorrer el DOM es costoso y lento, por ese debemos optimizar el número de pasos que hacemos sobre él.

Deja que los expertos lo recorran

DOM es un método muy interesante y práctico para recorrer nuestra página, pero como hemos dicho antes es realmente costoso y lento para nuestras aplicaciones. Una alternativa para algunos es casos es hacer uso de la tecnología más rápida en recorrer el arbol DOM, el CSS.

Como bien sabemos la finalidad del CSS, es dotar de estilo nuestro HTML, y por ello debemos, en medida de lo posible, usarlo para eso. Evitaremos hacer cosas como estas:

var n = document.getElementById('nav');
if(n){
var as = n.getElementsByTagName('a');
if(as.length > 0){
for(var i=0;as[i];i++){
as[i].style.color = '#369';
as[i].style.textDecoration = 'none';
}
}
}

cuando podamos hacer cosas como estas

//Javascript
var dynamicClass = ‘js’;
var b = document.body;
b.className = b.className ? b.className + ‘ js’ : ‘js’;

//CSS
/* static version */
#nav {
….
}

/* dynamic version */
body.js #nav {
….
}

o estas,…

//HTML

blabla…




//Javascript
var el = document.getElementsByClassName(”textnormal”)[0];
if (el) {
el.className = “textNegrita”;
}

//Css
.textnormal {

}

.textNegrita {

}

Conoce bien a tu enemigo

Hemos de entender que esto es una guerra, los navegadores son nuestros enemigos y hemos de no dejar flancos sin cubrir para que nos puedan cazar. Por ello debemos conocerlos bien, saber donde flojean y por que nos pueden causar un error. Si hace falta, crea otro fichero especialmente para él.

Como javascript es un lenguaje que nos ayuda a mejorar la usabilidad de nuestro sitio, podemos hacer funcionalidades exclusivas para los que tengan javascript activado. Por poner un ejemplo, los navegadores no ofrecen un sistema sin javascript para lanzar la impresión de página, por ese motivo podemos generar el contenido desde javascript, dejando al margen a todos los usuarios que no lo tengan activado. ¿No les pondremos la miel en los labios si no lo van a poder usar no?

Entiende los eventos

La gestión de eventos es sin duda la clave del javascript no obstructivo. El uso de una gestión de eventos, proporciona una separación necesaria de la capa de funcionalidad, haciendo que los elementos de la estructura esperen el evento definido. Estos eventos pueden ser definidos teniendo en cuenta:

  • Solo necesitas comprobar que un simple elemento existe, no todos ellos.
  • Puede añadir o eliminar dinámicamente nuevos elementos hijos sin tener que eliminar o añadir nuevos controladores.
  • Puedes usar el mismo evento en diferentes elementos.

Tambien debemos recordar que lo eventos pueden ser detenidos.

Juega bien con los demás

Generalmente nuestros scripts suelen estar en un solo fichero con lo que llegamos a cargar una gran cantidad de variables globales y funciones que no llegamos a usar a lo largo del uso de la aplicación. Una muestra de ello son el uso de frameworks, por ello debemos saber donde y cuando debemos usar variables globales. Veamos un ejemplo:

var nav = document.getElementById('nav');
function init(){
// do stuff
}
function show(){
// do stuff
}
function reset(){
// do stuff
}

De esta forma estamos definiendo una variable global que podemos usar en todas las funciones anteriores.

var myScript = {
nav:document.getElementById('nav'),
init:function(){
myScript.show();
if(myScript.nav.className === 'show'){
myScript.reset();
}
// do stuff
},
show:function(){
var c = myScript.nav.className;
// do stuff
},
reset:function(){
// do stuff
}
}

De esta forma, únicamente usaremos la variable nav para estos métodos del objeto, aunque para usarla debemos escribir demasiadas letras :D Tambien podemos necesitar hacer que desde fuera del objeto no podamos acceder a ciertos métodos y a otro sí, para ello podemos hacer lo siguiente.

var myScript = function(){
// these are all private methods and properties
var nav = document.getElementById('nav');
function init(){
// do stuff
}
function show(){
// do stuff
}
function reset(){
// do stuff
}
var foo = 'bar';
function public(){

}
// return public pointers to the private methods and
// properties you want to reveal
return {
public:public,
foo:foo
}
}();

myScript.public(); //OK

myScript.init(); //ERROR

Fuente: http://www.anieto2k.com/2007/11/14/7-reglas-de-oro-para-hacer-un-javascript-no-obstructivo/

Javascript no obstructivo, Manual de buenas maneras


Esto pretende ser una traducción de un fabuloso artículo de Christian Heilmann.

Javascript es una herramienta maravillosa para mejorar la usabilidad de las aplicaciones web. Es una capa extra entre la estructura (HTML) y el diseño(CSS). Javascript nos permite alterar el comportamiento de un elemento.

Uno de los problemas con los que nos encontramos a la hora de desarrollar aplicaciones web con javascript son problemas de accesibilidad derivados al no contemplar la posibilidad de que un usuario nos visite con un navegador que no interprete este lenguaje. Una técnica para corregir este problema sería el separar el javascript de las otras 2 capas del desarrollo web (estructura y diseño), esto recibe el nombre de Javascript no obstructivo o Javascript Accesible.

La frase, “¡¡Divide y vencerás!!” se adapta perféctamente a esta idea, en la cual separaremos cada capa en su respectivo fichero, de forma que en cuanto a mantenimiento (la etapa más costosa y larga del desarrollo de una aplicación) e incluso la comprensión de la aplicación se verán afectadas positivamente en cualquier aplicación.

Ver traduccion completa del artículo.

Ver artículo Original en Ingles.

martes, 4 de diciembre de 2007

10 errores comunes en los css

Esta es una recopilación de errores comunes en las hojas de estilo. Es bastante provechoso hacer una lista con estos y otros errores comunes.

1.Uso innecesario del valor 0

El código siguiente no necesita la unidad especificada si el valor es cero.
padding:0px 0px 5px 0px;

En su lugar puede ser escrito de esta manera:
padding:0 0 5px 0;

De la misma manera es igual para otros estilos. Ej.:
margin:0;

No malgastes espacios agregando unidades tales como px, pt, em, etc, cuando el valor es cero. La única razón de hacer esto es si necesitas cambiar estos valores más tarde. Si no declarar estas unidades no tiene sentido. Los pixeles cero son iguales que los puntos cero.

Sin embargo,line-height puede no tener unidad.Por eso es válido lo siguiente:
line-height:1;

De cualquier manera puedes utilizar una unidad en concreto como em si lo deseas.

2.Los colores en formato hexadecimal necesitan una almohadilla

Esto está mal:
color: ea6bc2;

Debe ser:
color: #ea6bc2;

O esto otro:
color: rgb (234.107.194);

3.Valores duplicados en los códigos de colores

No escribir el código de esta manera:
color: #ffffff;
background-color:#000000;
border:1px solid #ee66aa;


Los valores duplicados pueden ser omitidos.Escribiendo los códigos de esta manera:
color:#fff;
background-color:#000;
border:1px solid #e6a;


¡Por supuesto esto no debes hacerlo con códigos como este!
color: #fe69b2;

4.Evitar repeticiones de código innecesaria

Evita usar varias líneas cuando lo puedes conseguir con una sola. Por ejemplo, al fijar los bordes, algunas veces se debe hacer por separado pero en casos como el siguiente no es necesario:

border-top:1px solid #00f;
border-right:1px solid #00f;
border-bottom:1px solid #00f;
border-left:1px solid #00f;


Podríamos resumirlo en una única línea esta:
border:1px solid #00f;

5.La duplicación es necesario con los estilos en cascada

En los estilos en cascada es aceptable repetir el mismo codigo para un elemento elemento dos veces, si significa evitar la repetición mencionada en el punto arriba. Por ejemplo, digámos que tenermos un elemento donde solamente es diferente el "border" izquierda. En vez de poner cada "border" escrito usando cuatro líneas, uso sólo dos:

border:1px solid #00f;
border-left:1px solid #f00;


En este caso primero definimos todos los "borders" con el mismo color pero más tarde para ahorrarnos dos lineas de código redefinimos el "border" izquierda a otro color, de esta manera hemos ahorrado dos líneas de código.

El ejemplo malgastando espacio quedaría así:
border-top:1px solid #00f;
border-right:1px solid #00f;
border-bottom:1px solid #00f;
border-left:1px solid #f00;


Obviamente supuestamente este ahorro de carga supone un retraso en la carga de la página pues estamos definiendo el "border" izquierda dos veces, pero la carga de este proceso es insignificante.

6.Los estilos inválidos no hacen nada

Un ejemplo es suficiente para explicar este error:
padding:auto

Este estilo solo puede ser aplicado a width y height pero no a padding.

7.Código Específico para cada navegador

Obviamente este tipo de código solo funcionará en el navegador al que va destinado , pero es hay que pensar si es rentable puesto que solo algunos usuarios podrán apreciar esos cambio.

8.Espacio perdido

No estoy seguro del porqué pero muchos diseñadores estan empeñados en desaprovechar el espacio en su código, usando un montón de innecesarios saltos de línea. Recuerda que eso sólo lo verás tu y estas haciendo un uso excesivo de ancho de banda. Tambien tu código será más facil de leer puesto que tendrá menos "boquetes".

Por supuesto es sabio dejar un cierto espacio para mantenerlo legible, aunque a algunos les encanta condensar todo, no dejando ningún espacio.

9.Especificar los colores sin usar palabras

Definir los colores usando las palabras que lo definen no es una buena idea puesto que estaríamos confiando en el navegador para que el interprete que color y código debe aplicar.Las tonalidades para un mismo nombre de color cambian mucho de un navegador a otro.

Es una buena práctica especificar siempre el color por su código hexadecimal.
Ej.: utilizar "#fff" en lugar de blanco.

10.Agrupar estilos idénticos

Es común ver los estilo escritos una y otra vez con el mismo código, aún cuando el estilo es igual.

Sería conveniente agruparlos y asi optimizaríamos espacio:
h1, p, #footer, .intro {
font-family:Arial,Helvetica,sans-serif;
}


Tambien nos hara mucho más facil la tarea de actualizar el código.


Fuente: http://www.desarrolloweb.com/articulos/10-errores-comunes-css.html