Hace 2 años | Por --682766-- a genbeta.com
Publicado hace 2 años por --682766-- a genbeta.com

Las hojas de estilo en cascada (más conocidas como CSS) son el lenguaje de diseño (y una de las tres grandes bases, junto a HTML y JavaScript) de la World Wide Web, el lenguaje que permite a los desarrolladores dar formato a las páginas web aplicándoles estilos que alteran aspectos como colores, tipografías o espaciados. Y ahora, este lenguaje nacido en 1996 está quizá a punto de experimentar uno de los mayores cambios de su historia. Según publica Miriam Suzanne, miembro del CSS Working Group del W3C

Comentarios

ctrl_alt_del

Y muy potente y flexible

leporcine

#3 es que ese ejemplo que pones está mal maquetado.

kwisatz_haderach

#9 Creo que precisamente esa es la broma y cualquiera que haya tocado el CSS lo siente con verlo.
El css es super cómodo para algunas cosas, pero luego te hace cada descuadre con las justificaciones y los margenes...

EmuAGR

#15 El problema está en las propiedades por defecto de los elementos HTML, que div es bloque y span en línea. Ese es fácil, pero otros no tanto, y no siempre te viene bien dado el HTML.

Relator

#19 goto #15

saqueador

#19 Señal de que no has vivido la época del ie6.

EmuAGR

#48 La he vivido, por supuesto. Prefiero olvidar. lol

saqueador

#84 Era para #15, se me fue

leporcine

#15 a eso me refería, hay propiedades para que una palabra salte de línea, y que crezca en vertical. Con lo que ese ejemplo se vería perfectamente.

D

#15 yo por ejemplo, le digo que me ponga una lavadora, y nunca falla... roll

g

#13 yo odiaba hacer nada en css hasta que descubrí flexbox. Alinear cosas verticalmente like a Boss.

montaycabe

#13 hay cosas, como por ejemplo por qué margin-top hace esas cosas, que solo se transmiten de mago css a mago css cada generacion

boria

#42 sin duda, pero es aconsejable que cada elemento aplique el margen a su sucesor, evitas muchos problemas.

D

#42 que se lo expliquen al overflow :hidden...

fugaz

#3 A lo mejor es justo lo que querías hacer.

PacoJones

#3 ésta broma es muy del 2008

montaycabe

#6 si tienes un selector kilométrico es que estás haciendo las cosas mal y esto no te va a ayudar.
No entiendo tanto revuelo por la tontería del nesting cuando no aporta absolutamente ninguna funcionalidad

D

#12 aporta encapsulamiento y mejor legibilidad.

montaycabe

#28 #17 #20 llevo maquetando desde antes que existiera el css, cuando el . Si tu css es tan largo y complejo que necesitas nesting, necesitas, si o si, sass y ni siquiera ves nunca el css compilado. Y esto no aporta ninguna capacidad nueva a css, solo legibilidad a quien no la necesita, porque ya usa sass

F

#37 Que sass ya aporte esto no quiere decir que css no pueda adoptarlo. Qué tonteria.

De hecho, es habitual esta secuencia de pasos. Ya pasa con muchos frameworks, que van por delante del propio lenguaje de programación y es éste el que termina integrando como funciones nativas algunas que hasta el momento solo ofrecían los frameworks/librerías.

Y no es que mi CSS sea especialmente largo, es que es una buena práctica anidarlo por razones que ya se han comentado más arriba. Y que es más elegante, que leches.

montaycabe

#50 No, anidar selectores no es una buena practica, es una mala practica, de hecho, y no se recomienda. Lo que ha comentado el compañero sobre el a:hover, visited, etc. se podria haber arreglado de forma mucho mas logica con una shorthand property como pasa con background, pero no se ha hecho eso.
¿Esta bien? Pues bueno, si, esta bien, mejor que no tenerlo. ¿Le mejora la experiencia de usuario o la vida a alguien? pues no, la verdad es que realmente no, o a muy pocos. E incita a las malas practicas, como anidar selectores.

D

#52 si, es una buena práctica si se hace correctamente, de hecho es la que permite una mejor modularizacion.

montaycabe

#64 Que no. Añades especificidad sin necesidad, por eso existe BEM, para no hacer .bloque .elemento que luego no podrias cambiar por ejemplo añadiendo una clase .utility-color-blue a no ser que le metas un !important.
Con BEM haces .bloque__elemento y ademas si luego desaparece .bloque sabes a la primera que .bloque__elemento te la puedes cargar sin problemas.
Que sea comodo, ok, que sea util en determinadas circunstancias, ok, que no hay que ser taliban, ok, pero no es una buena practica añadir especificidad anidando si hay otra forma de hacerlo,

D

#67 que tendra que ver la especificidad, con el anidamiento utilizado correctamente...

Se gana en legibilidad y en encapsulamiento.

montaycabe

#68 joer tio, empiezo a sospechar que no sabes lo que es la especificidad y sus problemas. El anidamiento es precisamente especificidad, son equivalentes.
.clasea .claseb
gana a
.clasec
Si metes 3 niveles, acabaras poniendo !important por todas partes. Y luego ya, el apocalipsis. No estas encapsulando nada, css no funciona asi.
Ni siquiera se gana mucho en legibilidad porque en un css muy largo, al estar cada clase precedida por su clase padre, no tienes que "subir el scroll" para ver al padre y saber donde estas. Pero volvemos a lo mismo, si usas tanto nesting que tienes un problema con la legibilidad, tienes problemas mucho mas importantes seguro. Ya te digo que un css serio y bien hecho está hecho en sass* y el anidamiento lo usa mayormente para generar los selectores BEM, no para anidar el css. Si la arquitectura css está bien hecha, el anidamiento de selectores necesario será minimo o nulo. Hablo siempre de proyectos grandes, para una chapuza pequeña usas lo que te resulta mas comodo.

* Por ejemplo nadie se imagina un css serio sin imports de css parciales, y nadie que se tome en serio su trabajo se imagina hacer eso con css nativo para lastrar el arranque de la pagina.

d

#71 creo que te confundes con el anidamiento de sass scss, donde declaras el "padre" solo una vez. Al final anidamiento siempre hay y con estos preprocesadores queda más elegante.

Benzo

#52 Por curiosidad, ¿Cómo es una shorthand property para un enlace?

montaycabe

#70 No te entiendo. Una una shorthand property es por ejemplo poner
background: red;
que comprende background-size, background-color, background-image, etc. y las chafa a todas.
O border: solid 3px red, que es lo mismo que poner
border-top-color:red, border-left-color, border-top-width, border-left-width, etc etc etc.

con lo que digo de la a, se deberia poder hacer algo como
a
y chafara el resto de propiedades a-hover, a-visited, a-active, etc. o bien las puedieras setear por separado

EmuAGR

#12 Poco CSS has hecho tú.
a:focus
a:active
a:visited
a span.highlighted

Todo eso puede estar dentro de "a " ordenadito. Ahora pon eso dentro de un div que también tiene párrafos, imágenes... con estilo especial propio, tan tonto como para poner colores específicos. Y si quieres hacer una animación ya ni te cuento.

D

#20 Él lo dice porque sí necesitas anidar puedes usar SASS

Como si la mejora de una herramienta no aportara valor porque existen otras.

montaycabe

#40 si necesitas anidar a saco, ya empezamos mal. Con BEM por ejemplo no se anida, con atómic css tampoco. Para cuando anidar es una ventaja, ya han pasado muchas cosas que te "obligan" a usar sass.
Además, la gente tiende a anidar porque parece que queda más ordenadito, y reflejan la estructura del html en el anidamiento del css y eso es un error muy grave.

D

#43 la nomenclatura BEM es una parida monumental en varios sentidos. Y el atomic design, se puede plantear con anidamientos y mixins propios de sass.

Lo que tenían que haber hecho los socios estos es llevarse scss (sass) al estandar CSS. Con los@import y toda la pesca.

Y lo del PostCss para anidar, NO gracias...

montaycabe

#66 No he dicho atomic design sino atomic css, es una cosa muy distinta, solo se usan utility clases, es feo como el demonio y me repugna, pero tiene su sentido en sus circunstancias, lo usaba yahoo.
Es esto, por ejemplo:
https://acss.io/

BEM es una parida para ti y para mi , para proyectos pequeños, llena de mierda el html, es un coñazo pensar una nomenclatura correcta, pero si tienes a 300 frontenders trabajando en el mismo proyecto, una web de un banco, por ejemplo, que ademas van entrando y saliendo, tienes que acabar usandolo para no terminar a navajazos.

D

#69 vale, atomic CSS, como lo hace tailwind, me gusta tanto como el BEM...

Quein invento el BEM odia a los frontend, y la simplicidad. Y no se justifica a mi modo ver por la razones que esgrimes (que se que suelen esgrimir en gral).

Desde mi punto de vista hay q ser minimalista, utilizar clases solo donde son necesarias, principalmente como referencia del primer nivel del componente o bloque. Y por supuesto haciendo un nesting simple y coherente.

No hay nada mas, creo q eso es todo lo necesario. Ni nomenclaturas forzadas y redundantes, ni utilizar clases en lo que pareciera un sustito de una de las peores practicas en CSS (ponerlas inline) como hace a cierta manera tailwind.

Ah, y utilizar los import para modularizar..., y claro, todo esto se hace con Scss.

Otra cosa que no cabe en la cabeza de BEM es que no se anida, con lo que la lectura rápida y visual del código es una patada en el culo.

montaycabe

#40 de hecho, es una ventaja usar sass aunque solo escribas css plano porque por ejemplo te avisa de los errores de sintaxis o estructura, cosa que el browser no hace y te puede volver loco. Si el css no vale, no compila

F

#12 La legibilidad y mantenimiento del código están por encima del rendimiento. Y más aún en CSS, donde esto apenas se aprecia.

boria

#12 si aplicas BEM viene de perlas

montaycabe

#54 no, no sirve, no sirve para componer nombres de selectores como en sass, y en bem no se anida

boria

#57 Tienes razón, pensaba en esto:
.block
}
}

Pero parece ser que no se podrá usar & para generar la clase como en sass.
En ese caso facilitan escribir con más especificidad

C

#12 Puede tener sus usos. Suponte que has creado componentes pequeños (botones, pequeños widgets) que cambian ligeramente según donde vayan metidos. puedes tener una serie de reglas
.contextoN
.....
.widgetn
}
Para las "pequeñas" diferencias. Es lo mismo que añadir la clase padre a cada uno, pero la simple comodidad evita que por ejemplo se dispersen por el fichero, se intercalen los contextos... Tiende a que la gente las junte cuando añada una nueva porque ya tienen su sitio.

También ahorra algo de CSS. Que de normal puede parecer ridículo pero cuando te peleas con AMP y su límite de 75kb (antes eran 50) puede ser de ayuda.
Por último también hay contextos en los que estás obligado a basarte en la estructura del html aunque sea una pésima práctica, por ejemplo si no tienes control sobre él. Piensa en un CMS en el que inyectas HTML desde BBDD y no se quiere obligar a los redactores a que metan clases css (o el html se convierte directamente de otro formato como word) y únicamente hay unas convenciones básicas sobre la estructura de dicho html.

Como todo, no es la panacea pero ayuda. Que se puede hacer en sass? sí, pero si es nativo mejor, se puede añadir a cualquier cosa sin incrementar el stack de herramientas, tienes control sobre el css generado (que con sass se puede disparar)...

D

#5 si, pereza mortal, solo lo comentaba, por no desmerecer al CSS, que luego se ve cada cosa en equipos grandes.

armadilloamarillo

#4 "Es posible hacer un Turing Complete" ha sonado a otra cosa.

pawer13

#4
no tiene que Turing completo para ser un lenguaje. Ni siquiera tiene que serlo para ser un lenguaje de programación si no es de propósito general.

El html es un lenguaje para marcar textos y no es Turing completo, no tiene bucles ni condiciones.

D

#61 Si nos ponemos maquiavélicos con el HTML hacer un Turing Complete es posible mediante scrolls y anchors. Francamente decir que el HTML sirve para marcar textos no es realista, más cuando cada día otros lenguajes replican su concepto. Por cierto, ahora que lo pienso si tiene condicionales, como noscript o cualquier alternativa de rutas de recursos.

Realmente la pregunta de si es o no un lenguaje de programación me parece absurda. A mi me da que está motivada por la comunidad de programadores intentando desmerecer a todos los "no programadores" que hacen sus pinitos con el HTML.

D

#1 css es un lenguaje, de diseño, pero un lenguaje...

alexwing

#21 y mi lavadora es programable, eso no la conviente en un lenguaje de programación.

D

#22 jodo petaca

Donpenerecto

#1 otro que se cree que sabe y no sabe nada

alexwing

#41 llevo más de 20 años programando me vas a decir tu si se o no.

adrigm

#49 y yo. Y no quita que te has colado diciendo que css no es un lenguaje.

alexwing

#58 me refería a lenguaje de programación, que conste que CSS no me disgusta, se me da bien, tengo hasta un mod en modo oscuro para meneame que usan algunos usuarios.

https://userstyles.org/styles/138352/dark-mename

selina_kyle

#49 falacia de autoridad era esa no?

Donpenerecto

#49 yo conozco algunos que llevan 30 años intentando y todavía no han aprendido.

Omóplato

#1 Sí, un lenguaje de diseño para definir hojas de estilos. Como también lo sería XSL. Ni en el titular, ni en la entradilla, ni en el artículo se define a CSS como lenguaje de programación.

Por otra parte, odio CSS. A muerte.

PacoJones

#56 ya se han quedado obsoletos, están en modo legacy

z

#81 Ahora hay tres alternativas posibles, a ver cuál termina imponiéndose.

EmuAGR

#82 Hace 15 minutos que una de ellas ha dejado de recibir soporte, otra ha sacado una versión incompatible con la anterior que obligará a refactorizar media aplicación y la tercera tiene un bug en una dependencia y el npm peta hoy.

editado:
Acabo de leer que la segunda tiene un bug crítico de seguridad y como no migres a la nueva versión estás expuesto a XSS de script kiddie.

yocaminoapata

Css nesting aka scss

montaycabe

#56 y son el futuro.

PacoJones

#90 me da pereza contestarte, seguro que eres la alegría de la huerta en el trabajo.

PacoJones

#59 Además que no lo cataremos hasta dentro de 2 o 3 años y con suerte

PacoJones

Bienvenido sea

zuul

#35 Aunque un pelin tarde.

PacoJones

#87 Aparte que sobra tu falta de respeto, no tienes mucha de idea de CSS, no?
En la norma oficial está además aceptado con el nombre de variable https://www.w3.org/TR/css-variables-1/

D

#89 Yo también puedo llamar a mi perro "variable", eso no lo convierte en una variable.
¿De verdad tenéis una carrera de informática? Si no sabéis lo que es una variable y tenéis la carrera mal asunto, otra cosa es que seáis FP o seáis de cursos de programación. Pero no, lo que en CSS se llaman variables no son variables, como ya he mencionado anteriormente.

MoussaZy

Sería interesante ver si viene a remplazar los preprocesadores css(sass,less, stylus...) o es para convivir juntos.

montaycabe

#7 esto no sirve para nada

D

Gopher + Gemini > Web.

D

Es un pseudo lenguaje. No tiene variables.

D

#18 Espero que seas FP y no un hinjeniero de informática, porque eso que has puesto es un mero typedef, o un define, vamos., una definición de un identificador, o si apuras una constante, pero no una variable. Por mucho que ponga luego var(), no deja de ser una "sustución" CC: #34

PacoJones

#11 va a ser que si tiene

Q

Algo es algo .. pero los pre-procesadores + las metologias (como BEM SMACSS ITCSS ..etc) obtienes mejor juego y es mas fácil todo.

D

#25 Y con los preprocesadores, la carga del nesting no termina en el navegador. Mucho van a tener que optimizar el tema para que salga a cuenta, sino va a empeorar tiempos.

Z

Me cuelo aquí para que me deis consejos para empezar el mundo de la programación...por donde empiezo más que nada, conocimientos básicos de informática y de programación cero

D

#29 En lo referente a programación web, tienes frontend (la parte visual, la parte que se ejecuta en tu navegador, acciones, etc) y tienes el backend (la parte más lógica, el motor, trabajar datos, etc).

Hay quien elige un lado u otro (hay full stack, que tocan todo, pero para mi no existen). Una vez eliges un camino puedes mirar los lenguajes más usados. En frontend tienes HTML y CSS para definir la estructura de la página y cómo se ve, y JavaScript para cosas más dinámicas (algunas sencillas como clicks pero puedes llegar a montar un backend en JavaScript). En backend tienes Python, Ruby, PHP (el mejor, haters), etc. Y muchos más.

La programación comparte conceptos comunes en los lenguajes, como un idioma hablado. Yo que tú me miraría videos en YouTube para esas bases comunes y luego picotearía para encontrar la parte que te tire más, y luego me centraría en eso. Pero da igual qué elijas, siempre vas aprendiendo cosas y ampliando tu área de confort. Y para eso tiene que gustarte, porque es renovación constante

No sé si es lo que preguntabas o me he colado. Cualquier duda pregunta sin miedo.

D

#32 Perdón por incordiar, ¿pero qué te hace pensar que los full stack no existen? Lo pregunto de verdad.

Y para muestra, un botón. En mi actual empresa me contrataron para la página web (fullstack), no solo me toca mantener el UI/UX (desde los colores al grid-gap para el Layout) sino que además me he tenido que montar un sistema CRUD que se sincronice con nuestra plataforma de E-commerce, hacer varias llamadas en Graphql, convertir los datos a lo que yo quiero, meterlos en la base de datos y añadir nuevos campos que no son nativos. Añádele que como usamos AWS he tenido que montar 4 o 5 instancias EC2, varias páginas estáticas temporales con S3+Cloudflare, una docena de Lambdas, he ensamblado un sistema operativo basado en Debian minimal con entorno gráfico que ocupa 2GiB y al instalar expande las particiones hasta 480GiB para meter en infinitos mini ordenadores (Intel NUCs, vamos por los 40 desde que empezó el verano). Los lenguajes en que me muevo en el día a día son Typescript, Python y Bash (el cronjob para retroactivamente actualizar los NUCs corre cada hora y voy por las 1200 lineas).

Eso si, yo estoy para poner en la realidad lo que un diseñador gráfico mete en un papel (es que ni mobile first entienden).

Si a eso no lo llamas fullstack agradecería que me dieras una mejor nomenclatura.

P.S. No pretendo agraviarte, estoy de acuerdo con todo tu comentario (incluso con el PHP que es con lo que empecé hace 20 años cuando me empezaron a salir pelos) pero lo del fullstack me ha tocado un poco la fibra.

D

#38 Jajaja, precisamente lo digo porque mosquea a los full stack.

Yo también vengo de una situación similar. Tocaba mucho PHP, frontend y hasta diseño. Pero con el paso del tiempo, se ramificó todo tanto que es difícil mantener un equilibrio trabajo/ocio si quieres abarcar todo. Tarde o temprano te lastra intentar estar al día con todo.

Aparte de que yo no iría a un zapatero que también hace copias de llaves. O una cosa o la otra, pero no juguemos a ser Dios.

F

#47 Se puede ser fullstack (yo también lo era) y no tener que estar a la última en todo. Especialmente en lo que al frontend se refiere, que es una casa de putas.

D

#51 En el tiempo que has tardado en escribir ese comentario han salido dos frameworks de JavaScript que lo cambian todo.

u

#29 css no es lenguaje de programación, es más bien un lenguaje de estilo

japeto

#36 Falso.

D

Todo lo que tenga que ver con WEB mola y apesta a partes iguales.