Javascript dégradable, <yesscript> ?

par **Hywan** » 02 nov. 2008, 23:19

HS : http://lists.w3.org/Archives/Public/pub ... l/2008Oct/
HS 2 : http://lists.w3.org/Archives/Public/pub ... l/2008Nov/
si ça t'amuse. Les titres sont explicites, tu retrouveras facilement. Sinon, utilise la recherche.

Et oui, il y a beaucoup à lire et c'est pas simple à comprendre …

Personnellement, la perspective de lancer le débat ici m'effraie

. Si tu te sens de le faire, vas-y, mais évitons tout le cheminement déjà effectué veux-tu

.

</hs>

par AB » 02 nov. 2008, 23:02

Ne m'en parle pas … en ce moment on se bat sur la balise <q> alors … bobo la tête mine de rien. 20 mails par jours, c'est violent. 54 ce week-end.

V'oui, c'est plus difficile que de gagner des élections en racontant n'importe quoi

Bon on en reparlera dans un autre topic, de la définition de la balise q. M'enfin comme celle-ci est assez universelle, je me demande un peu où se situe la polémique

par **Hywan** » 02 nov. 2008, 22:33

Ne m'en parle pas … en ce moment on se bat sur la balise <q> alors … bobo la tête mine de rien. 20 mails par jours, c'est violent. 54 ce week-end.

par AB » 02 nov. 2008, 22:29

Hey ,

On préférera utiliser display à visibility en revanche.
Et je ne comprends pas pourquoi ce n'est pas valide XHTML 1.1 ?

Taratata... on préférera utiliser ce que l'on veux suivant les circonstances. La propriété "visibility" ayant l'avantage de réserver les dimensions du bloc, ce qui peut être utile dans certains cas.

Concernant la non validation en XHTML 1.1, le validateur dit qu'il ne doit pas y avoir d'id dans une balise <style type="text/css"...
Maintenant si tu me demandes pourquoi ils ont décidé ça ... bah on va rentrer dans le conceptuel du comment du pourquoi. Et pour m'être penché à quelques reprises sur ce genre de décisions, je te laisse volontiers la suite

par **Hywan** » 02 nov. 2008, 22:11

Hey

,

On préférera utiliser display à visibility en revanche.
Et je ne comprends pas pourquoi ce n'est pas valide XHTML 1.1 ?

par AB » 02 nov. 2008, 18:41

J'avais gardé cette astuce dans mes cartons ...

On peut également utiliser ce script (premier post donné par Hubert) pour cacher des éléments pour les seuls navigateurs ayant JS activé.
C'est très pratique quand on doit modifier des styles css sans attendre le chargement de la page, et sans avoir à modifier les styles Css via javascript (ce qui peut s'avérer pénible et délicat pour être compatible avec la majorité des navigateurs).

Code : Tout sélectionner

<style type="text/css">
.cachetext {
visibility:hidden;
}
</style>

<style type="text/css" id="degradable_js_stylesheet">
.affichetext {
visibility:visible;
}
</style>

<script type="text/javascript">
var stylesheet = document.getElementById('degradable_js_stylesheet');
stylesheet.parentNode.removeChild(stylesheet);
</script>


//... HTML
<div class = "cachetext affichetext">Contenu</div>

Gros avantage : la simplicité et la compatibilité du code avec quasiment tous les navigateurs.

Le seul tout petit problème : cette syntaxe n'est pas valide XHTML 1.1 mais "seulement" XHTML 1.0 scrict.

par **Hubert Roksor** » 24 févr. 2008, 17:26

Comme pour getElementsByTagName(), tu dois attendre d'avoir chargé le DOM pour utiliser XPath. Tu peux utiliser l'un comme l'autre dans <head /> mais ça ne servirait à rien puisque le document n'a même pas de <body /> à ce moment là.

...d'où l'approche actuelle consistant à virer du document cet élément <style /> avant même d'avoir commencé à peindre la page.

par **Hywan** » 24 févr. 2008, 17:10

Si XPath est moins ch*ant à utiliser, et qu'il ne nécessite pas que le DOM soit chargé, ne serait-il pas préférable de le préférer à getElementsByTagName() ?

par **Hubert Roksor** » 19 févr. 2008, 11:16

À ma connaissance, à peu près tous les navigateurs proposent XPath. Le problème d'XPath étant qu'il est super-relou à utiliser en JS

[edit: ah ben non, moins que dans mes souvenirs. En tout cas, dans les navigateurs récents]

Ceci dit, comme je le disais plus haut, les solutions à base de getElementsByTagName() ont le désavantage de nécessiter d'attendre que le DOM soit complétement chargé et peuvent potentiellement entrainer plusieurs reflow puisque chaque élément est modifié séparément, c'est pourquoi je m'oriente vers quelque chose qui puisse être placé dans le <head>. D'après ce que j'ai pu voir sur les navigateurs à ma disposition, ma solution actuelle pourrait être la meilleure, mais je reste vigilant et n'écarte pas la possibilité que l'on trouve un moyen plus pratique.

par **Hywan** » 19 févr. 2008, 11:06

À propos de rapidité, tu devrais jeter un oeil sur l'intégration native de certaines fonctions Javascript comme getElementsByClassName pour WebKit. Apparemment, ce procédé devrait s'étendre à plusieurs navigateurs par la suite tellement les résultats autrement performants.
Edit : les commentaires sont également intéressants .
On l'aura attendue longtemps cette fonction... Et le temps que les utilisateurs aient tous des navigateurs qui la supportent, les solutions comme celle d'Hubert ont encore de longues années devant elles

Ça arrivera plus vite que tu ne le crois

. Si WebKit l'implémente, alors Safari et Konqueror l'auront. Firefox est séduit par ces résultats, peut-être pour la bêta 4 de ffx 3 ? Non j'en doute, mais pour Firefox v4, il y a de forte probabilité pour que ça arrive. Comptons alors 2 ans maximum.
Et pour IE ... euh c'est quoi déjà comme logiciel ça ?

On notera au passage que XPath est plus rapide que DOM. Comme Hubert s'intéressait à XML la dernière fois, tu peux sûrement savoir si XPath est activé côté client (navigateur), car les résultats sont sensiblement plus performants.

par **naholyr** » 18 févr. 2008, 22:51

Je procède comme ça aussi, j'utilise ce genre de choses en général :

Javascript

Code : Tout sélectionner

Event.observe(window, "load", function(){
  $A(document.getElementsByTagName("yesscript")).each(function(element){
    element.show();
  });
});

HTML

Code : Tout sélectionner

<span class="yesscript">Only si tu as enablé Javascript my buddy-friend :)</span>

par AB » 18 févr. 2008, 13:29

À propos de rapidité, tu devrais jeter un oeil sur l'intégration native de certaines fonctions Javascript comme getElementsByClassName pour WebKit. Apparemment, ce procédé devrait s'étendre à plusieurs navigateurs par la suite tellement les résultats autrement performants.
Edit : les commentaires sont également intéressants .

On l'aura attendue longtemps cette fonction... Et le temps que les utilisateurs aient tous des navigateurs qui la supportent, les solutions comme celle d'Hubert ont encore de longues années devant elles

par **Hywan** » 18 févr. 2008, 10:50

À propos de rapidité, tu devrais jeter un oeil sur l'intégration native de certaines fonctions Javascript comme getElementsByClassName pour WebKit. Apparemment, ce procédé devrait s'étendre à plusieurs navigateurs par la suite tellement les résultats sont autrement performants.

Edit : les commentaires sont également intéressants

.

par AB » 18 févr. 2008, 02:12

Je prend note.

Jusqu'à présent je n'avais à gérer qu'un bloc ou deux donc je faisais :

Code : Tout sélectionner

<body onload="document.getElementById().style.display = 'block' ;">

après les avoir cachés par CSS

Pour plus d'un bloc ta solution me parait tip top

par **Hubert Roksor** » 18 févr. 2008, 00:04

Un document.write() ?

L'embêtant d'un document.write() (ou des appels d'appendChild, innerHTML, etc...) c'est que c'est relativement lent et ça force à mélanger HTML et Javascript. Ça interfère également avec le processus de validation du document.

Pour ma part, je pencherais sur l'ajout d'une classe à chaque élément qu'on souhaite masquer en JavaScript. En JavaScript, il suffirait de boucler chaque élément et d'ajouter le style display: none chaque fois qu'on trouve le nom de la classe cherchée.

Le principe est de faire apparaître les éléments nécessitant Javascript, et dans ce cas il faudrait faire un "display:block" ou plutôt retirer la valeur de l'attribut "display" pour lui faire adopter sa valeur par défaut et ne pas interférer avec les éléments inline. Malheureusement, ça voudrait dire qu'il faut faire une boucle sur tous les éléments de la page, donc ça peut prendre un petit peu de temps. De plus, cette boucle ne pourrait être exécutée qu'une fois le DOM complètement chargé et probablement déjà au moins partiellement affiché. C'est pourquoi j'ai opté pour un script que l'on peut placer le plus haut possible dans le document, de façon à minimiser le nombre de repaint/reflow.

Je ne l'ai pas précisé, mais j'ai aussi essayé de modifier le CSS via l'interface DOM, mais c'est plus long à taper et comme toujours la gymnastique pour le faire fonctionner sous IE est très désagréable.

Pour l'heure, retirer ce stylesheet spécial par removeChild() semble est la solution la plus rapide et la plus simple, mais si vous avez d'autres idées n'hésitez pas !

Javascript dégradable, <yesscript> ?

Répondre

Étendre la vue Revue du sujet : Javascript dégradable, <yesscript> ?