Track/align all the work that needs to be done in order to refactor the Building Blocks. Main steps: - Use OOCSS to improve the selectors (simplify) - Add cross browser mobile support (mobiles engines need to be defined) - Markup w3c-compilant - Merge `style` and `style_unstable` in one `style` folder - Move value_selectors styles (date, time, value picker) to `shared/style/` - Improve documentation about class-names usage, browser support, etc.. (via README) Extra ball (nice to have): - Gaia submodule / repo that will allow us to mantain different versions of the Building Blocks (v1, v2), speed up development, add more contributors, etc...

Hi is there any maillist or IRC to discuss about BuildingBlock related issues? Will BuildingBlock use CSS pre-processor such as compass or less for cross browser support?

Hi Fred, there is dev-gaia thread that talks about the refactor: Building Blocks refactor (was: Re: un-semantic CSS). There is also #buildingblocks in irc, i use to be there everyday, but seems no other one joins :D

Sorry I've some other thing occupied and not able to attend recent 1.2 agile meetings from Taipei. Several months ago I've made the UIDemos app and published to marketplace https://marketplace.firefox.com/app/ui-demos I've just upload the code to github and like to donate it back to building block if you interested. https://github.com/gasolin/uidemos/tree/master/public/ffosbb The good part of it is UIDemos have chunk of followable source code right after the visual widgets. Let developers can follow it easily. The cons is at that time I manually merge the style/style_unstable into style folder, and put related demo code directly into the correspondent folders right after index.html, which make I've to manually update and compare each resources.

Are we looking at performance of selectors at all with this refactoring? I ask because I noticed a few PR's above have selectors using descendents with common tag rules on the right. For example: https://github.com/mozilla-b2g/Gaia-UI-Building-Blocks/pull/69/files#L3R32 Since our devices are CPU constrained so often, I wondered if it would be worth considering selector optimization as discussed in: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS

Hi Ben, we tend to use class-based selectors as much as we can, but we need to keep a balance between performance and over-classnaming. I think we are taking a huge step from selectors like `section[role=region] > header a` to `.bb-header .action`. Let's try in this way, then we will meausre it, and if there are substantial performances improves to do, we will take care of it. Is important to do not overoptimize at the beginning of the refactor. Anyway i'm happy to see you guys are in the loop on this refactor :D Thx!

Ismael, I've added bug 886409 as dependent of this one. I've attached a proposal that suggests adding a second line to the subtitles when text doesn't fit one line. Sergi let me know you'll be looking at this as part of lists refactoring. Thanks!

(In reply to Ismael Gonzalez [:basiclines] from comment #7) > I think we are taking a huge step from selectors like `section[role=region] > > header a` to `.bb-header .action`. > Let's try in this way, then we will meausre it, and if there are substantial > performances improves to do, we will take care of it. > > Is important to do not overoptimize at the beginning of the refactor. Sounds good. Thanks Ismael!

Closing BB refactoring bugs in favor of web components, currently tracked in bug 1002417. Please re-open these bugs if there's still something specific that should be done here.