top | item 6223313

Brick – UI Components for Modern Web Apps

214 points| dkannan | 12 years ago |mozilla.github.io | reply

72 comments

order
[+] jwilliams|12 years ago|reply
Interesting, although I think the "beta" is quite literal. Seems to lack a bit of polish.

The one I was most interested in was the Date Picker, but locks up Chrome (28) and Safari (6) on my machine. http://mozilla.github.io/brick/component/datepicker/demo/ind...

[+] potch|12 years ago|reply
Hi! I work on Brick. Yes, there are still rough edges on these components, and we're putting them out there in the hopes of getting feedback and bug reports- a traditional beta.
[+] ciupicri|12 years ago|reply
It slowed firefox-23.0-1.fc19.x86_64 so much, that I thought it froze too.
[+] nogridbag|12 years ago|reply
I'm not having the freezing issue with Chrome (28). But I think there're some major usability issues. I cannot figure out how to input a date. If I input "8" then "16" it's current value is 08/16/yyyy with the "yyyy" part selected. If I continue to input "2" for the year part it changes to 1902. Inputting "20" will reset the date picker back to mm/dd/yyyy.
[+] moondowner|12 years ago|reply
Locks FF Nightly too.
[+] ssharp|12 years ago|reply
Another thing about the date picker that was at least happening on my desktop: when it expands, it expands well beyond the bounds of the mobile phone container they're using in their example:

http://i.imgur.com/oOQFBs4.png

[+] NKCSS|12 years ago|reply
Yup, has been a while since I've had to fire up IE to view something that doesn't work in chrome :P

While the page does load, it has a long running script that dies :P

[+] cateye|12 years ago|reply
I can confirm this on OSX - Chrome 28.
[+] emehrkay|12 years ago|reply
Seems fine on an older webkit nightly (the newest one, on another machine, crashes after five mins)
[+] nilsbunger|12 years ago|reply
Sounds like the "brick" is quite literal too in this case! :)
[+] bsimpson|12 years ago|reply
Works fine in ChromeOS 28.0.1500.95
[+] casual_slacker|12 years ago|reply
Looks like these are built on Polymer. (http://www.polymer-project.org/).
[+] potch|12 years ago|reply
We're actually not using the Polymer Web Components shim- it attempts to simulate Shadow DOM by overriding DOM Methods(!), which didn't seem necessary.
[+] andybak|12 years ago|reply
Yep. The web components aspect is the most interesting aspect of this. It would have been useful to put that in the post title (until a mod reverts it).
[+] csuwldcat|12 years ago|reply
Underlying Polymer's opinionated framework, there is a set of polyfills for the emerging Web Components standards - both Mozilla's X-Tag library and Polymer use these polyfills as the basis of their offerings.
[+] bpatrianakos|12 years ago|reply
This is cool and certainly useful but I have concerns. Forgetting for a moment that this is a shim and imagining that all browsers support this natively, isn't this sort of thing outside the intended purpose of html. Html should describe content not styling and this sort of thing seems ripe for abuse. I thought XML was the markup language for describing custom data. Adding the ability to create your own DOM elements for the purpose of using them as hooks for interactivity and styling seems like something that should be avoided in HTML.

Am I being a too much of a purist or overlooking something here?

[+] csuwldcat|12 years ago|reply
You're overlooking that the underlying technology - Web Components - is landing as a standard as we speak in both Firefox and Chrome. The idea that creating custom elements is inherently bad is an urban legend - there is no empirical basis for such a claim. Additionally, you are mixing metaphors, Custom Elements are not meant to describe data, they are meant to create new, active UI components and other useful tags.
[+] pennyfx1001|12 years ago|reply
Web Components is an active W3 spec. http://www.w3.org/TR/2013/WD-components-intro-20130606/

All browsers are going to support Web Components eventually and it is going to greatly expand what we thought HTML should or shouldn't do.

I think Chrome Chrome Canary has an implementation behind a flag and FF is actively working on it as well.

[+] k3n|12 years ago|reply
Isn't that pretty much the M.O. of Angular?

Not that it makes it right or wrong, but this just seems like a different take on the same (or similar) concepts.

[+] WayneDB|12 years ago|reply
I'd rather say <x-calendar/> than <div><div><div></div></div></div>.
[+] OlavHN|12 years ago|reply
These are UI elements built on top of (a shim for) the coming standard Web Components.

For another Web Components shim check out polymer-project.org along with a small, opinionated framework leveraging Web Components. Especially look at the awesome Sandbox application allowing you to compose web components :)

[+] rubyn00bie|12 years ago|reply
I think it's fucking awesome and it works like a boss in FF 24 (beta) on OS X. I'm very excited about this project only because standard UI elements are so irritating to make (after having done it hundreds of times) and the alternative libraries (in my opinion) all do too much and too little at the same time.

For everyone complaining about Chrome, I would like to say this is "beta" and "ahahahahaha."

Not to be malicious though! I just have a really shit experience on the web with a lot developers only targeting Chrome/Webkit. Like ScalaTour for instance-- a wretched experience if you're /not/ using Chrome (read unusable).

It's nice to see it go the other way for once! ;-)

[+] itry|12 years ago|reply
Calendar looks broken in FF and Chrome here. All I see is:

  21
  21
  21
  21
  21
  21
  21
  21
  21
  21
  21
According to Browsershots it looks like this on many browsers:

http://browsershots.org/http://mozilla.github.io/brick/compo...

Same with the datepicker.

Some other stuff also looks broken.

I would much prefer one piece of javascript per component. So if I liked one, I could use it and improve it. Im not so much inclined to use a library of tons of stuff I dont use.

[+] csuwldcat|12 years ago|reply
Each component is isolated in just the way you describe, the only requirement is the base X-Tag Web Component library.
[+] nilsbunger|12 years ago|reply
These are a big step forward compared to today's tangle of plugins! Much smoother and nicer to code.

On IE10 this library has no animations. Is it possible to polyfill your way to decent support with animations at least on IE10?

(I hate IE but a lot of our customers use it)

[+] SchizoDuckie|12 years ago|reply
The first example (flip widget) already does exactly nothing on Android.
[+] RossM|12 years ago|reply
Oddly enough in Chrome Stable the front face is not visible. Combined with the browser-crashing calendar demo it's got some way to go.
[+] unwind|12 years ago|reply
Counterpoint: it works perfectly on my Android device (using the standard awesomely-named "Internet" browser).
[+] potch|12 years ago|reply
We've pushed a stopgap fix to the calendar code to stop it from hanging while we investigate/repro the issue.
[+] rafaelferreira|12 years ago|reply
At first glance, the intent seems quite similar to Google's Polymer project. Hopefully they will interoperate.
[+] drudru11|12 years ago|reply
With this and Polymer, I think the whole idea of software components might actually happen. I cannot wait for this to happen. Having this stuff would be great!

Thanks to the people behind HTML5 for kicking off the innovation.

Thanks to the team that put this together at Mozilla. I went to the demo page and things just worked.

[+] thousande|12 years ago|reply
Ah! It continues Web Components are the most exciting thing on the Web at the moment. I can not wait until this is fully supported in the browser.

There is a lot of great JS frameworks out there that projects DOM etc., but I always fall back to markup as the best way to build a browser based app

[+] cliveowen|12 years ago|reply
The date picker actually froze Chrome and slowed everything to a crawl. Way to go Mozilla.
[+] epmatsw|12 years ago|reply
Interesting. In Chrome Canary, the polyfilled text input is working fine, but the native date input is freezing.
[+] ldoubleuz|12 years ago|reply
For those of you reporting crashes in calendar/datepicker, can you please indicate what region you are in (UK, etc)? The issue is most likely caused by non-American date formats, and we are working on a fix.
[+] ebbv|12 years ago|reply
While I understand the desire for custom HTML elements I'm also certain they are going to result in monstrosities.

It's not the tool's fault, in the end. But it is opening up a basket of horrors.

[+] utopkara|12 years ago|reply
Excellent! Didn't know about web components. Are there any big blockers that would prevent libraries like jQuery Mobile moving into this?
[+] phpnode|12 years ago|reply
yeesh, I respect Mozilla for their true open-source-everything-all-the-time philosophy but this is an example where I think it backfires - it's too early! Even if these really are awesome components it's really hard to see past the lack of polish. People are fickle and you only get one chance to make a first impression, it's important that these things look good
[+] daleharvey|12 years ago|reply
I dont believe it backfires. People are fickle, you get lots of chances to make a first impression.

I think the key is clarity in your communication, doing a lot of polish on top of unstable software and advertising it as stable causes people to waste time using it, advertising as beta / for early adopters lets the early adopters pick it up and the people who just want it to 'just work' can wait. If you lose a few people who dont understand the benefits still far outweight the negatives.

This is mostly just a disclaimer for people who are waiting to open source their software until 'its ready', its never ready, do it now.

[+] potch|12 years ago|reply
We were torn whether to call the current state of things alpha or beta, but yes, these are not ready for prime time. Where we and some other orgs disagree is that things should be kept secret until they're 'ready', when outside contributions could help you get them ready!
[+] davexunit|12 years ago|reply
It's never too early. Develop in the open. Make an official release when it's ready. The site makes it perfectly clear that it's in a Beta state.