Elementabfragen (oder „Containerabfragen“, falls dies erforderlich ist), finden weiterhin Eingang in Unterhaltungen zwischen responsive Webdesign-Machern. Ihre Einbeziehung in beliebige Spezifikationen und die derzeitige Landschaft ist jedoch unklar. In diesem Artikel werden die Elementabfragen besprochen, und wo sich der Community-Konsens derzeit zwischen Entwicklern und Standardarbeitsgruppen befindet.
Mit Elementabfragen können Elemente unabhängig von den Einschränkungen der Bildschirmgröße auf ihre eigenen Einschränkungen reagieren. Dies ist das wichtigste Detail, das man verstehen muss. Medienabfragen, wie wir sie kennen, sind zu 100% für das responsive Layout, aber das responsive Layout ist nicht zu 100%. @Medien
Anfragen. Module, Komponenten und Oberflächenelemente werden mit dem Bildschirm immer größer und kleiner, reagieren aber niemals eigenständig, weshalb @Medien
ist nicht die gesamte Lösung für unsere Probleme.
Sehen Sie sich diese grobe Demo von Elementabfragen mit eqcss an:
Viele Leute, die nach Lösungen für elementbasierte Haltepunkte suchten, begannen, CSS-in-JS mit Frameworks wie React zu implementieren. Während in anderen Bereichen Fortschritte erzielt wurden, brachen die Lösungen, die Entwickler entwickelten, von allgemein genutzten Lösungen für CSS oder JavaScript in mehrere Framework-spezifische Bibliotheken. Während die Ergebnisse variieren, sind die Kernfunktionen dieser Tools oft sehr ähnlich. In der Zukunft könnte eine Standardisierung dieser verschiedenen Techniken einen Ansatz für diese Art von Responsive Design verdeutlichen, der auf jede Website oder jedes Tool angewendet werden kann.
Bei meinen Diskussionen zu diesem Thema mit Tommy Hodgins (einem Befürworter von Elementabfragen und Ersteller von eqcss) scheint es, dass die Leute immer noch sowohl „Elementabfragen“ als auch das separate Konzept von „Containerabfragen“ kennen. Der Konsens scheint sich in einige Bereiche zu teilen:
Hier ist ein weiteres Beispiel, bei dem ich das CSS basierend auf der Breite des Videos ändern kann. Völlig unabhängig von der Größe des Darstellungsbereichs. pic.twitter.com/O6lbDBJvFf
- Wes Bos 🔥 (@wesbos) 6. Oktober 2017
Ich will Houdini Ich denke, wir können damit Konzepte entwickeln, mit denen Browser native werden können.
- Snook (@snookca) 6. Oktober 2017
Willst du einen Sprung in die Welt der Web-Entwickler machen? Seien Sie derjenige, der mit Houdini eine funktionierende Implementierung von Containerabfragen durchführt. 🤹🏼♂️
- Chris Coyier (@chriscoyier) 10. Oktober 2017
Was steht also auf der Wunschliste für Entwickler??
Stellen Sie sich vor, Sie könnten ein Plugin schreiben, das eher einem Browser-Patch als einem JavaScript-Plugin ähnelt. Was wäre, wenn Sie die Möglichkeit hätten, Ihre eigene Logik einzugeben, wie ein Browser Seiten analysiert, malt und rendert? Welche Dinge könnten Sie dem Browser „beibringen“, anstatt sich auf die Logik oben auf der Seite für die Berechnung zu verlassen?
Momentan halten wir an der Art und Weise fest, wie ein Browser CSS verarbeitet, aber mit Houdini besteht die Hoffnung, dass wir die Möglichkeit haben, neu zu ordnen und Prioritäten zu setzen, sodass wir mithilfe intelligenter Ansätze Werte berechnen oder das Rendern steuern können, um Fehler zu verbergen. APIs für JavaScript und CSS-Objektmodelle verleihen CSS die gleiche Art von Zugriff, Kontrolle und Leistungsfähigkeit, die JavaScript und DOM-APIs für HTML bieten. Laut Tab Atkins verwendet Houdini auch die Typed OM- und Parser-API-Logik, und dies sind die zugrunde liegenden Techniken für benutzerdefinierte At-Rules, mit denen Sie Elementabfrageregeln in Ihrem Stylesheet angeben und mit JavaScript behandeln können.
Auf ishoudinireadyyet.com gibt es eine Website, die sich ausschließlich mit der Verfolgung des Fortschritts befasst. In der Zwischenzeit wollen wir jedoch einige andere mögliche Lösungen in Betracht ziehen.
Die Verwendung von iframes zum Einschließen von Elementen ist sicherlich eine kluge Herangehensweise, aber leider ist dies immer noch keine echte Lösung für das Problem. mehr ein kreativer Hack. Lesen Sie mehr über diesen Trick aus dem Blog von Tab Atkins.
Diese Eigenschaft ist zwar nicht in der Spezifikationsform stabilisiert, soll aber auf Seiten nützlich sein, die viele unabhängige Widgets enthalten. Die Dokumente behaupten, dass sie verwendet werden können, um zu verhindern, dass die CSS-Regeln eines Widgets andere auf der Seite ändern. Ein Eigenschaftswert von streng
schlägt vor, dass viele Probleme von Containerabfragen vermieden werden können, dies ist jedoch nicht die gesamte Lösung; nur ein stück zum rätsel.
Ein Hauptproblem bei Containerabfragen ist, dass die untergeordneten Elemente und deren Inhalt angezeigt werden können haben einen Einfluss auf die Größe des Behälters. Theoretisch kann dies durch die Verwendung von CSS-Containment vermieden werden. Sehen wir uns jedoch das eigentliche Problem an, das diese Abhängigkeit zwischen den Elementen verursacht.
Schauen Sie sich den folgenden Vortrag von Dan Tocchini an (Sie können das Video ab der Marke 10:00 starten, da Vimeo keine Zeitstempel zulässt)..
Warum reagiert ein Element nicht auf seine Größe? Zyklische Abhängigkeiten. Hier ist eine Grafik, die aus dem obigen Video erstellt wurde:
Jedes Feld hängt von den Einschränkungen seines Feldes ab (Breite
in diesem Fall), und hier treten die zyklischen Abhängigkeiten auf. Es gibt eine konstante Beziehung zwischen diesen gebundenen Elementen, die natürlich auftritt. Diese Art von Verhalten existiert auch mit :schweben
Ereignisse, wie Tommy Hodgins in diesem Video erklärt.
Zyklische Abhängigkeiten sind, wenn ein großer Teil der Leute, die den Begriff "Container-Abfrage" verwenden, stecken bleiben, weil:
Die gute Nachricht ist, dass Browser allmählich Beweise für die Behebung dieser Probleme aufzeigen, wie zuvor mit Houdini erörtert wurde.
Es gibt zufällig eine CSS-Element-Abfrage (Traum) von Tommy Hodgins; und obwohl es nur eine Traumspezifikation ist, ist es sehr beeindruckend, wie lange es dauert, Worte und Vorschläge in das Gespräch zu bringen. Er hat auch eine Website zusammengestellt, auf der Entwickler aufgelistet sind, die an Containerabfragen arbeiten, die entsprechend mit dem Titel "Wer arbeitet an Containerabfragen" arbeitet..
Nach all meinen Nachforschungen frage ich mich immer noch, warum die Mehrheit unserer Community nicht so baut, wenn wir können? Wir hatten vor CSS die Möglichkeit, auf diese Weise zu bauen @Medien
wurde im Browser unterstützt, aber es scheint, dass wir abgelenkt wurden. Wir hatten keine Ahnung von „Responsive Best Practices“ und haben herausgefunden, wie man verschiedene Ergebnisse mit Hilfe von erreichen kann @Medien
; und das verbreitete sich wie ein Lauffeuer. In Artikeln, in denen über „Media-abfragefreies responsives Layout“ unter Verwendung intelligenter Anzeigemodelle wie Flexbox und Grid diskutiert wird, wird deutlich, dass es schwierig ist, das responsive Layout von Medienabfragen zu trennen.
Schauen Sie sich diese Präsentation von Eric Portis an (Contain Your Excitement), in der er genau diesen Punkt bespricht. Mit so vielen Roadblocks, wie können wir die Webplattform insgesamt voranbringen?
Im Folgenden finden Sie einige allgemeine Soundbits, die Sie zu Elementabfragen hören:
👏 👏 👏🏻 👏🏾 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻 👏🏻
- Zach LeatHERMAN 🎃⬆⌨ (@zachleat) 6. Oktober 2017
Ich denke, dass Intl-Lösungen auf JS basieren und diese nur CSS-only APIs informieren. Wir sollten tmp-Lösungen nicht ignorieren, nur weil sie JS erfordern.
- Phil Walton (@philwalton) 6. Oktober 2017
Es fühlt sich so an, als ob Houdini manchmal ein Weg sein könnte zu sagen: "Wir können uns nicht die Mühe machen, unsere Zeit damit zu verschwenden, also lasst uns * sie * herausfinden"
- Sara Soueidan 🐦 (@SaraSoueidan) 6. Oktober 2017
Wie ich im Laufe meiner Karriere erfahren habe, äußerten Entwickler nur selten Probleme mit JavaScript, um Unterstützung hinzuzufügen @Medien
mit IE8, weil wir JavaScript brauchten, um bei fehlenden Browsern mehr Gestaltungsmöglichkeiten zu bieten. Verwenden Sie jedoch bereits im Browser JavaScript, um CSS zu verbessern? Das ist Ketzerei für viele. sogar einige von denen, die total glücklich sind, JavaScript zum Zusammenstellen von HTML zu verwenden.
Die in den vorangegangenen Abschnitten genannten Ideen erlauben es Entwicklern sicherlich, an ihren eigenen Ideen zu arbeiten, aber wir müssen häufiger zusammenkommen, Notizen vergleichen, einen Standardansatz finden und ihn einschließen. Meiner Ansicht nach können wir das nicht Scheiden Sie JavaScript von CSS, wenn es um Elementabfragen geht. Jeder, der auf einen reinen CSS-Ansatz wartet, könnte viele, viele Jahre im Zugdepot sein.
Verwenden Sie Elementabfragen in Ihrer eigenen Arbeit? Sind Elementabfragen aufgrund der hochmeinenden Sichtweisen eine verlorene Ursache? Ich hoffe, dass diese Diskussion dazu beiträgt, Überlegungen anzustellen, die es JavaScript ermöglichen, am Tisch Platz zu finden, sodass wir außergewöhnlich flexible Komponenten für das sich ständig verändernde Web erstellen können. Bitte poste deine Gedanken wie immer in den Kommentaren und fröhliche Kodierung.
Ein großes Dankeschön an Tommy Hodgins für seine Zeit und wertvolles Wissen zu diesem Thema und auch für all seine Arbeit, die dieses Community-sensible Thema aufrechterhält.