+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 154
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 154
    Points : 9 224
    Points
    9 224

    Par défaut Les Web Components, pour le meilleur et pour le pire



    Avez-vous déjà utilisé les Web Components ? Cette nouvelle façon de concevoir les pages Web est pressentie comme une prochaine révolution en matière de développement web. Elle permet de manipuler des composants d'interface encapsulés sous la forme de balises HTML personnalisées, grâce à l'association de plusieurs nouvelles spécifications : les Custom Elements, les HTML imports et le Shadow DOM.

    Si vous n'avez jamais entendu parler des Web Components, je vous invite à découvrir cette excellente introduction par Didier Mouronval : Les éléments personnalisés - Créez de nouvelles balises HTML

    Les Web Components ont fait beaucoup parler d’eux depuis l’avancée des dernières spécifications et le développement de polyfills permettant de les utiliser dès maintenant. Mais cet engouement est-il justifié ? Pour aller à contre-courant de la multitude d’articles en vantant les mérites, j'ai souhaité mettre en avant l’intérêt discutable, les limitations, les inconvénients et les mauvais cas d’utilisation des Web Components :

    Débat: Les Web Components, pour le meilleur et pour le pire ?

    Je vous invite à poursuivre le débat ici.

    Allez-vous utiliser les Web Components dans vos futurs projets ?
    Pensez-vous que les Web Components vont révolutionner le développement web ?
    Quels autres avantages et inconvénients voyez-vous dans l'état actuel des spécifications ?
    One Web to rule them all

  2. #2
    Membre expert
    Avatar de Kaamo
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    1 166
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 1 166
    Points : 3 023
    Points
    3 023

    Par défaut

    Quel pessimisme...ça fait du bien ! Enfin un article qui met le doigt sur la corde sensible des Composants Web.

    Je suis aussi mitigé que toi. Ce qui me fait peur c'est la qualité et surtout la pérennité des Composants trouvés au hasard du net. Quid du versionning du Composant ... y'a t-il un mécanisme de mise à jour ?
    Un composant vanilla, ok ... Mais si le Composant repose sur une librairie. Dois-je vraiment charger cette lib pour faire tourner le Composant ? Et si je préfère un composant chez une lib concurrente ? J'espère que l’interopérabilité sera au RDV.

    J'ai aussi peur qu'à l'avenir les développeurs utilisent à tout-va les Composants Web comme ils ont utilisé à tout-va jQuery. La facilité au détriment de la qualité.
    Si tout le monde pouvait se poser les questions "check" que tu décris à la fin de ton article.

    A choisir, pour le moment, je préfère :
    Code html : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    <div id="une-bonne-soupe-à-l-ancienne>
      <div id="mon-bol-prefere">
        <span>avec des bons légumes dedans</span>
      </div>
      <div id="ma-cuillere-fetiche">
        <span>rouge et jaune à p'tits pois.</span>
      </div>
    </div>

    plutôt que :
    <une-soupe-dont-je-ne-vois-pas-les-ingrédients />

  3. #3
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2005
    Messages
    274
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juin 2005
    Messages : 274
    Points : 469
    Points
    469

    Par défaut

    Citation Envoyé par Kaamo Voir le message
    J'ai aussi peur qu'à l'avenir les développeurs utilisent à tout-va les Composants Web comme ils ont utilisé à tout-va jQuery.
    Je n'ai jamais utilisé les WebComponents (j'ai regardé rapidement le lien et je dois reconnaître que je trouve ça un peu lourd) mais je trouve que c'est un premier pas intéressant de vouloir standardiser cette manière de développer.

    Après tout du réutilisable c'est ce qu'on fait avec les languages de template type Handlebar. Et puis le fait que jQuery soit utilisé à tort et à travers n'en rend pas la lib moins performante non ?
    Mobile first !
    Développeur & co-fondateur de appSoluce ! - développement de solutions mobiles cross-platform

  4. #4
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 154
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 154
    Points : 9 224
    Points
    9 224

    Par défaut

    Citation Envoyé par madfu Voir le message
    Et puis le fait que jQuery soit utilisé à tort et à travers n'en rend pas la lib moins performante non ?
    Justement si, certains ont pointé du doigt qu'utiliser systématiquement jQuery n'était pas justifié et pouvait se ressentir sur les performances. Mais dans le cas des Web Components, la performance est loin d'être ma principale préoccupation.
    One Web to rule them all

  5. #5
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2005
    Messages
    274
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juin 2005
    Messages : 274
    Points : 469
    Points
    469

    Par défaut

    Citation Envoyé par SylvainPV Voir le message
    Justement si, certains ont pointé du doigt qu'utiliser systématiquement jQuery n'était pas justifié et pouvait se ressentir sur les performances.
    C'est sûr. Mais entre nous je préfère vivre dans un monde avec jQuery même si certains l'utilisent à tort et à travers. Quand aux WebComponents puisque c'est ça le débat j'attendrais de voir mais je pousse clairement dans ce sens.
    Mobile first !
    Développeur & co-fondateur de appSoluce ! - développement de solutions mobiles cross-platform

  6. #6
    Membre éprouvé
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2014
    Messages
    539
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2014
    Messages : 539
    Points : 929
    Points
    929

    Par défaut

    Citation Envoyé par madfu Voir le message
    C'est sûr. Mais entre nous je préfère vivre dans un monde avec jQuery même si certains l'utilisent à tort et à travers. Quand aux WebComponents puisque c'est ça le débat j'attendrais de voir mais je pousse clairement dans ce sens.
    Personnellement, je préfèrerais vivre dans un monde sans jQuery mais avec un Javascript unifié et pourvu nativement en méthodes d'animation de propriétés.

  7. #7
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 205
    Points : 577
    Points
    577

    Par défaut

    Merci à l'auteur pour ce débat.

    Je partage certaines interrogations comme l'utilité des HTML imports, lesquels impliquent une utilisation agressive des requêtes HTTP. S'agit-il d'un standard réservé aux applications non déployées dont les composants ne sont pas encore minifiés et fusionnés ? Ou bien est-ce un pari sur l'avenir du protocole HTTP 2 ? Sur le sujet : la FAQ de Polymer.

    Actuellement, la spécification présente plus de contraintes que d'avantages comparée aux solutions existantes à base de <script>. Elle a le mérite d'enfin apporter un standard pour un mécanisme utilisé et éprouvé depuis des années. Mais tout comme les imports HTML, elle semble arriver trop tard et les éléments <template> seuls ne servent à rien sans JavaScript pour les activer.
    Personnellement j'ai toujours trouvé que le détournement de la balise <script> était une bidouille infame. La balise <template> est la bienvenue. Il n'est jamais trop tard pour bien faire.

    HTML, un descendant de SGML […] HTML a pris un autre chemin. […] Depuis HTML5, les éléments n'ont d'ailleurs plus à respecter les contraintes d'une DTD […] Malgré le fait que le HTML5 se soit émancipé des DTD, on pourrait tout de même en parler ne serait-ce qu'à titre de comparaison.
    Tout à fait. Il y a dix ans le XHTML était l'avenir du HTML et HTML 4 était vu comme un dialect SGML approximatif dont les parseurs toléraient les écarts. Depuis HTML 5, HTML trace son propre chemin. Par exemple, les balises non fermées, lorsqu'elles ne sont pas ambigües, sont devenues des fonctionnalités que Google recommande d'utiliser.

    D'autres diront qu'il présente un intérêt pour l'isolation des règles CSS. Je leur répondrai qu'il existe d'autres moyens pour y parvenir sans avoir à fragmenter le document: <style scoped> @import "composant.css"; </style>
    J'ai lu récemment que cette fonctionnalité était en train d'être abandonnée

    Sur les Shadow DOM je n'ai pas encore d'expérience mis à part quelques tests. Toutefois je ne pense pas qu'il faille les voir comme autre chose que des espaces de nommage. Et dans des applications JavaScript, un mécanisme d'encapsulation est une fonctionnalité bienvenue.

    Au fond le mensonge dans les "Web components" vient de l'apparente simplicité d'utilisation. Un web component sans framework est soit compliqué à utiliser parce qu'il faut le fusionner et faisant gaffe aux dépendances, soit un défaut de performance parce que son chargement nécessite plusieurs requêtes HTTP. Je pense qu'un bon Web component facile à utiliser dépendra en fait d'un framework et non pas des seuls standards.

  8. #8
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 154
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 154
    Points : 9 224
    Points
    9 224

    Par défaut

    A propos de style scoped, voilà un extrait des échanges des équipes Blink:

    <style scoped> has been burden for us to maintain.I've felt several times that <style scoped> is the cause of code complexity when I work on Shadow DOM styling.


    I'm not saying that blink shouldn't support <style scoped>.
    I am saying that we can get benefits from the view of hack-ability of style system if we can forget <style scoped>.
    We can reimplement <style scoped> later once we feel it's needed.
    Il ne s'agirait donc pas d'un abandon, mais d'un retrait temporaire d'une fonctionnalité qui était toujours resté au stade expérimental. Ce retrait a été amené à cause de la complexité de l'implémentation du Shadow DOM... ben voyons
    One Web to rule them all

  9. #9
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 205
    Points : 577
    Points
    577

    Par défaut

    Ah, et je vois que Firefox implémente "style scoped". C'est intéressant. Peut-être effectivement une meilleure manière de concevoir une application avec des styles imbriqués : meilleur pour l'homogénéité. D'un autre côté, je me demande si l'inclusion de styles dans le code HTML est ou non une manière élégante de travailler.

    Contrairement à un "style scoped", dans le cas du shadow DOM, les styles globaux ne s'appliquent pas sur les shadow DOM. C'est un inconvénient : comme pour les iframe, le résultat final est une page vraiment pas homogène. Mais c'est aussi un avantage : pas d'effet de bord lors d'un changement des CSS du DOM global.

    Un reset CSS classique (ou un normalize.css) ne s'applique donc pas sur les balises situées à l'intérieur du shadow DOM. Il faudra réécrire les styles transversaux avec le sélecteur /deep/, mais il reste à voir les effets sur la performance et puis on manque un peu de recul pour savoir si l'on peut travailler proprement ainsi.

  10. #10
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 154
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 154
    Points : 9 224
    Points
    9 224

    Par défaut

    Exact, l'isolation totale a plus d'inconvénients que d'avantages selon moi. Certaines règles, comme celles de normalisation ou celles relatives à la charte graphique du site, ont tout intérêt à s'appliquer partout. D'autres ne devraient s'appliquer qu'au composant ciblé, et les styles scoped ont été pensés pour ça.

    Mais on a pas absolument besoin de ces nouvelles fonctionnalités: les développeurs ont déjà résolu ce problème en ajustant intelligemment la spécificité des sélecteurs, comme tu l'as bien montré Tarh avec ton article sur la méthodologie BEM par exemple.

    Concernant la place du CSS dans le HTML, je suis d'accord que multiplier les balises <style> au milieu du document n'est pas non plus la panacée. Idéalement j'aurais voulu que CSS gère les nested rules (règles imbriquées), comme le font déjà tous les préprocesseurs CSS.
    One Web to rule them all

  11. #11
    Membre expert Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : avril 2007
    Messages : 858
    Points : 3 015
    Points
    3 015

    Par défaut

    Citation Envoyé par SylvainPV Voir le message
    Concernant la place du CSS dans le HTML, je suis d'accord que multiplier les balises <style> au milieu du document n'est pas non plus la panacée. Idéalement j'aurais voulu que CSS gère les nested rules (règles imbriquées), comme le font déjà tous les préprocesseurs CSS.
    Genre ça : http://tabatkins.github.io/specs/css-nesting/
    Dommage que ça ne soit qu'une proposition.
    Mon blog de développeur web.

    Projet : BakuJS

  12. #12
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 205
    Points : 577
    Points
    577

    Par défaut

    Citation Envoyé par Zefling Voir le message
    Genre ça : http://tabatkins.github.io/specs/css-nesting/
    Dommage que ça ne soit qu'une proposition.
    D'après ce que je lis c'est juste une manière de refaire ce que font les préprocesseurs, en moins souple, moins lisible, moins complet. Si le but est d'apporter les namespaces aux CSS, les actuels sélecteurs de descendants feraient l'affaire (".namespace .nested-selector") à part qu'il est impossible de les optimiser (ils sont intrinsèquement lents). Si l'on pouvait indiquer au navigateur où sont les composants dans le document, il pourrait en faire des contextes partiellement autonomes. Cela permettrait des optimisations, comme la génération de tables de hachage pour les descendants au niveau de chaque composant. Les blocs englobants des préprocesseurs CSS se rapprochent effectivement de ce besoin, mais une spécification qui irait dans ce sens ne permettrait pas un sélecteur "section > &".

  13. #13
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 154
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 154
    Points : 9 224
    Points
    9 224

    Par défaut

    @Tahr: le besoin que je verrais serait plus quelque-chose de ce genre :
    Code css : Sélectionner tout - Visualiser dans une fenêtre à part
    #header { @import "header.css"; }

    Que ferait ton sélecteur "section > &" ? Si ça reviendrait à ajuster le sélecteur selon le parent, c'est intrinsèquement impossible avec CSS qui ne peut pas naviguer dans le DOM de bas en haut.

    Les sélecteurs par descendant amènent de nombreux copier-coller, ils ne sont pas optimisés ni pour le temps de traitement, ni pour la taille de fichier. Les nesting rules pourraient faire d'une pierre deux coups.
    One Web to rule them all

  14. #14
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 205
    Points : 577
    Points
    577

    Par défaut

    Citation Envoyé par SylvainPV Voir le message
    Que ferait ton sélecteur "section > &" ?
    Il est dans la proposition de spec, le lien donné par Zefling.

  15. #15
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2005
    Messages : 3 790
    Points : 7 688
    Points
    7 688

    Par défaut

    Hello,

    J'arrive un peu après la bataille, mais je vais lire ce débat avec intérêt, pour une fois qu'on voit un peu de critiques construites sur les web components, il ne faut pas s'en priver !
    Je voudrais juste revenir sur le shadowDOM considéré comme un cache misère.

    Je ne peux pas être en désaccord avec cela, mais je ne comprends pas trop pourquoi cela est reproché aux web-components.
    Je m'explique : c'est un peu comme un plugin jQuery, une directive Angular, ou que sais-je encore, on l'utilise "tel quel", mais rien n'empêche d'aller jeter un oeil dans le code (c'est d'ailleurs plutôt sain en général).
    Si cela ne nous plait pas, il y a plusieurs solutions : on en choisit un autre, on le réécrit, on le forke, on push-requeste, etc.

    Bref, si cela peut être considéré comme un problème, ce n'est absolument pas lié aux web-components. Quand j'utilise une librairie Java, rien ne me dit si le code est correct, sécurisé, performant, sauf à y jeter un oeil (quand il n'est pas obfusqué du moins).

    Alors bien entendu, on finira toujours pas se poser la question "j'ai besoin d'utiliser un composant X, lequel prendre ?", et hélas la réponse n'est pas toujours simple. Mais cette question, on se la pose déjà tous les jours, et ce n'est pas près de changer !

    Au final, je préfère avoir 1 à 2 lignes d'un composant que j'aurais choisi et approuvé plutôt que d'écrire moi-même 30 lignes de "plomberie".
    Quand on voir le code d'un carousel de Bootstrap (http://getbootstrap.com/javascript/#carousel), je me dis qu'il y a quand même beaucoup de code "pour rien" (ou plutôt juste là pour faire marcher le composant).
    Avoir un truc du genre :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    <tb-carousel>
    	<tb-slide>...</tb-slide>
    	<tb-slide>...</tb-slide>
    	...
    </tb-carousel>
    c'est quand même plus clair et plus lisible, non ? Il ne faut pas oublier qu'on passe en général 80% à lire du code et 20% à en écrire. Plus celui-ci est concis / clair, mieux c'est !
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  16. #16
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 154
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 154
    Points : 9 224
    Points
    9 224

    Par défaut

    Oui, le problème du junk HTML n'est pas à imputer aux Web Components ; il existe depuis des années, que ce soit de la mise en page par tableaux ou de la soupe de <div>. Mais ce que je crains est que l'on fasse passer les Web Components pour une solution à ce problème, alors qu'il n'en est rien. Pire, cela pourrait être considéré comme une acceptation tacite et quelque peu fataliste au fait qu'un markup de présentation est nécessaire. Auquel cas le problème devrait logiquement empirer davantage, puisqu'il y a maintenant un standard qui lui est dédié. La citation de webcomponents.org que j'ai mis dans l'article est vraiment révélatrice à ce sujet. C'est ce que j'ai voulu exprimer par mon illustration de la boîte en carton sur la tête, car selon moi la pire façon de faire face à un problème est de mettre un drap dessus.
    One Web to rule them all

  17. #17
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 205
    Points : 577
    Points
    577

    Par défaut

    AMP, le nouveau projet de Google destiné à accélerer l'affichage des pages Web sur les mobiles, fait massivement appel aux Web components:

    With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.

    JavaScript is the core building block for advanced web apps, but for static content it may not always be required: for a headline, some text and an image you do not need JS. Looking further into the content being created on the web nowadays, there are, however, things like lightboxes, various embeds, polls, quizzes and other interactive features that cannot easily be implemented without JavaScript. But the web platform has a great solution: custom elements and web components. AMP components may have JavaScript under the hood, but it is coordinated with other AMP components, so its composition into the page doesn’t cause performance degradation. If AMP HTML provided the right custom elements, we might be able to get rid of arbitrary JavaScript for these documents altogether. [Source]
    À lire aussi : la présentation officielle, une critique. Et l'article de developpez.com !

  18. #18
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 154
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 154
    Points : 9 224
    Points
    9 224

    Par défaut

    Le tech lead du projet AMP a dit :
    With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.
    Donc interdiction d'utiliser des scripts persos ou extérieurs, uniquement les Web Components Google-approved. Vous les voyez venir là, les Web Components boîte noire ? Ne donnez pas les clés de votre site à n'importe qui !

    http://sylvainpv.developpez.com/publ...ts-debat/#LV-C
    One Web to rule them all

  19. #19
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 205
    Points : 577
    Points
    577

    Par défaut

    :scope est obsolète.
    Sait-on pourquoi ?

    La page de Mozilla précise :

    In JavaScript, when used with Element.querySelector, Element.querySelectorAll, or Element.closest, :scope refers to the element on which these methods are invoked. For example, document.body.querySelector(":scope") returns the body element. While support for :scope has been removed for CSS, this use of :scope continues to be supported.
    Il continue à être supporté par "querySelectorAll" mais cet usage est-il menacé ?

  20. #20
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 205
    Points : 577
    Points
    577

    Par défaut

    Autre info, il semble que ce soit la fin pour les HTML Imports : https://www.polymer-project.org/blog...22-npm-modules

Discussions similaires

  1. Les MOOC sont-ils la meilleure arme pour former les éducateurs ?
    Par Stéphane le calme dans le forum Etudes
    Réponses: 1
    Dernier message: 06/12/2013, 10h49
  2. POO : pour le meilleur et oublions le pire
    Par punkscum dans le forum Langages de programmation
    Réponses: 11
    Dernier message: 25/04/2006, 00h53

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo