Al blog de desenvolupament de Webkit s'anuncia la implementació d'unes propietats CSS destinades a permetre transicions entre dos estats d'un element anomenat CSS Animation.
Tot i que a primer cop d'ull pot semblar un avenç, a parer meu fa tremolar els fonaments de la famosa separació de capes, és a dir:
- (X)HTML, per estructurar i marcar el document
- CSS, per formatejar la presentació del document
- Javascript per afegir funcionalitat extra
Si es proporciona una via per afegir transicions des del CSS en comptes de fer-ho des de la capa natural (Javascript) en quin punt ens hem d'aturar? Creixerà la necessitat d'afegir un control del flux amb condicions, bucles, etc.? No en tinc cap dubte.
Aquest tipus d'iniciatives són llamineres perquè aparentment semblen fer assequible a profans de la programació (Javascript en aquest cas) uns efectes que abans no podien abarcar però, abans de “fer-ho fàcil en CSS” mesclant capes valdria la pena considerar “fer-ho fàcil en Javascript” (deixant fora de debat si és o no fàcil actualment).
En resum, crec que és un error greu per part dels desenvolupadors de Webkit aquest enfoc ja que no aporten res veritablement nou.
Comentaris
Comentat per Wítiza el 13/11/07
Tens tota la raó, barrejar les capes és com el problema del calb que quan es renta al matí no sap on se li acaba la cara :) Com deia fa tants anys Dijkstra "tenim una innata inhabilitat per tractar la complexitat" i per tant ens cal l'abstracció per tractar-la, que en aquest cas es tradueix en separar les capes i donar al Cèsar que és del Cèsar i al Dau és que és del Dau.
Comentat per Eric Mora el 21/12/07
Penso que no cal alarmar-se, la web s'està pujat una capa en determinats dominis on l'accessibilitat no és un factor determinat (per exemple perque no hagin d'utilitzar la web persones sense javascript).
Amb l'aparició d'ajax, la lògica de control de les interfícies que s'estava realitzant en el servidor (per exemple: Selects per a seleccionar pais i provincia, el select de provincia tindrà només les provincies del pais) ha pujat de nivell.
Quan s'aplica Ajax per carregar aquestes dades la lògica de peticions i pintat s'està passant a JavaScript part de la lògica del servidor.
No creus que, si apliquem JavaScript per això en determinats dominis on l'accessibilitat pot ser menor per definició (Aplicacions Web, gestors de contingut, etc..) el fet que les capes apareguin i desapareguin, que les capes es moguin, etc... forma part de la presentació del document? Realment crec que va més enllà que fer assequibles assequible a profans de la programació (Javascript en aquest cas) uns efectes que abans no podien abarcar. Penso que independentment del que he comentat aquests efectes formen part de la presentació.
Igual que formen part de la presentació posar un fons de color vermell o pintar un text de blau, forma part de la presentació fer que aquest text es posi en vermell passats 15 segons i el fons en blau passats 18 segons.
Comentat per are el 21/12/07
Crec que vas errat. Javascript i CSS estan al mateix nivell. Javascript no és inaccessible de per sí i CSS no és accessible de per sí. Amb els dos es poden fer les coses bé o malament.
Sobre AJAX: Usar transferència de dades asíncrona pot estar bé si el cas ho demana però compte. A dia d'avui (2007-12-21) AJAX no és accessible i crea grans problemes d'accés.
Segueixo pensant que no és part de la presentació. És part del comportament de l'aplicació web, de la pàgina web o del que sigui web. No canvia cap paradigma.
I a més obvies un dels punts clau: creus que dotar CSS d'una lògica primitiva com la proposada és suficient? Jo crec que no.
Comentat per Eric Mora el 22/12/07
Discrepo!!! jejejejeje Creus que és bo tenir dues tecnologies al mateix nivell? Si JavaScript está començant a treballar amb la transferència de dades asíncrona (de fet des del 1998 amb MSRS - Microsoft's Remote Scripting), no creus que hi ha d'haver una divisió de capes que hauria d'estar dins del mateix JavaScript i deixar com una capa d'acces al negossi (no bloquejant a l'accessibilitat) la capa AJAX i una capa de gestio d'events d'entrada?
El tema es que aquesta gestió d'events es facilitaria amb el recolsament i ús de CSS. Si tinguessim suport de CSS per eliminar de JavaScript alguns temes de DHTML i estandaritzar-ne l'ús, això agilitzaria molt els desenvolupaments i permetria anar introduint noves necesitats fent créixer l'abast de la tecnologia.
Et posaré un exemple de com podria facilitar això des del meu punt de vista: - L'usuari clicka a un botó i apareix una capa flotant amb un efecte fade-on a dreta de la pantalla.
Realment el que ha passat és que la capa de gestió d'events de Java Script ha canviat la classe (atribut class) de la capa i aquesta classe té incorporat un efecte fade on d'entrada. Aquest efecte d'entrada pertany al disseny de la web i per tant hauria d'estar dins de les CSS i no dins de JavaScript.
Coincideixo amb tu que aquesta capa de lògica primitiva no és suficient, potser s'haurien de dotar aquestes transicions d'events com per exemple fer que quan es carrega la classe a la etiqueta (ja sigui des d'una funcio JS o des de que es carrega la plana) faci una acció i quan la etiqueta despareix en faci una altre, però per alguna cosa s'escomença, penso que és un pas important que podria dotar les planes web fetes en css d'un major espectacularitat de presentació.
Comentat per are el 22/12/07
Ui, això es dispersa: Quan dic «al mateix nivell» dic: “al mateix nivell de dependència en relació a l'accessibilitat”, per desmuntar-te l'afirmació, sense fonaments, de que posar quelcom al CSS ho fa de per sí més accessible i, no posar-ho al JS tb. O sigui:
L'accessibilitat aquí no millora ni desmillora.
Segon, quan dius: «deixar com una capa d'acces al negossi (no bloquejant a l'accessibilitat) la capa AJAX» em vols explicar què vols dir? perquè AJAX (suposo que vols dir HttpXMLRequest) com ja he dit abans, és un bloquejant real de l'accessibilitat a dia d'avui. En un futur millorarà quan millorin les ajudes tècniques pertinents.
A més a més, m'estas dient que penses que posar la teva lògica de negoci en una tecnologia de client i prescindible és bona idea? Se m'acudeix que com a poc tens un forat de seguretat que no el voldria en un negoci meu.
Tercer, i tornant a l'origen del post: la presentació (CSS) descriu estats estàtics i així s'hauria d'ampliar. Qualsevol transició no té pq haver d'entrar a CSS. Javascript ja ho fa molt bé.
Necessites widgets estandaritzats i prefets? d'acord, tots ho volem. Però no és CSS qui ha de permetre que li declaris tot això.
Mira't el projecte WAI-ARIA.
I per últim, quan dius «podria dotar les planes web fetes en css d'un major espectacularitat de presentació»: què et permetria fer que ara no pots amb Javascript i CSS (cada tecnologia fent la seva feina) ? La resposta és ràpida: res. Senzillament m'estas dient de canviar-li el nom al Javascript i dir-li CSS, és això? pq sinó no t'entenc ni entenc el raonament.
Comentat per Eric Mora el 26/12/07
AJAX és bloquejant en quan a accessibilitat depenent del nivell d'accessibilitat que necessiti l'aplicació que s'està fent. Suposo que coincidiras que l'accessibilitat no és un terme boleà: té nivells d'accessibilitat i una aplicació pot estar en un o altre nivell.
Jo no dic que posem la logica de negoci a JavaScript, això seia molt xungo, si no que des de JavaScript accedim a la capa de negoci del servidor. Deixant aquest tema apart i tornant al quit de la questió: Llavors estem d'acord que els widgets estandaritzats i prefets estarien bé, no creus que això pertany a la capa de disseny? Realment no és interacció, la interacció la hauria de controlar JS i el disseny CSS.
A la teva pregunta què et permetria fer que ara no pots amb Javascript i CSS (cada tecnologia fent la seva feina) ? A priori se m'acut desenvolupar de manera ràpida una web que tingués aquests efectes. A la teva pregunta senzillament m'estas dient de canviar-li el nom al Javascript i dir-li CSS, és això? Evidentment, la resposta es no! Simplement estic dient que s'haurien de passar els efectes gràfics de disseny (fade-on, etc..) que es controlen des de JS a CSS. I deixar per JS el tema de gestió d'events, etc...
Comentat per are el 26/12/07
L'accessibilitat d'una eina no és booleana, però tampoc és difusa. Si pots garantir que tothom pot usar l'eina (aconseguir l'objectiu): és accessible. Si no, no ho és.
Sobre nivells, hi ha un acord via W3C d'establir tres nivells d'accessibilitat. AJAX a dia d'avui NO compleix el nivell més primitiu degut a que algunes ajudes tècniques (molt exteses) no són capaces d'usar-lo correctament.
Els widgets estandaritzats sí, estem d'acord.
No, no crec que sigui capa de disseny establir el comportament d'un fade.
Això no és cert, no seria més ràpid. Estas canviant una nomenclatura per una altre. Seria tan ràpid com usar una biblioteca determinada que coneguis. I molt més limitant ja que CSS no et permetria gaire.
Comentat per Eric Mora el 27/12/07
Estic d'acord amb casi tot el que dius.
Jo penso que el fet que una capa (per exemple) tingui un efecte de fade en un determinat moment és clarament un tema de disseny igual que el color de fons que ha de portar la mateixa.
El tema de la rapidesa de desenvolupament dependrà de la magnitud del problema.
Si ho hem de fer a una capa d'una pantalla, ens serà igual. Pero si el problema se'ns repeteix en diferents capes de diferents pantalles, a priori, si apliques l'efecte de fade-on capa a capa des de JavaScript, serà més llarc de fer que si apliques l'efecte a una classe css que tenen totes les capes que per disseny han d'apareixer fent un fade-on.