Der aktuelle Status von Elementabfragen

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.

Was sind Elementabfragen??

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:

Die Frontlinie

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??

  1. Erstellen Sie einen Beobachter für die Größenänderung, und untersuchen Sie den Vorteil, wenn Sie Entwicklern ein besseres Primitiv für die Erstellung von breitenbasierten Haltepunkten bieten. Dies ist das grundlegende Element, das wir für die effiziente Durchführung von Elementabfragen mit JavaScript benötigen. Die unglückliche Nachricht ist, dass Resize Observer nicht bereit ist, aber die Community ihrer Entwickler ist hart daran, dies zu verwirklichen. Sie können die Angaben zur Öffentlichkeit lesen, wenn Sie weiter eintauchen möchten.
  2. Entwickeln Sie Houdini zu einem Arbeitsmodell und präsentieren Sie es als perfekten Anwendungsfall für unsere Bedürfnisse. Derzeit konzentriert sich die CSS-Arbeitsgruppe tatsächlich auf Houdini.
  3. Bieten Sie Entwicklern die Möglichkeit, die APIs zu verwenden, die vom CSS-Objektmodell festgelegt wurden (eine Sammlung von APIs, mit denen JavaScript mit CSS kommunizieren und diese bearbeiten kann). Die Absicht von CSS OM-Entwicklern besteht darin, einen neueren, tieferen Zugriff darauf zu zeigen, wie ein Browser CSS verarbeitet und darüber nachdenkt. Diese Aspekte ermöglichen es Entwicklern, CSS-Plugins ähnlicher zu schreiben. etwas, das wir noch nicht erreichen konnten. Wenn das CSS-Objektmodell Ihr Interesse weckt, empfiehlt es sich, auch diese Spezifikation zu lesen.

Houdini wer?

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.

Verwenden Sie einen iFrame. Problem gelöst

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.

CSS Contain (Rettungsinsel nicht enthalten)

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.

Zyklische Abhängigkeiten: Die Container-Abfrage-Nemesis

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:

  • Es ist ein legitimes Problem, da CSS bereits darunter leidet.
  • Es gibt nichts, was Entwickler tun können, um etwas dagegen zu tun, da sie die CSS-Sprache stark umschreiben müssen.
  • Es würde einige Verbesserungen auf Browserebene erfordern.

Die gute Nachricht ist, dass Browser allmählich Beweise für die Behebung dieser Probleme aufzeigen, wie zuvor mit Houdini erörtert wurde.

Zukunftsperspektive

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 werde einen Blick darauf werfen, sobald es eine genehmigte CSS-Spezifikation ist (es könnte niemals sein ...)
  • Ich werde es nur unterstützen, wenn es von einem Browser nativ unterstützt wird (die Funktionen werden unterstützt, aber es gibt keinen Zucker speziell für Elementabfragen)..
  • Ich möchte kein JavaScript zum Styling verwenden, weil „That's Bad®“

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.

Gedanken zum Abschied

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.

Besonderer Dank

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.

Zusätzliche Links

  • Umgehen eines Mangels an Elementabfragen in der Filament-Gruppe
  • Presto-Punkte auf GitHub
  • Was zum Teufel sind Elementabfragen und Containerabfragen? von Tommy Hodgins
  • GSS: Layout wurde wöchentlich im Webdesign neu erstellt
  • Elementabfragen von Tommy Hodgins
  • eqcss auf GitHub
  • CSS-Elementabfragen auf GitHub
  • cssplus auf GitHub
  • Element Query Demos Collection auf CodePen
  • Elementabfragen und wie Sie sie heute im Smashing Magazine verwenden können
  • Houdini
  • Versand beabsichtigen: ResizeObserver