Es gibt zwei gegensätzliche Ansichten zur Verwendung von neuen, nicht-polyfillbaren Web-Features, die meiner Meinung nach beide in unserer Branche gleichermaßen verbreitet sind.
- Websites müssen nicht in jedem Browser gleich aussehen. Das Konzept der progressiven Verbesserung hilft dabei. Es gibt Werkzeuge, sogar native Sprachfunktionen, die dabei helfen.
- Wenn die Browserunterstützung nicht dort ist, wo ich sie haben möchte, ist es nur exotisches Augenfutter für Demos und nicht zur Verwendung gedacht.
Ich bin mir nicht sicher, ob ich sagen würde, dass die eine oder andere dieser Aussagen mehr oder weniger richtig ist als die andere.
Ich stelle mir auch vor, dass es keine große Überraschung ist, dass ich die Denkweise hinter #1 unterstütze. Es ist durchaus möglich, Dinge zu entwerfen und zu implementieren, die sich in verschiedenen Browsern und Bedingungen unterschiedlich verhalten. Das ist im Wesentlichen responsives Design, und das ist ziemlich das gesamte Internet heutzutage.
Das Rückgrat der progressiven Verbesserung ist, mit einer funktionierenden Grundlage zu beginnen, die überall funktioniert, und darauf aufbauend Design und Funktionalität zu schichten, wenn möglich. Es gibt sogar native Sprachfunktionen, die diese Idee unterstützen. @supports Regeln erlauben uns, CSS zu schreiben, das etwas tun kann, wenn ein Feature unterstützt wird, und etwas anderes, wenn nicht.
Das ist der gesamte Anwendungsfall für Modernizr und es hat 22.804 Sterne.
Ich möchte nicht gegen progressive Verbesserung argumentieren. Denken Sie daran, ich sagte gerade, dass ich diese Denkweise unterstütze. Aber ich habe etwas Empathie für Leute und Teams, die sich entscheiden, diesen Weg nicht zu gehen und sich stattdessen für eine #2-Haltung entscheiden.
Es ist ein bisschen mehr Arbeit, Features zu entwickeln und zu entwerfen, die auf unterschiedliche Weise funktionieren. Es mag Arbeit sein, die absolut lohnenswert ist. Oder auch nicht. So oder so, es kompliziert die Dinge. Es ist mehr Code, es erfordert mehr Aufmerksamkeit und Tests, und es ist etwas schwieriger zu durchdringen. Es ist technische Schuld.
Lassen Sie mich wieder präventiv defensiv sein: technische Schuld kann in Ordnung sein und sogar beabsichtigt. Wir alle nehmen sie bei allem, was wir bauen, auf uns. Mein Punkt ist, dass es hilfreich ist, klug damit umzugehen und eine Menge technischer Schuld auf sich zu nehmen, die Sie auf Dauer pflegen können.
Sie könnten argumentieren, dass der Aufbau auf einer Grundlage der progressiven Verbesserung im Grunde weniger technische Schuld bedeutet, da Sie auf einer so stabilen Grundlage aufbauen, dass weniger Tests und ständige Pflege erforderlich sind. Vielleicht!
Ich verstehe das Verhalten eines #2. Es fühlt sich sicherer an. Es fühlt sich an, als ob man vorsichtig und verantwortungsbewusst ist. „Hey, das ist nett“, denken Sie. „Ich werde in ein paar Jahren darauf zurückkommen, um zu sehen, ob ich es wirklich nutzen kann.“ Ich könnte argumentieren, dass 1) das keinen Spaß macht und 2) fast kontraintuitiv bedeutet, dass Sie nicht bereit sind, einen Ansatz der progressiven Verbesserung zu verfolgen, der Ihren Code letztendlich zerbrechlicher machen könnte.
Es kommt darauf an, nehme ich an. Es kommt darauf an, was genau Sie tun möchten. Es kommt auf das Gewicht dieser technischen Schuld an. Es kommt auf das Team und die Rate des Entwicklerwechsels an. Es kommt auf die Dokumentation an. Es kommt auf Tests und QA an.
Machen Sie Ihr Ding.
Genau!
„Browserunterstützung ist nicht dort, wo ich sie haben möchte“
Seien wir brutal ehrlich, meistens reden wir hier über den Internet Explorer & seinen Cousin Edge.
Meiner Meinung nach haben wir als Webentwickler nicht nur die Freiheit, sondern die Verpflichtung, diese IE-nicht unterstützten Features trotzdem zu nutzen.
Ein Hauptprinzip eines gut ausgeführten UX-Designs ist Vorhersehbarkeit, die auf die Erwartungen der Nutzer eingeht und diese anpasst.
Für Internet Explorer-Nutzer gehören verzerrte Layouts und kaputte Funktionen zum Internet-Navigieren dazu. Graceful Degradation kann zu Verwirrung führen oder für Ihre IE-Nutzer sogar ein schockierendes, traumatisierendes Ereignis sein.
Tragen Sie nicht zu ihrem Leid bei. Nutzen Sie diese neuen Features. Brechen Sie den IE. Das ist Ihre moralische Pflicht.
(Es sei denn, Ihr Kunde bittet speziell um IE-Unterstützung und bezahlt gut dafür.)
Ich würde argumentieren, dass, wenn Sie davon ausgehen, dass ein Ansatz immer der richtige ist und ihn auf absolut jedes Projekt anwenden, das Sie machen, Sie es dann bereits falsch machen.
Ich habe immer noch Schwierigkeiten mit manchen Kunden und manchen Designern, die nicht verstehen, dass eine Website in den verschiedenen responsiven Zuständen (Telefon, kleines Tablet, großes Tablet, Desktop) unterschiedlich aussehen kann und wird.
Ich werde mich nicht auf die Diskussion einlassen, dass eine Website in verschiedenen Browsern unterschiedlich aussieht. Das Versäumnis, dies zu tun, lässt sie glauben, ich könne die Mängel eines Browsers nicht umgehen.
Es gibt Kämpfe und es gibt andere Kämpfe. Diesen Kampf werde ich aufschieben, bis er gewinnbar ist.