Discussion :

[Hinault Romaric]

Le Web bientôt doté d’un nouveau langage ?
CAS s’inspire du CSS pour proposer une définition des attributs des balises HTML dans une feuille


Tab Atkins Jr, un représentant de Google au sein du W3C (World Wide Web Consortium) vient de proposer à l’organisme un nouveau langage de script pour normalisation.

Le langage CAS pour Cascading Attribute Sheets s’inspire grandement du CSS (Cascading Style Sheets), à la différence qu’il est basé sur un concept d’attributs HTML.

L’idée de base autour de ce nouveau langage est que tout comme avec le CSS, les développeurs pourront définir dans un fichier des attributs pour les balises HTML, qui seront directement appliqués à l’ensemble d’une page lors de l’appel de ces balises.

Concrètement, le développeur pourra par exemple écrire le code CAS suivant :

Code CSS :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
video {
  preload: metadata;
}

Lors de l’utilisation de la balise video dans son application Web, l’attribut « preload » sera automatiquement ajouté et sa valeur sera définie à « metadata ».

Un lien vers le fichier CAS doit au préalable être inclus dans la page HTML en utilisant la balise script <script type="text/cas">.

Selon la description d’Atkins, la grammaire de CAS est pratiquement identique à celle du CSS. La feuille d’attribut peut contenir des règles, des sélecteurs, des accolades et des déclarations.

Au niveau où le CSS a normalement un nom de propriété, CAS utilise un nom d’attribut. Tout jeton unique comme une chaine, un numéro ou un identifiant peut être utilisé pour définir la valeur d’un attribut.

Compte tenu de sa similitude avec le CSS, CAS peut être facilement pris en charge par les navigateurs qui pourront utiliser l’analyseur CSS existant en y apportant très peu de modifications.

La proposition de Tab Atkins Jr est en train d’être analysée par le W3C qui n’a pas encore pris une décision sur son adoption ou pas.



Source : W3C


Et vous ?

Que pensez-vous de CAS ? Intéressant ou le Web n'a pas besoin d'un langage de script de plus ?

[Kamule]

Un nouveau moyen de mutualiser les déclarations c'est toujours bon à prendre. Ca risque en plus de faciliter la mise en cache de ce genre de données.
Et comme dit dans l'article, c'est très proche du CSS, donc facile à ajouter aux navigateurs. Par contre, un moyen simple de gérer la compatibilité avec les anciens navigateurs ?

[grunk]

Rien que pour avoir des pages HTML qui vont à l'essentiel , ca pourrait être sympa.

D'un autre coté j'ai du mal à voir combien de fois on a besoin d'attributs qui pourraient être mutualisés dans une fichier à part ?

Parce que si c'est pour ecrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<a id="lelien">Mon lien</a>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#lelien {
    href : 'http://google.com';
    class : 'misenforme';
}

Ca présente quand même pas beaucoup d'intérêt.

[transgohan]

Je suis tout aussi sceptique que grunk, je ne suis pas dans le métier mais lorsque je développe quelques petits sites je n'ai jamais à utiliser des attributs HTML autres que title, alt ou href (et sans doute deux ou trois que j'oublie mais bon vous voyez le nombre quoi...).
La grosse part de renseignement se trouve dans la forme du DOM et des propriétés CSS.

[gwinyam]

Dans une application riche, cela pourrait avoir un sens. Mais en fait non, puisque dans une application riche, vous utilisez un moteur de templates. Et si vous l'utilisez correctement, vous aurez rarement à répéter une balise avec les mêmes attributs.

De plus, ça fera un fichier de plus à charger, pas terrible pour le chargement doux. Vous allez charger la structure du site (HTML simple), puis la description précise (CAS) de la structure puis l'apparence de la structure (CSS) puis son comportement (JS). Sans compter les nombreux médias et annexes de scripts. Ça va pas alléger les sites ça.

Comme grunk, je suis très sceptique. Je demande à voir.

[zeyr2mejetrem]

C'est moi ou tous les 2 jours, quelqu'un sort un "nouveau" langage qui doublonne fonctionnellement les existants ??

Franchement, mis à part contribuer à la fragmentation des langages (qui est déjà un bord*l apocalyptique), à quoi sert ce truc ?

[thelvin]

À la limite j'ai rien contre l'architecture proposée par ce truc.
Simplement... Bon, moi je veux bien croire que cela puisse possiblement servir à quelque chose.
Mais j'aimerais un exemple. Parce que, désolé, mais des balises <video>, dans les rares cas où j'en ai plus d'une par page, ben elles ne font justement pas la même chose.

[air-dex]

Ca ressemble à du QML.

[vanquish]

Même si l'intérêt reste très limité, dire que tout mes href de telle classe sont des popup ou tous mes bouton de telle classe sont de type "button" (et pas submit) ça peut être utile.

Mais déjà que l'intérêt reste très limité, à la base ; tant que 100% des navigateurs de le supporteront pas, ça n'aura pas d'intérêt du tout.
Qui va se faire suer à gérer 2 types de navigateurs pour si peu ?
Il va avoir du mal à s'imposer.

[la.lune]

Parce que si c'est pour ecrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<a id="lelien">Mon lien</a>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#lelien {
    href : 'http://google.com';
    class : 'misenforme';
}

Ca présente quand même pas beaucoup d'intérêt.

D'abord le facteur important ça permettra de factoriser plusieurs attributs qui sont les même dans plusieurs balise. et ça c'est un +10.

D'autre part toute personne ayant fait du html5 sait très bien que les balises sont trop long parce que les attributs sont nombreux alors du coup on a un gain et modularise nos attributs aussi.

Et pourquoi pas comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<a>Mon lien</a>

Si par exemple ta balise a étant le 3e on peut avoir ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
a:nth-child(3){
    href : 'http://google.com';
    class : 'misenforme';
}

N'est ce pas un gain et au cas ce même lie repète dans d'autre balise. En tout cas je dis oui pour ce projet et merci pour la personne ayant réfléchi sur ça +100

[Lutarez]

Dans le cas d'un site exploitant cette techno à 200%, ça va bien simplifier la vie des aspirateurs de site ! J'ouvre le fichier .cas et hop ! Plus qu'à se servir

Bref, n'étant pas très dev web, je ne vois pas l'intérêt pour le moment (comme dit plus haut, les templates, c'est marche très bien), mais j'espère que cela verra le jour pour les personnes qui peuvent en tirer profit (au moins ils nous ont pas encore réinventer un langage ce coup-ci !)

[Lutarez]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<a>Mon lien</a>

Si par exemple ta balise a étant le 3e on peut avoir ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
a:nth-child(3){
    href : 'http://google.com';
    class : 'misenforme';
}

Sauf que si une autre personne dans ton équipe "s'amuse" à changer l'ordre de tes liens dans la page, tout tes liens deviennent par conséquent faux. Dans un cas comme celui-ci, je pense que c'est une très mauvaise chose d'utiliser cette techno !

[la.lune]

Sauf que si une autre personne dans ton équipe "s'amuse" à changer l'ordre de tes liens dans la page, tout tes liens deviennent par conséquent faux. Dans un cas comme celui-ci, je pense que c'est une très mauvaise chose d'utiliser cette techno !

En tout cas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nth-child

fait déjà parti du CSS3 la W3C l'a déjà validé et elle est utilisé tant pis pour se qui ne savant pas s'en servir. Quand on utilise une techno en équipe on a intérêt à être conscient de ce qu'on fait, rien n’empêche de faire ce qu'on veux de la manière la plus facile et adéquate, c'est le moins que je pusse dire, toute chose à des inconvénients mais on compare les gain devant les pertes n'en parlons pas si les pertes sont probable avec une probabilité infime. On perd de l'essence lorsque la voiture marche et l'huile devient noir et on pollue la nature et pourtant on laisse pas la voiture.

Moi comme j'ai dis c'est la factorisation qui est plus important ici, même le fait d'attribuer des attribut class on va factoriser au lieu à chaque fois assigner la classe. Imaginer si tu a 5 champ de type texte au même class et tous des champs sont requis supposons qu'ils sont sur un div#id.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
<div id="id">
<input></input>
<input></input>
<input></input>
<input></input>
<input></input>
</div>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
div#id input{
type="text";
class="leschampsrequis";
required;
}

En utilisant un attribut html5 required pour designer qu'ils sont requis.

Et voila tout est fini.

Comparez cela à ceci.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
<div id="id">
<input type="text" class="leschampsrequis" required></input>
<input type="text" class="leschampsrequis" required></input>
<input type="text" class="leschampsrequis" required></input>
<input type="text" class="leschampsrequis" required></input>
<input type="text" class="leschampsrequis" required></input>
</div>

Imaginer le temps d'écrire tout ça encore un site de plusieurs page. Ce n'est qu'un petit exemple mais imaginez un site entier on écrira rapidement nos page, on les maîtrisera bien et on gagnera grandement en mémoire et les page se chargeront vite car il ne seront pas trop chargés..

[ferber]

En tout cas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nth-child

fait déjà parti du CSS3 la W3C l'a déjà validé et elle est utilisé tant pis pour se qui ne savant pas s'en servir. Quand on utilise une techno en équipe on a intérêt à être conscient de ce qu'on fait, rien n’empêche de faire ce qu'on veux de la manière la plus facile et adéquate, c'est le moins que je pusse dire, toute chose à des inconvénients mais on compare les gain devant les pertes n'en parlons pas si les pertes sont probable avec une probabilité infime. On perd de l'essence lorsque la voiture marche et l'huile devient noir et on pollue la nature et pourtant on laisse pas la voiture.

Moi comme j'ai dis c'est la factorisation qui est plus important ici, même le fait d'attribuer des attribut class on va factoriser au lieu à chaque fois assigner la classe. Imaginer si tu a 5 champ de type texte au même class et tous des champs sont requis supposons qu'ils sont sur un div#id.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
<div id="id">
<input></input>
<input></input>
<input></input>
<input></input>
<input></input>
</div>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
div#id input{
type="text";
class="leschampsrequis";
required;
}

En utilisant un attribut html5 required pour designer qu'ils sont requis.

Et voila tout est fini.

Comparez cela à ceci.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
<div id="id">
<input type="text" class="leschampsrequis" required></input>
<input type="text" class="leschampsrequis" required></input>
<input type="text" class="leschampsrequis" required></input>
<input type="text" class="leschampsrequis" required></input>
<input type="text" class="leschampsrequis" required></input>
</div>

Imaginer le temps d'écrire tout ça encore un site de plusieurs page. Ce n'est qu'un petit exemple mais imaginez un site entier on écrira rapidement nos page, on les maîtrisera bien et on gagnera grandement en mémoire et les page se chargeront vite car il ne seront pas trop chargés..

Personnellement
je trouve le code html du dernier exemple bien plus claire et facile a maintenir.
ensuite le fait de devoir multiplier les fichiers de pseudo code pour faire ce qu'un pseudo langage peut faire simplement me semble stupide.
Cela augmente le niveau de compétence nécessaire pour maintenir un site, donc augmente le coup du formulaire, augmentant au passage les listes d'erreurs potentiel, les chances d'avoir des incompatibilités, sans parler du nombre de connections supplémentaire pour la récupération des fichiers externe.

Je voudrait rajouter aussi que le simple fait d'utiliser le terme <langage> pour ce format de fichier est inadapté. Ce n'est pas un langage, c'est un <format de fichier descriptif>, tel que le rtf, l'odt, etc... bref on ne parle pas ici d'un nouveau langage, mais d'un nouveau format descriptif. ce qui n'est pas la même chose. Comprenne qui voudra.

bref, : vive l'as3 pour les app en ligne,
sinon je garde mes vieux tag html 1, pas besoins de plus pour faire une page web.

[Muchos]

Je trouve ce langage pertinent et plein de promesses.
Ca m'intéresserait surtout pour définir (et évidemment modifier) les attributs de classes que j'utilise souvent (par ex. : des liens de retour en haut, des logos, des microdata communes à plusieurs pages...) Ca aurait aussi des avantages en termes de mise en cache et de poids des pages. Si en plus les moteurs savent le traiter, alors je ne vois que du bon là-dedans.

Par contre, j'aurais préféré intégrer le fichier CAS avec <link> plutôt qu'avec <script>.

[v1cent]

Très intéressant...

A relier aux attributs html5 data-*

[transgohan]

Imaginer le temps d'écrire tout ça encore un site de plusieurs page.

Je sais qu'on est pas encore vendredi mais j'arrive pas à m'en empêcher...
Qui saurait donner un cours des fonctions copier et coller que l'on retrouve sur tous les éditeurs de texte/IDE/OS ?

[Zefling]

Si c'est aussi simple que du CSS, ça va vraiment faciliter le « responsive design » et le support conditionnel. Mais bon, s'il n'y pas de changement en live l'intérêt est tout de même moindre. En l'état actuel, j'y vois assez peu de réel intérêt si ce n'est de faire du sur-templeting et finalement compliquer les choses.

[xurei]

Même si l'intérêt de la techno est clair, je suis aussi dubitatif quant à son utilité en pratique...

Pour ceux qui demandent à voir, une mini-lib qui parse le code CAS et qui le convertit en une série de règles jquery devrait permettre d'avoir une POC. Le code serait dans le genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$(document).ready(function()
{
  //parser le code CAS somehow
    var rules = parse_cas();
 
  //pour chaque règle css, on ajoute les attributs
    for (r in rules)
    {
      var rule_selector = r.selector;
 
      for (rule_attrib in r.attribs)
        $(rule_selector).attr(rule_attrib, rule_value);
    }
}

Il suffit d'adapter un parseur CSS et le tour est joué !

[LSMetag]

La logique est intéressante :

Séparer les balises html de leur comportement.

Peut être intéressant lorsque l'on a des structures de balises récurrentes.
Comme dit plus haut ça permet d'avoir un standard permettant une fragmentation et une factorisation supplémentaire de son code html.

Indéniablement, c'est un gain de productivité pour le développeur. C'est aussi une simplification des pages HTML. Mais ça risque de nuire à la productivité des personnes qui devront ensuite reprendre son code ou le maintenir.

Je ne sais pas si c'est une très bonne idée.

imaginez qu'on fasse :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<div id = "test1"><input /> <input/></div><div id = "test2"><input/> <input/></div>

puis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
#test1 input
{
   type="button";
   text="coucou";
   value = "keke";
}
 
#test2 input
{
   type="text";
   text="coucou";
}

Pas évident de savoir au premier abord quel input correspond à tel composant.