SharePoint Blogs / SharePoint University
SharePoint Blogs and SharePoint University - all in one place!
Need SharePoint Training? Attend a SharePoint Bootcamp!

Please delete cookies related to sharepointblogs.com and sharepointu.com to resolve login issues!

Master Page debugging 2: CSS

HAZ CLIC EN EL TITULO DEL ARTICULO PARA VERLO MEJOR (SIN CORTES) 

En el artículo anterior escribí acerca de cómo construir un Master Page que funcione con MOSS. También les conté sobre los controles y algunos tips, además del Minimal Master Page y de mi xMP. Faltó, por supuesto, un gran detalle: los estilos visuales, o archivos CSS.

Antes de empezar

Todo lo que escribiré respecto a CSS es, casi siempre, dentro del contexto de MOSS (o SharePoint) en todo caso. No soy un experto en diseño web, ni tampoco en CSS. Lo que voy a escribir es lo que he aprendido desde MOSS Beta 2 y que me ha servido hasta el dia de hoy para construir sitios web MOSS altamente personalizados, visualmente hablando.

Background teorico (y un poquito de historia)

Hace mucho tiempo atrás, en una galaxia muy lejana… las páginas web servían para mostrar básicamente texto y algunas imágenes. Las personas recibían información tal como noticias, artículos, o informes mediante este nuevo medio que Tim Berners Lee llamó la “World Wide Web” o WWW. Como la tecnología era nueva, casi todos éramos felices con lo que había. Estas páginas se escribían con un lenguaje llamado HTML que básicamente define elementos mostrados en la página de acuerdo al orden en que son llamados a la hora de escribirla (o “programarla”), además de poder definir el color y un poco los estilos visuales de estos elementos, a decir: color de textos, tablas filas, columnas, fondo, imagen, etc.

Esto funcionaba bien para el uso inicial de la web: páginas simples orientadas en su mayoría al texto. Pero al popularizarse la tecnología, se empezó a elaborar cosas un poco mas complejas: animaciones, layouts avanzados asistidos por diseñadores, etc. HTML fue evolucionando para dar soporte a mas elementos, (“etiquetas”), y los navegadores los acompañaron en esto.

Luego, la web se convirtió en un medio de comunicación masivo, visitado por millones de personas diariamente, que mostraba contenidos dinámicos, dando soporte ya no solo a páginas, sino a aplicaciones, portales, extranets… el término “web” se popularizó y pasó a ser una manera más de poder extender una aplicación completa hacia el usuario, dándole acceso remoto desde prácticamente cualquier lugar, con tan sólo un navegador web. Aplicaciones corporativas, aplicaciones de terminales remotos, aplicaciones de trámites en línea (formularios), aplicaciones de audio/video… en fin.

Todas estas aplicaciones y páginas dinámicas eran (y son actualmente) generadas por un servidor, aplicando lógica visual y funcional mediante la utilización de una serie de lenguajes de programación, cuyo resultado de procesamiento es finalmente enviado hacia el navegador del usuario en formato HTML. Visual y funcionalmente este contenido mostrado es espectacular, pero es un spaghetti a la hora de mantener/editar/depurar: lo que define la estructura (tal como una etiqueta de columna) tenía codificada además del contenido en sí, a sus atributos visuales, como por ejemplo, color de fondo, de texto, o ancho total (quienes hayan visto ASP clásico o JSP sabrán a lo que me refiero). Si un diseñador web quería modificar un elemento netamente visual de la página, tenía que entrar necesariamente a trabajar junto con el código que define la estructura, contenido y formato, lo que ciertamente ponía en riesgo la integridad de la página, y hasta la funcionalidad: una etiqueta pasada por alto, un borrón de más, y fue. Funcionalidad rota, contenido inservible. Forma y fondo juntos hasta la muerte. Carpe noctem web designer!!

CSS (Cascading Style Sheets)

Afortunadamente a alguien se le ocurrió la sabia idea de separar forma de fondo. Regresar al HTML para definir contenido, pero poner en otra capa el tema visual. De este modo, los autores de contenido tendrían que encargarse solamente de crear contenido, y los diseñadores web se encargarían de definir cómo luce, donde va, y cómo va ordenado este contenido. Esta capa extra se conoce como Hoja de Estilos en Cascada, o Cascading Style Sheet (CSS).

Veamos cómo se definían los estilos visuales en una página web de los primeros tiempos

Verás que ese elegante fondo verde está definido como color de la celda, directamente en el mismo archivo HTML. Si quisiera hacer un cambio de color, tendría que editar el archivo HTML, pudiendo accidentalmente alterar el contenido

Un archivo CSS es un archivo de texto plano que tiene definidos ciertos formatos visuales agrupados, por ejemplo, uno de estos grupos (formalmente llamado “clase”) podría llamarse “.fondo-verde” y especificar un tipo de fuente determinado (Arial?, Verdana?, Courier?, cual te provoca?), su tamaño (10pt?, 12pt?), su color, su posición relativa al borde de la página, o relativa a la etiqueta HTML próxima, su visibilidad, su borde, sus márgenes… en fin. De modo que en lugar de editar el estilo visual en el mismo documento HTML, asocio este archivo CSS al archivo HTML, y además asocio las etiquetas HTML que yo desee con los estilos definidos en el CSS, así

NOTA: esta no es la única manera de incluir estilos en un documento HTML. Existen varias maneras de hacerlo, pero creo que de este modo se produce una separación clara entre las capas HTML y CSS

Te das cuenta que conseguimos el mismo resultado? Pero hemos separado las capas HTML y la capa de diseño (que define, entre otras cosas, el color). Y la magia la hace el famoso archivo llamado en este caso estilos.css, que tiene el siguiente código:

Este código tiene instrucciones CSS. Si buscas en internet podrás encontrar información de cómo utilizarlo.

Entonces es claro que ahora un diseñador web puede dedicarse a modificar el código CSS (que está en el archivo CSS), mientras que los editores de contenido o de formato se pueden encargar de lo que les corresponda. Además, si aprendes a utilizar CSS, podrás lograr efectos espectaculares, que simplemente no se podían lograr (al menos tan “elegantemente”) con el formato visual limitado del HTML.

Para cerrar este punto, puedes asociar múltiples hojas de estilos a un documento HTML, de modo que si un estilo no se encuentra en una, se buscará en otra, y así sucesivamente. El orden en que son referenciadas las hojas de estilos define la precedencia de un estilo sobre otro que se encuentre definido con el mismo nombre en otra hoja de estilos. El último estilo referenciado será el que sea aplicado efectivamente de modo incremental, tomando un comportamiento de “cascada” (de ahí el nombrecito).

OK, y SharePoint?

Que crees… SharePoint utiliza CSS en sus páginas. En el post anterior a este expliqué cómo están formadas las páginas en SharePoint, y cómo crear un propio Master Page… pero sin estilos visuales!! Ahora veremos cómo darle vida a ese Master Page via CSS. Hang on!!

Primero, aterricemos en MOSS. Lo que pasa es que no es tan fácil el manejo de Master Pages en WSS, al menos fuera de la caja, y todo este tema de branding se da mucho mas fuerte en MOSS que en WSS, así que acá nos quedamos –aunque, ciertamente, algunas partes de lo que viene a continuación puede aplicar también a WSS, pero no haré distinciones en ello.

Los Master Pages que trae MOSS utilizan sus propios CSS, en algunos casos un master page puede utilizar no solo uno, sino varios CSS. En el caso del Master Page que MOSS utiliza por defecto en los sitios de colaboración (default.master), MOSS emplea un archivo en particular y MUY importante llamado CORE.CSS

CORE.CSS

CORE.CSS es un archivo CSS que se encuentra en el sistema de archivos de los servidores Web Front-End de MOSS, en la ruta C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\<lcid>\STYLES\CORE.CSS (donde lcid es el código regional: 3082 si los binarios son en español, 1033 si están en inglés, etc.), el cual es utilizado como base para casi todos los estilos visuales de MOSS, tanto para las páginas de vista al usuario final, páginas administrativas, páginas de listas, de vistas de formulario, etc. Puedes encontrar una guía de las clases CSS que afectan a determinadas zonas del Master Page por defecto de MOSS en este post. Además, si tu inicias una modificación (o creación) de Master Page a partir de default.master, y asocias tu propio archivo CSS a este nuevo Master Page, y no modificas *la totalidad* de estilos, entonces el resto serán aplicados a partir de CORE.CSS. Es decir, primero se aplicarán TUS estilos y luego los de CORE.CSS (cascada, recuerdas?). En conclusión: CORE.CSS es un archivo crítico en MOSS, y no debe ser removido ni modificado, ya que esto no es soportado ni tampoco recomendado.

Incluir archivos CSS adicionales

Entonces, si no debemos tocar CORE.CSS, tenemos dos opciones:

- Hacer una copia de éste, ej: CORE-COPY.CSS, y modificarlo, asociándolo por supuesto al Master Page deseado, o de otro modo

- Incluir un archivo CSS totalmente distinto, empleando clases propias y alejarnos de las clases que trae MOSS por defecto.

Hacer una copia de CORE.CSS

Esto es bastante simple. Entra a la carpeta donde se encuentra CORE.CSS y realiza una copia del archivo, en la misma carpeta.

Asumiendo que esta nueva copia se llama CORE-COPY.CSS, debes asociarla a tu Master Page del siguiente modo:

1. Abre tu sitio SharePoint desde SharePoint Designer

2. Ve a la carpeta _catalogs/masterpage (esta es la ruta virtual expuesta desde la base de datos para el Master Page Gallery)

3. Abre algún Master Page, desprotegiéndolo (check-out) –puedes abrir default.master para empezar

4. En el código, ubica el control <SharePoint:CssLink runat="server"/> y posiciona el mouse ahí.

5. En el cuadro de propiedades, escribe el URL que referencia a CORE-COPY.CSS, así

NOTA: esta ruta “virtual” en realidad referencia al archivo CORE-COPY.CSS almacenado en C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\<lcid>\STYLES\CORE-COPY.CSS. Es de este modo como se especifica la relación de un CSS alojado en disco con las páginas de MOSS.

6. Si cambias a la vista de diseño, verás que se refresca la pantalla, y si verificas el código, verás que la etiqueta mencionada en el paso 4, ahora luce así:

<SharePoint:CssLink runat="server" DefaultUrl="/_layouts/3082/styles/CORE-COPY.CSS"/>

7. Guarda los cambios, y aprueba el Master Page –hey! No modifiques default.master!! guarda una copia, como MyDefault.master o algo así.

8. Ahora aplica tu Master Page al sitio.

Notarás que el sitio luce exactamente igual, y esto es lógico, ya que CORE-COPY.CSS hasta este momento no ha sido modificado, y es exacto a CORE.CSS.

Lo bueno de esto es que ahora podrás modificar CORE-COPY.CSS desde el disco. Yo recomiendo hacerlo con SharePoint Designer ya que tiene una especie de IntelliSense para CSS, muy útil. De este modo, tu personalización se verá reflejada inmediatamente al salvar los cambios en CORE-COPY.CSS

Si ya abriste CORE-COPY.CSS y te diste cuenta que son mas de 1400 líneas y no entiendes nada, este post te dirá qué significa cada estilo. Heather Solomon también ha publicado una excelente guía de los estilos de CORE.CSS

Ventajas:

- Debugging rápido de estilos. Los cambios son reflejados automáticamente en el sitio.

- La implementación es soportada –recuerda que NO es soportado alterar CORE.CSS

Desventajas:

- Debes desplegar el archivo CSS en todos y cada uno de los servidores Web Front-End de la implementación

- En un escenario como este, mantener la consistencia entre versiones de un archivo alojado en disco de muchos servidores Web de Front-End puede resultar un problema

- El backup del archivo es manual y no lo incluye ninguna herramienta de backup/restore de MOSS

En conclusión, utilizar un CSS de este modo es el modo mas práctico para probar tus propios estilos rápidamente, aunque una vez terminadas las pruebas/debugging es recomendado publicarlo NO en el sistema de archivos, sino almacenarlo en la base de datos de contenido, del siguiente modo:

1. Ingresa via web a la Biblioteca de Estilos de la colección de sitios donde está tu Master Page personalizado (http://tu_sitio_moss/Style%20Library/Forms/AllItems.aspx)

2. Carga el archivo CSS personalizado –en este caso CORE-COPY.CSS. Realiza todo el proceso de protección (check-in), aprobación y publicación.

3. Ahora nuevamente abre tu sitio SharePoint desde SharePoint Designer.

4. Ve a la carpeta _catalogs/masterpage (el Master Page Gallery donde está su Master Page)

5. Abre tu Master Page (el mismo que modificaste antes para incluir tu CSS –dale chek-out y toda la historia)

6. Ubica la línea de

<SharePoint:CssLink runat="server" DefaultUrl="/_layouts/3082/styles/CORE-COPY.CSS"/>

7. Reemplázala por la siguiente:

<SharePoint:CssRegistration name="<% $SPUrl:~SiteCollection/Style Library/CORE-COPY.CSS%>" runat="server"/>

8. Salva nuevamente los cambios y aprueba tu Master Page. Notarás que la página permanece intacta con relación a los cambios que tu hayas realizado en CORE-COPY.CSS

Lo que has hecho, es utilizar otro control que te permite referenciar a CORE-COPY.CSS ya no desde el disco, sino desde la Biblioteca de Estilos de la colección de sitios, lo que quiere decir, desde la base de datos.

Ventajas:

- Despliegue unificado. Sólo necesitas realizar esto una vez. No es necesario hacerlo varias veces en caso tengas varios servidores Web de Front-End.

- El archivo está en la base de datos, de modo que está incluido en el backup/restore de una colección de sitios, mediante las diversas herramientas de MOSS.

- El control referencia a la Biblioteca de Estilos de un modo relativo, no mediante una ruta absoluta, de modo que si tu migras esta colección de sitios a otro servidor, o a una ruta distinta de la original mediante una operación de backup/restore, los estilos visuales permanecerán aplicados (en tanto el backup/restore sea de todo el contenido de toda la colección de sitios).

Desventajas:

- El debugging es lento. En caso necesites variar estilos, deberás modificar el archivo realizando todo el proceso de publicación (check-out, modificación, check-in, aprobación, publicación)

Yo diría que esta es la única desventaja, por otro lado me parece la estrategia mas recomendada para aplicar estilos visuales.

Por otro lado, esta desventaja puede ser eliminada, ya que en la misma página donde elegimos un Master Page (http://tu_sitio_moss/_Layouts/ChangeSiteMasterPage.aspx) podemos asociar un CSS alternativo, que se aplicará primero que el CSS que has asociado a tu Master Page.

Aunque este CSS también deberá estar almacenado (idealmente) en la Biblioteca de Estilos, por lo menos puedes tocarlo y no meterte con los estilos que ya definiste, por ejemplo, en CORE-COPY.CSS.

De este modo podrás poner en este CSS alternativo las mismas clases que quisieras modificar de CORE-COPY.CSS, y los cambios que realices se aplicarán, ya que el orden de la cascada es el siguiente:

Se entiende? Así tengas los mismos estilos en los tres archivos, siempre se aplicarán primero los especificados en la dirección de CSS alternativa, luego los especificados en el control de SharePoint en tu Master Page, y por último los de CORE.CSS.

Utilizar un CSS totalmente distinto

Todo lo anterior (hacer una copia de CORE.CSS) funciona a la perfección cuando partes de un Master Page basado en default.master, pero si quisieras aplicar tus propios estilos a un Master Page basado por ejemplo, en mi xMP, esto no te servirá.

Por que?! Porque a menos que las etiquetas HTML, ASP.NET y controles SharePoint de tu Master Page llamen a las mismas clases que son llamadas desde default.master hacia CORE.CSS (o mejor dicho, CORE-COPY.CSS), tendrás que definir tus propias clases y asociarlas a tu nuevo Master Page.

Ejemplo: MyDefault.master utilizando CORE-COPY.CSS

Aquí notamos que las clases llamadas son definidas en CORE-COPY.CSS y son las mismas definidas en CORE.CSS

Cuando utilices el Minimal Master Page, o el xMP, no tendrás estas referencias a clases, y a menos que las copies de, por ejemplo, default.master, de nada servirá que trabajes personalizando una copia de CORE.CSS

Es por esto, que si quieres que tu sitio luzca, por ejemplo, así

(http://www.westernaustralia.com –MOSS baby, MOSS!)

será mejor que empieces de CERO a partir de xMP y que a cada elemento en la vista de código le asocies clases creadas por ti, y que utilices un CSS creado por ti, ya no a partir de CORE.CSS, sino uno totalmente nuevo, definiendo las clases que TU crees, así

Asocias al Master Page un archivo CSS totalmente nuevo (misEstilos.CSS??), primero a modo de debugging en el disco, luego cuando hayas terminado, a la Biblioteca de Estilos. Tu archivo CSS deberá tener entonces únicamente las clases que tu definas (como .fondoBanner, por ejemplo). Por los estilos que definen las páginas administrativas, ni te preocupes (a menos claro, que quieras cambiarlos también), siempre estará CORE.CSS como “fondo” o “piso” para los estilos que no definas –lo que ocurre realmente es que las páginas administrativas, o páginas “_layouts”, normalmente no son personalizadas (no está recomendado y no sé exactamente si está soportado), de modo que tu Master Page será aplicado al sitio visible para los usuarios, mientras que las páginas administrativas siguen utilizando su Master Page por defecto (application.master), entonces realmente no tiene nada que ver una cosa con la otra.

Conclusiones

- MOSS emplea extensivamente CSS en los Master Pages que utiliza

- Existen al menos tres capas de CSS, teniendo mayor prioridad la hoja CSS alternativa, luego la(s) asociada(s) al Master Page, y por último CORE.CSS.

- No debes modificar de ningún modo CORE.CSS, nunca.

- Luego de hacer debugging y pruebas de tu CSS en disco, pásalo a la Biblioteca de estilos del sitio.

- Para personalizaciones muy avanzadas, es recomendable no basarte en default.master, sino en un Master Page base, tal como xMP, o el de Heather, y crear tus propios estilos.

Con este artículo (y algunos anteriores) concluyo una serie de artículos dedicados al Branding de MOSS. Creo que, sobre todo, este artículo y el anterior, explican de manera clara y amigable (eso espero Smile) los tips de cómo personalizar una implementación de MOSS. Como mencioné al iniciar la serie, estos tips son los que yo he venido aprendiendo desde Beta 2 y que me han permitido personalizar profundamente sitios MOSS. Adicionalmente, mucha de esta información está publicada de modo formal en MSDN y TechNet.

Referencias

Guía CSS de SharePoint (Core.css): http://www.sharepointblogs.com/jeanmarc/archive/2007/07/20/3201.aspx

CSS Reference Chart for SharePoint 2007: http://www.heathersolomon.com/content/sp07cssreference.htm

Branding SharePoint – Part 1: Designing your SharePoint Site - http://www.heathersolomon.com/blog/articles/brandsppart1.aspx

Branding SharePoint - Part 2: Creating the Design in SharePoint - http://www.heathersolomon.com/blog/articles/brandsppart2.aspx

Master Page debugging 1: Place Holders - http://www.sharepointblogs.com/jeanmarc/archive/2007/09/14/5828.aspx

Espero que sirva!

-.M.-


Posted 09-28-2007 1:04 PM by Marcel Jeanneau

Comments

Links (9/30/2007) « Steve Pietrek’s SharePoint Stuff wrote Links (9/30/2007) &laquo; Steve Pietrek&#8217;s SharePoint Stuff
on 09-30-2007 7:30 PM

Pingback from  Links (9/30/2007) &laquo; Steve Pietrek&#8217;s SharePoint Stuff

Sergio Tarrillo wrote re: Master Page debugging 2: CSS
on 01-29-2008 5:37 PM

Hola Marcel!

Buen artículo, y para que no tengas problemas con las imágenes, puedes cambiar el tema de tu blog.

Saludos,

Miguel wrote re: Master Page debugging 2: CSS
on 11-03-2008 10:40 PM

Muy buen articulo.

Saludos

Add a Comment

(required)  
(optional)
(required)  
Remember Me?
Need SharePoint Training? Attend a SharePoint Bootcamp!
Posts (c) their respective authors. Everything else (c) 2009 SharePoint Experts, Inc.