@mailpravink there might be easy way to do it (like in some way e.preventDefault()), so you could try listening for some focus-like events, but since the behaviour may be somwhat platform dependent (I remember there being some platform inconsistencies) it may not work out of the box. I could be wrong but you could still try that. If it works then everything is perfect.
A somewhat related topic can also be found here.
So maybe there are plugins which may help, otherwise a hacky way would be trying to focus it again, but it may not work very well either.
And a final option would be thinking if you really need the feature - I think skype and most other chat apps do hide their keyboard when the user focuses out. On some phones the keyboard takes almost the whole screen (especially in landscape), so you should probably still give the user at least some way to hide it imo.
Sorry if my answer wasn’t very helpful. I hope you find a solution - if you do feel free to share it here again :) Good luck! ;)

@Dennis-Ferreira You are correct. That’s precisely how it should be used. The reason why there is not much documentation about it is because it’s just a media query and I guess we expect people who want to use media queries to know how to write them.
On another note - this is actually the documentation for ons-split-view from Onsen 1, in Onsen 2 there is a component ons-splitter which is a little better. When the ons-split-view collapses there is no way to open it until the expression becomes false, whereas in ons-splitter it becomes a sliding menu, which is seems more logical imo.

When item-width < 100%, it seems the first and last carousel items can’t be ‘selected’ (meaning the postchange event doesn’t fire for these elements).
As a workaround, I’m thinking along the lines of adding dummy items on each end of the carousel, and maybe detecting these edge items as an overscroll rather than a postchange (not sure if this would work, I haven’t had time to test this yet), and handle that event in order to automatically re-select the nearest non-dummy item.
Are there any known workarounds?
edit: My workaround idea doesn’t work right. The carousel kind of settles on the first or last list element, as if it was selected, without it actually being selected in terms of activeIndex/postchange, nor is overscroll triggered unless the user goes out of his/her way to do it.

@Vincent-Bastos Well actually they are centered by default. Here’s a demo.
Most likely you have some sort of style which is overriding the default one.
You should be able to fix it by writing
.tab-bar__button {
text-align: center;
}
in a css file and include it. Alternatively you could just write style="text-align: center" in the ons-tab elements.

@Fran-Diox Thats great! My problem is, I get all the GH updates in email so I read those and then I forget which issue I read, so sometimes going back and finding the new way to do something is difficult. I will say though, I have learned so much about Onsen reading the internal comments of you guys working on Onsen. It is so much fun right now!
You guys are super impressive and I am learning a lot - even on coding things I have done for years. Just super amazing stuff, :bowtie:

@serdarde Which version are you using? I noticed a bug like this but I think it was fIxed in beta.8. If you can make a Codepen example we could test it easier. About the textarea, you can resize it as any other HTML textarea. Just drag it :sweat_smile:

@markarupert You can style .popover__top-arrow { display: none; } if you don’t want the arrow. There is a modifier="android" that also hides the arrow, and from beta.8 you have modifier="material" that is like a dropdown menu (and scrollable).

@shubhanan - thank you for your activity. About using the itemScope - linking the height function to that might affect the performance. The current implementation recalculates the heights if the items count changes, however it does not keep the scopes alive for all the items but rather only for the ones visible in the viewport. So to add that functionality it would need to recreate them or at least call the configureItemScope function, which will probably worsen the performance. Overall it’s best if the logic for calculating the dynamic height is as simple as possible.
Still if you have any suggestions for improvements for the API we would be happy to hear them.
@lezard - currently we don’t offer an API for switching the current index. Lazy repeat was made with the user scrolling in mind, not us navigating. We may think about adding it in the future, but I’m not sure if we should encourage users to do that.
If you want you can just manually scroll to the top. Something along the lines of
// Pure JS
document.querySelector('.page__content').scrollTop = document.querySelector('#lazy-list').offsetTop;
// jQuery
$('.page__content').scrollTop($('#lazy-list').offset().top);
$('.page__content').animate({scrollTop: $('#lazy-list').offset().top}, 250);
// Angular
$anchorScroll('lazy-list'); // 1.4.0+
angular.element('.page__content')[0].scrollTop = angular.element('#lazy-list')[0].offsetTop; // earlier versions
This is assuming you have only one page and that the parent of the element with the ons-lazy-repeat attribute has an id lazy-list.

@davidfherrerar The “parameter as an option” that you mention is just for the animation and some other information but not for custom data, so in general there is no need to get the parameter back in the new page. You can save data on page’s hide or destroy events and apply it to the new page on init or show events.