8 Reaktionen

Mozilla Brick 2.0: Neustart des Projektes

Geschätzte Lesedauer:

Mit den Web Components befindet sich eine Webtechnologie in der Standardisierung durch das W3C, welche es Webentwicklern erlaubt, eigene HTML-Elemente für Webanwendungen zu bauen. Mit Brick entwickelt Mozilla eine auf Web Components basierende Sammlung wiederverwendbarer UI-Komponenten, deren Version 2.0 vor kurzem angekündigt worden ist.

Mozilla Brick ist eine Sammlung von UI-Komponenten, welche cross-browser-kompatibel und im März als Version 1.0 veröffentlicht worden ist. Im offiziellen Blog des Projektes gab es einen Ausblick auf die kommende Version 2.0. Brick 2.0 wird mehr oder weniger ein Neustart des Projektes sein, welches dann nicht länger auf X-Tag – einer von Mozilla entwickelten Polyfill-Bibliothek – aufbaut. Stattdessen werden die platform.js-Polyfills von Google Polymer genutzt und die Brick-Komponenten im „Vanilla“-Style geschrieben, sprich direkt die standardisierten APIs angesprochen. Ziel sei ein leichtgewichtigeres, mehr modulares Brick, zu welchem es außerdem einfacher sein soll, Code beizusteuern.

[lightbox style=“modern“ image_path=“https://www.soeren-hentzschel.at/wp-content/uploads/brick-2-0.png“ popup=“https://www.soeren-hentzschel.at/wp-content/uploads/brick-2-0.png“ link_to_page=““ target=““ description=““ size=“two_col_small“]

Mit Web Components sind Webentwickler dazu in der Lage, eigene HTML-Elemente zu bauen, welche in der Anwendung wiederverwendet werden können. Eines der Bricks ist beispielsweise ein Kalender. Eine Zeile wie <x-calendar controls chosen=’2012-05-17′></x-calendar> reicht, um einen Kalender in die Webanwendung zu integrieren. Weitere Widgets, welche Brick bereitstellt, sind unter anderem eine Tab-Leiste, ein Slider oder auch Tooltips. Mit den Bricks kann ein Entwickler viel Zeit sparen, da er sich keine Gedanken um das HTML/CSS/JavaScript dahinter machen muss. Die Widgets von Brick sind mit allen aktuellen Browsern kompatibel und mobiltauglich.

Unabhängige Berichterstattung unterstützen.

Unterstütze wirklich unabhängige und Fakten-basierte Berichterstattung zu Mozilla, welche nicht das Ziel hat, Schlagzeilen zu produzieren, sondern objektiv zu informieren.

Dieser Artikel wurde von Sören Hentzschel verfasst.

Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, firefoxosdevices.org sowie sozone.de.

8 Kommentare - bis jetzt!

Eigenen Kommentar verfassen
  1. schrieb am :

    Der erste Link ist bei mir tot.

    https://mozbrick.github.io/ ?

  2. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Hmpf, ja. Danke, werde ich korrigieren.

  3. Blueray
    schrieb am :

    Hm, auf der einen Seite wirbt man für mehr Standardisierung bei W3C, andererseits dann wieder solche „Spielwiesen“- ich übertreibe mal bewußt …

    Sofern sich solche Dinge verbreiten und das Netz „durchsetzen“ käme eine spätere, zeitversetzte Übernahme als Standard infrage, oder ? Als Knackpunkt sehe ich die crossfähige Nutzung bei allen Browsern, oder ist das eher eine kopfgemachte Problematik ?

    Ich nutze andere Sachen außerhalb FF kaum noch bzw. selten und bewußt nur um vermutete fehlerhafte Seiten durch andere Browser zu testen, daher hinke ich mit Sicherheit hinterher …

     

  4. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Hm, auf der einen Seite wirbt man für mehr Standardisierung bei W3C, andererseits dann wieder solche “Spielwiesen”- ich übertreibe mal bewußt …

    Sofern sich solche Dinge verbreiten und das Netz “durchsetzen” käme eine spätere, zeitversetzte Übernahme als Standard infrage, oder ?

    Web Components sind bereits auf fortgeschrittenem Weg, Standard zu werden. Brick sind UI-Komponenten, welche in Form von Web Components umgesetzt sind.

    Als Knackpunkt sehe ich die crossfähige Nutzung bei allen Browsern, oder ist das eher eine kopfgemachte Problematik ?

    Hier kommen sogenannte Polyfills ins Spiel. Die Aufgabe eines Polyfills ist es, Kompatibilität mit Browsern herzustellen, welche das nicht nativ unterstützen, hier kommt platform.js von Google Polymer zum Einsatz, Kompatibilität siehe:

    http://www.polymer-project.org/resources/compatibility.html

  5. Kerob
    schrieb am :

    Hier verstehe ich nicht, warum man HTML nicht gleich zu SGML bzw. zu XML erweitert. Das ist doch nur Symptombehandlung. Einfacher wäre es, wenn man gleich xml zu ließe und zwar nur mehr valides. Das würde diese ganzen Quirksmodes auch aufräumen und all die „ich schuster mir mal ne Webseite in 1-2 Stunden mit Klickibunti-Editoren zusammen“-Leute schön dazu zwingen die Sprachen ordentlich zu lernen oder aufzugeben 🙂

  6. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Mir ist nicht klar, welches Symptom genau du meinst, dass es durch Brick behandelt würde, und inwiefern XML irgendetwas vereinfachen würde.

  7. Kerob
    schrieb am :

    Dann schau dir mal das Ökosystem rund um XML an. (XPath, XQuery, XSLT, …)

    Abgesehen davon ist es in XML gar kein Problem einfach <my-awesome-element> zu bauen 🙂

  8. Sören Hentzschel Verfasser des Artikels
    schrieb am :

    Dann schau dir mal das Ökosystem rund um XML an. (XPath, XQuery, XSLT, …)

    Das kenne ich, das war auch ein Semester Inhalt meines Studiums. 😉 Meine Frage war, inwiefern das in dieser Sache irgendetwas vereinfachen würde.

Und jetzt du! Deine Meinung?

Erforderliche Felder sind mit einem Asterisk (*) gekennzeichnet. Die E-Mail-Adresse wird nicht veröffentlicht.
  1. Nach Absenden des Kommentar-Formulars erfolgt eine Verarbeitung der von Ihnen eingegebenen personenbezogenen Daten durch den datenschutzrechtlich Verantwortlichen zum Zweck der Bearbeitung Ihrer Anfrage auf Grundlage Ihrer durch das Absenden des Formulars erteilten Einwilligung.
    Weitere Informationen