Mozilla Hacks

Introducing Brick: Minimal-markup Web Components for Faster App Development

Avatar photo By Leon Zhang, Robert Nyman [Editor emeritus]

Posted on August 27, 2013 in

Those of you on the cutting HTML5 edge may have already heard of the exciting Web Components specification. If you haven’t, you’ll probably want to read up on what makes this so exciting, but long story short, Web Components promise to open up a new realm of development by letting web developers write custom, reusable HTML tags. Think of them as JavaScript plugins without the need for additional code initialization or boilerplate markup/styling.

Unfortunately, it will be a while before we see native browser support for the spec, but that doesn’t mean developers can’t start taking advantage of the component concept now, thanks to Google’s Polymer framework and Mozilla’s x-tags polyfill library (both X-Tag and Polymer share the same low-level, Web Component polyfills).

We’re proud to announce the beta release of Brick, a cross-browser library that provides new custom HTML tags to abstract away common user interface patterns into easy-to-use, flexible, and semantic Web Components. Built on Mozilla’s x-tags library, Brick allows you to plug simple HTML tags into your markup to implement widgets like sliders or datepickers, speeding up development by saving you from having to initially think about the under-the-hood HTML/CSS/JavaScript.

Putting Brick into Action

Say that you wanted to implement a cross-browser, mobile-friendly calendar widget in your application. With current JavaScript plug-ins, such as jQuery UI, this would require putting boilerplate, non-semantic markup into your HTML, as well as explicitly initializing and managing it through JavaScript. However, with Brick, you can implement such a component simply by adding a custom HTML tag that you can treat as a normal native tag.

For our calendar example, this means just including the library’s CSS and Javascript file in your application, then adding the following tag to your markup:

which creates a DOM element that looks like this:

Want to edit how the component behaves, such as by adding navigational controls or pre-selecting a date? Like any other native tag, you can change how a component behaves just by changing the attributes of the tag!

Available Bricks

At the time of writing, Brick consists of thirteen different tags, most of which are completely independent of one another, and can even be downloaded separately instead of a single bundle.

Some tags abstract away complex widgets into simple HTML tags, such as:

Others are cross-browser polyfill implementations of existing native not-yet-globally-supported elements, such as:

which polyfill <input type="range"> and <input type="date">, respectively. Still others are structural components simplifying the styling and markup of certain components, such as <x-layout>, which ensures that content, headers, and footers can fill a container element without explicit styling markup.

Each tag comes with a flexible attribute/JavaScript API and can be fully styled to match your application.

Start Building with Bricks

Want to start using components in your own applications? Head to mozilla.github.io/brick to download a release bundles, view demos, and read the documentation for the available tags. Alternatively, visit the Brick Github page to view the source code and contribute to the effort!

The library is still in a beta release, so we appreciate all user feedback! Brick is already starting to crop up in the wild, so we’d love to hear about how you’re using it!

About Leon Zhang

I am a Mozilla WebDev Intern working with the Apps/DevEcosystem team for Summer 2013. I'm currently a student at Carnegie Mellon University, where I study Computer Science/Human Computer Interaction.

More articles by Leon Zhang…

About Robert Nyman [Editor emeritus]

Technical Evangelist & Editor of Mozilla Hacks. Gives talks & blogs about HTML5, JavaScript & the Open Web. Robert is a strong believer in HTML5 and the Open Web and has been working since 1999 with Front End development for the web - in Sweden and in New York City. He regularly also blogs at http://robertnyman.com and loves to travel and meet people.

More articles by Robert Nyman [Editor emeritus]…

45 comments

  1. Lech Rzedzicki

    You mean like XUL or well more generally XML? ;)
    The wheel keeps getting reinvented :/

    August 27th, 2013 at 06:50

    1. Potch

      XUL components are powerful, but limited to Gecko rendering. Brick (and the Web Component specification) is a particularly nice re-invented wheel. Imagine if we still trundled on wooden spokes!

      August 27th, 2013 at 13:15

    2. T

      Reinventing the wheel is a good thing. If done well, technology evolves, but either way it is representative of passion to move forward; to fend off complacency. I actually pose this question in interviews to see how the person thinks to get an idea of culturally, as well as technologically, how the candidate thinks. There’s a happy medium to be had, but we simply cannot throw iteration to the wayside.

      August 28th, 2013 at 16:30

      1. Robot

        When you’re older, you will understand complacency well

        August 30th, 2013 at 10:39

      2. Rand McRanderson

        Fair enough, but there is a difference between iteration and discarding what has come before.

        Part of this comes down to, are the skills that you use with this technology useful for the next iteration, or can they be mutated some how to become useful with this next iteration. Otherwise, this tech is nice to play with, but is not production ready.

        September 2nd, 2013 at 09:44

  2. Phunky

    Has there been any discussions on how to handle media-query type functionality in web components yet?

    It would be good to get that baked in from the start!

    August 27th, 2013 at 06:56

    1. Potch

      This is something we’re thinking about actively. Some components will definitely benefit from different styles at different screen sizes- for instance.

      August 27th, 2013 at 13:17

      1. Phunky

        Think more of RESS instead of RWD.

        August 29th, 2013 at 02:43

  3. Phunky

    I’ve never used XUL so can’t comment, but there will be a case where needs to be different for devices and surely native support for this would be better.

    August 27th, 2013 at 07:04

  4. bardu

    Would you guys recommend using Brick on Firefox OS?

    August 27th, 2013 at 08:03

    1. Angelina Fabbro

      Yes, definitely – we did a Firefox OS workshop this weekend in Porto Alegre, Brazil and I taught everyone about Brick with a demo app. Perfect use case.

      August 27th, 2013 at 10:23

      1. bardu

        @Angelina: Is your demo app somewhere available? Is it running on an actual device or in the emulator?

        August 27th, 2013 at 15:28

      2. romulo santos

        I was there, at the end my team ended up with twitter bootstrap. We were in a rush and I was working on the REST backend so I really don’t know why they took that decision. Now I’m redoing the app from scratch and decided to give brick another chance.

        September 15th, 2013 at 12:11

    2. Potch

      Definitely! We’re building the components for use in any webapp environment, Firefox OS included.

      August 27th, 2013 at 13:13

  5. Ted Drake

    How is the web component x-calendar better than using HTML5 form type=”date”? Will they ultimately generate the same calendar picker by the OS? Or will the generate a free-standing calendar that is independent of an input?

    August 27th, 2013 at 08:04

    1. Leon Zhang

      Hi Ted,

      For datepickers, we actually provide a tag that uses x-calendar in the way you describe.

      Essentially, it will default to using the native input type=date element if the browser supports it, and it will generate a standalone polyfill otherwise. You also have the option of forcing the polyfill to render in case you want a consistent UI regardless of native support.

      You can find more details here: http://mozilla.github.io/brick/

      August 27th, 2013 at 14:17

      1. Leon Zhang

        Oops, wrong link, I meant this: http://mozilla.github.io/brick/demos/datepicker/index.html

        August 27th, 2013 at 14:18

    2. Potch

      datepicker and slider are polyfills, so we will fall back to the native input[type=date] and input[type=range] whenever the system provides a native version of the controls. Calendar provides a standalone calendar independent from an input.

      August 27th, 2013 at 14:47

  6. Gerardo Capiel

    As with much tech innovation, it’s a double edged sword for people with disabilities and Brick could be the one of best or worst things ever. I hope the Brick community is building in accessibility from the start. I highly recommend reviewing and leveraging Bryan Garaventa’s open source work on accessible web components:

    http://whatsock.com/modules/aria_calendar_module/demo.htm

    https://github.com/accdc

    August 27th, 2013 at 08:45

    1. Potch

      We are working with the Mozilla accessibility team to ensure that by stable release, Brick components will be highly accessible. If you see any issues in particular with accessibility please let us know.

      August 27th, 2013 at 14:53

  7. James Meldrum

    Why the x- prefix?
    Javax?
    Xemacs?

    Good start.

    August 27th, 2013 at 09:05

    1. Fred

      x- stems from “x-tag”, Mozilla’s web components polyfill + library (http://www.x-tags.org/).

      The web components standard that all this is built on requites a dash to be in a custom element name.

      August 27th, 2013 at 13:56

  8. Aras

    This is very exciting and long overdue! I am so happy to see a sensible UI solution like this is emerging for the web. Will definitly give bricks a try. Thank you for this great article!

    August 27th, 2013 at 12:04

  9. PixnBitsOrg

    Sounds a lot like Angular’s directives: http://docs.angularjs.org/guide/directive

    August 27th, 2013 at 13:08

    1. Potch

      They are very similar to ng-directives in the ability to provide new functionality via markup. However, the interface to these components is independent from any framework. In fact, you could easily mix Brick components into Angular apps, and interface with them using angular.element just as you would any other HTML element.

      August 27th, 2013 at 14:49

  10. Igor Costa

    Finally Web developers will have the power of componentization to increase chance of better performance and better code quality.

    On the other hand, Apache Flex took that step 9 years ago, problem just remains on FP for render. Hope soon Bricks becomes a standard to the market.

    August 27th, 2013 at 14:07

  11. Nobody

    Finally, you’ve caught up with IE 5’s behaviors!

    August 27th, 2013 at 14:44

    1. Richard

      My thoughts exactly! But it was 5.5, not 5.0, and they’ve been removed in IE10.

      http://msdn.microsoft.com/library/ie/ms531426.aspx
      http://msdn.microsoft.com/en-us/library/ie/hh801216%28v=vs.85%29.aspx

      August 28th, 2013 at 12:33

    2. Potch

      Happy to finally catch up in a way that works cross-browser and is open source!

      August 29th, 2013 at 11:27

  12. Alexander Voronin

    XAML browser edition? Nice..

    August 27th, 2013 at 23:53

  13. Mark McDonnell

    I have two concerns with Web Components:

    1.) What happens if you load two components, both of which use a library such as jQuery, does jQuery get loaded twice?

    2.) Will we see these components being abused much like the jQuery plugin era where inexperienced developers where releasing badly written plugins by the truck load and we had plugin overload. Imagine a junior developer deciding to write their own calendar widget by loading in the full fat jQuery as well as jQuery UI and then releasing that as a Web Component. Disastrous performance implications for doing that.

    That second point isn’t a problem with Web Components itself but definitely a concern worth having regarding where this will lead in future if the developer community is not given the appropriate guidance on what NOT to do with this feature.

    Regarding point 1.) I’d love to know how this scenario is (or will/should be) handled?

    Thanks.

    August 28th, 2013 at 01:19

    1. Potch

      1) The core Brick components all share a common dependency core, which is only included once in a bundle. If you’re pulling in additional components or individual Brick elements, they will be available on Bower, a js/css package manager. Bower handles dependency management, and will only download a given dependency once even if multiple components require it.

      2) The beauty of the web is that you’re free to write code, good and bad. Brick as a component library/bundle will try to lead by example, establish best practices, and curate our components to a set that behaves well together.

      August 29th, 2013 at 11:31

  14. Semih Akalin

    Interesting. How does one begin to integrate this type of markup with something like Ember or Angular?

    August 28th, 2013 at 03:47

  15. Ok

    I guess this could replace jquery? I can’t keep up with all these new developments.

    August 28th, 2013 at 07:00

    1. Potch

      This doesn’t seek to replace jQuery, though it could easily replace jQuery UI. Brick serves to sit along side existing web frameworks and is designed to work seamlessly with them by exposing all its functionality via the DOM as opposed to a new proprietary API. For example, to interact with an x-calendar in jQuery, you could say `$(‘x-calendar’).attr(‘chosen’, ‘2013-08-27’);` and that will work exactly how you would expect!

      August 29th, 2013 at 11:34

  16. Zach Moreno

    “At the time of writing, Brick consists of thirteen different tags…”

    I believe the author meant “…thirteen different elements…”
    As defined here – https://developer.mozilla.org/en-US/docs/Web/HTML/Element

    August 28th, 2013 at 08:03

    1. Potch

      The ‘Custom Element’ and ‘Web Component’ monikers get conflated a lot, but yes, technically we’re working with the Custom Elements portion of the spec.

      August 29th, 2013 at 11:35

  17. mintypoohs

    http://html6spec.com or this…. joke.

    August 28th, 2013 at 10:14

  18. garbas

    very similar what PatternsLib is trying to do (just different syntax) http://patternslib.com

    August 28th, 2013 at 11:06

  19. niutech

    Awesome, this could be called HTML6! No need for external libraries like jQuery UI to make widgets, just type plain HTML tags, e.g.: x-tabbar, x-slidebox, x-slide, x-accordion, x-tooltip, x-modal, x-datepicker and run brick.js.

    I hope it will be compatible with Polymer UI Elements.

    August 28th, 2013 at 15:21

    1. Zach Moreno

      There will never be an HTML6, as the HTML spec will just continue to evolve agnostic of a version number. Hence the new doctype with no versioning defined.

      August 29th, 2013 at 13:56

      1. niutech

        No, the HTML spec is numbered, the latest being HTML5.1: http://www.w3.org/TR/html51/ so eventually there will be HTML6 and it may consist of custom elements such as web components.

        August 30th, 2013 at 15:05

        1. Rand McRanderson

          The key thing is that without a doctype, there is nothing to distinguish an HTML6 doc vs an HTML5.

          My advice for an html processor is to just assume that every tag you don’t know is something that could be legitimate. After all, there might be an update to the html spec while you were on vacation.

          September 2nd, 2013 at 09:48

  20. pd

    Why can’t you just fast forward the process of building better common widgets into HTML5? It’s completely ludicrous how much the community bangs on about the open web as a ‘platform’ when there’s so few meaningful tags standardized and supported across all browsers. How long have datepickers been available to desktop developers as a simple widget? Probably three decades and yet these are still not available natively in HTML. Instead browser developers place their focus on all sorts of other areas.

    These x-tags are potential helpful but really, the developer community have already supplied a very similar version of these widgets in the form of jQuery UI for example. Ok so you don’t need to know the basics of JavaScript objects to initialize the x-tags, with attributes available instead. That’s handy but a separate library file is still required, the same as jQuery UI does.

    HTML5 is such an over-hyped standard in that it’s really very under-ambitious when it comes to expanding the number and quality of simple tags available to developers.

    September 8th, 2013 at 10:10

    1. niutech

      Well, just HTML wasn’t meant for web apps, but for web pages. Hence a lack of builtin complex widgets, although a datepicker is available as an input tag. Others you can build from basic tags like divs and buttons.
      Second, HTML is a static language, so you have use JS to add behavior (even if it’s hidden inside an x-tag). Keep in mind, that the web is backward compatible, so you have to rely on JS.
      I think x-tags and web components are steps in a good direction, towards more modular web pages and faster loading times (components should be cached).

      September 8th, 2013 at 16:22

Comments are closed for this article.