text-stroke (textos con contorno): 4 vías CSS 26.6.17
Diferentes métodos (cuatro) con sus pros y contras para dibujar un contorno o perfil a los textos con CSS.
text-stroke (textos con contorno): 4 vías CSS
Un efecto clásico con los textos es añadirles un contorno o perfil para resaltarlos del fondo sobre el que se muestra. En entornos gráficos no suele representar ningún problema. Otro tema es hacer lo mismo con los textos en la web con unas mínimas garantías.
Hasta no hace tanto no era tan fácil ya que ahí fuera, en las especificaciones de CSS, no está contemplada esta posibilidad. Aunque formas hay. Y no una o dos. Hasta cuatro he encontrado yo. Cada una con sus pros y sus contras. Vamos con ellas.
Contorno de texto con -webkit-text-stroke
La propuesta de propiedad CSS -webkit-text-stroke no está recogida en ningún documento del W3c. Es un yo me lo guiso, yo me lo como
de Chrome que durante mucho tiempo sólo fue soportada por su navegador.
Recientemente un grupo importante de navegadores, como Firefox 52+, Edge 14+, Opera 46+, Safari..., decidieron incluirla en su core pero manteniendo el prefijo -webkit- y sólo bajo el prefijo -webkit-. Para más info: caniuse.com
La propiedad -webkit-text-stroke realmente es la forma acortada de otras dos:
- -webkit-text-stroke-color
- -webkit-text-stroke-width
y complementada con -webkit-text-fill-color que de declararse reescribe la propiedad color con independencia del orden en que estuviesen declaradas.
.text-stroke {
-webkit-text-stroke-color: #000;
-webkit-text-stroke-width: 2px;
/* shorthand */
-webkit-text-stroke: 2px #000;
/* color del texto */
-webkit-text-fill-color: #fff;
}
See the Pen gRXYwB by Kseso (@Kseso) on CodePen.
La única precaución a tener presente es que un valor elevado en -webkit-text-stroke-width (elevado en función del tamaño del texto font-size y font-weight) hará ilegible el texto.
Contorno de texto con text-shadow
Un sustituto de -webkit-text-stroke clásico durante todo este tiempo ha sido usar la propiedad CSS text-shadow para emularla.
.text-shadow {
text-shadow:
0 0 1px #000,
-1px -1px 0 #000,
1px -1px 0 #000,
-1px 1px 0 #000,
1px 1px 0 #000;
}
See the Pen WOXedN by Kseso (@Kseso) on CodePen.
Al usar esta vía hay que tener presente una particularidad: que la sombra de los textos no se crea y dibuja a partir del límite de cada carácter y hacia fuera. También "rellena" el propio carácter. Esto se pone de manifiesto al usar un color con transparencia (rgba por ejemplo) o un texto transparente (color: transparent).
Se podría pensarse en recurrir a la propiedad no estándar -webkit-background-clip: text para cubrirse, en parte, ya que los navegadores Chrome, Firefox y Safary ya la soportan con prefijo obligado. Pero no. La sombra cubre el interior de los caracteres.
Así que no es posible usar esta forma para mostrar el texto sólo con el contorno (sin color de relleno).
Contorno de texto con filter: drop-shadow()
Esta vía con el filtro drop-shadow
no deja de ser una variante del anterior con box-shadow.
Sin embargo como la sombra se "difumina" conviene repetir el valor drop-shadow() varias veces para asegurarse que el contorno es nítido y resalta lo suficiente.
.drop-shadow {
filter: drop-shadow(0 0 1px #000)
drop-shadow(1px 1px 0 #000)
drop-shadow(-1px 1px 0 #000)
drop-shadow(1px -1px 0 #000);
}
See the Pen qjVBmL by Kseso (@Kseso) on CodePen.
AL utilizar filter: drop-shadow() hemos de tener presente las particularidades de los filtros. En este caso es obligado usar un color para el texto (no podemos dejarlo transparente) y no asignar un fondo al elemento textual.
En el primer caso (fondo transparente) no se genera sombra y por lo tanto el texto se vuelve invisible (equivalente a un visibility: hidden). Y en el segundo (fondo al elemento) el filtro aplica al elemento (contornea la caja) y en caso de que el fondo tenga algún grado de opacidad (rgba) lo tinta del color declarado en el filtro.
A favor de text-shadow y/o drop-shadow está que podemos jugar con el desfase y color en los valores de las sombras para lograr otros efectos en el contorno de los textos. Ni te enlazo ninguno porque son de sobra conocidos.
Contorno de texto con el elemento `text´ del SVG
La última vía para dar contornear un texto es utilizar el elemento text propio del SVG.
A todos los efectos es similar a usar la propiedad -webkit-text-stroke.
<h1> <svg viewBox="0 0 850 80"> <text x='5' y="65">soy Kseso, esto EsCSS</text> </svg> </h1>
Al tratar con un elemento propio del SVG podemos recurrir a las propiedades que aplican a ellos. Como fill, stroke y stroke-width.
Las dificultades vendrán en este caso por el control del texto contenido por <text /> características de este elemento. Pero las ventajas, innegables, que estaremos trabajando con SVG y todo lo que ello permite.
Hay gran cantidad de información sobre el elemento SVG text. SVG text element por Jakob Jenkov . Una pequeña guía para aproximarse a él es la serie de artículos de Steven Bradley SVG Text On A Path y el de Chris Coyier SVG `text` and Small, Scalable, Accessible Typographic Designs. Por ejemplo.
Las cuatro vías para contornear textos
Para finalizar un pen donde podrás ver y jugar con estas cuatro formas de crear contornos a los textos y los efectos al combinarlos con diferentes propiedades y/o valores que advertía en cada uno de ellos.
See the Pen text-stroke: 4 ways by Kseso (@Kseso) on CodePen.
 con sus pros y contras para dibujar un contorno o perfil a los textos con CSS.){kind=link}
Kseso
the obCSServer ᛯ Ramajero Argonauta, Enredique Amanuense de CSS.#impoCSSible inside
Dicen que, en español, EsCss es el mejor blog de CSS. Posíblemente exageren.
@Kseso EsCss Kseso
Es curioso, text-stroke no es la única propiedad que Firefox soporta con el prefijo -webkit-. Usando el autocompletado del inspector, veo que acepta propiedades como -webkit-animation, -webkit-transition, -webkit-border-radius, -webkit-box-shadow, -webkit-box-sizing o -webkit-user-select, además de las propias de Firefox, algunas solo con el prefijo -moz- y otras también sin prefijos.
ResponderEliminar¿Por qué habrán decidido añadir los prefijos de otro navegador? Y ya puestos, ¿no habría sido más práctico usar des del principio un único prefijo del tipo -beta-propiedad para marcar que la propiedad está en desarrollo?
Hola Jorge
EliminarSí y no es de ahora. Hace poco más de un año que Firefox hizo el anuncio de soporte a algunas -webkit-*.
Comenté algo en el blog (CSS al día. Novedades) al mencionar las novedades de FF 49.
Aquí un artículo donde se explayan algo más al respecto: Firefox will support non-standard CSS for WebKit compatibility
Personalmente no me gusta.
Un saludo
A mí tampoco me gusta mucho, pero si lo critico van a acusarme de una doble moral.
EliminarSé que no es el tema, pero ya que lo mencionan, coincido en que deberían poner un prefijo del tipo 'beta-' y que no haga referencia a otros desarrolladores, porque si bien 'webkit-' no es realmente de Chrome, siempre se lo asocia a Google. En realidad si van a usar prefijos, yo insistí en que funcionaran como hacks, para separar una propiedad en un navegador específico, pero no tiene demasiada utilidad cuando se respeta una norma (tipo estándar).
El punto es que ya sabíamos que esto iba a pasar, lo debatimos hace años cuando ni sabíamos que Chrome iba a aparecer. Si un navegador toma ventaja de su desarrollo, los demás debían "copiar" sus ventajas para no quedar atrás, sin esperar a que al fin le aprobaran los inventos de manera "oficial". Así funciona el negocio.
Mozilla se negó durante lustros a hacer eso, lo que llevó a sus navegadores a dejar un buen lugar de mercado a Internet Explorer y después a Chrome (que hoy es el más popular). A nosotros nos obligó a inventar códigos extrañísimos para emular los efectos "maravillosos" de los DirectX de MS, solamente para hacer esos diseños tan originales compatibles con Firefox (o mejor dicho, "simulables"). Para mi ingenua imaginación, eso era una forma de promover el uso de un navegador fuera del alcance de empresas poco respetuosas de los usuarios.
Pero si Firefox ahora acepta prefijos de otros desarrolladores y los interpreta correctamente, nos está ahorrando un montón de trabajo.
Lo de seguir manteniendo prefijos (propios y ajenos) en reglas que evidentemente ya no lo necesitan, es un ejemplo claro de que se prioriza la compatibilidad hasta con los documentos viejos, no actualizados.
Saludos. Y gracias por el artículo.
Sí, sí, Furoya
EliminarTienes toda la razón que es un viejo tema de debate. No sólo en el blog ;-) también en la red.
Ya ni me acordaba de este post.
Es, nada menos, que de los primeros del blog: Febrero de 2012.
¡Qué viejos somos, compañero!