Live data from Hacker News

Brick – UI Components for Modern Web Apps

mozilla.github.io

31–40 of 78 posts

Re: Brick – UI Components for Modern Web Apps

#31

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

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.

Re: Brick – UI Components for Modern Web Apps

#33
post #14

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

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

That likely won't happen on your real phone :) Thanks though! I'll file an issue for that if one hasn't already been.

Re: Brick – UI Components for Modern Web Apps

#34
post #11

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

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!

Re: Brick – UI Components for Modern Web Apps

#35

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…

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.

Re: Brick – UI Components for Modern Web Apps

#36

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…

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.

Re: Brick – UI Components for Modern Web Apps

#37
The folks working on the components are going to be incorporating all this feedback and reporting going forward. Everyone is encouraged to file bugs with the repo here: https://github.com/mozilla/brick/issues

Just an FYI - Mozilla will be employing this highly technical problem resolution strategy to ensure a high level of quality prior to official release: http://www.youtube.com/watch?v=yo3uxqwTxk0

Re: Brick – UI Components for Modern Web Apps

#38

Looks like these are built on Polymer. ( http://www.polymer-project.org/ ).

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.

Re: Brick – UI Components for Modern Web Apps

#39
post #12

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

I can confirm this on OSX - Chrome 28.

I'm also running Chrome 28 (Version 28.0.1500.95) on Windows, but everything is running fine. I'm wondering if Chrome itself is locking up, because the calendar demo is has only one demo of the polyfill picker, the rest are the native calendar that it uses when it detects it is available.

Re: Brick – UI Components for Modern Web Apps

#40

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

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.

I believe you are describing the native datepicker, I am seeing the same weirdness. Be advised, the calendar polyfilled calendar is only active when a native implementation is not detected, or you force it to be used. This may be a bug in Chrome itself.
Post reply on HN