Carousel component. A carousel can be used to display several items in the same space. The component supports displaying content both horizontally and vertically. The user can scroll through the items by dragging and it can also be controlled programmatically.
Click here to see the original article
Why is modifier not supported for this element? It seems to contradict the manual stating that all elements accept a modifier.
@Morten-Barklund I would believe this to be, because carousel is a navigation element and not a style element. Your templates that the carousel displays can accept modifier though.
@munsterlander but that doesn’t change the fact that the
<ons-carousel>element is part of the DOM and might require styling (e.g. display, width or height) that I can’t just apply to the children only and expect it to work. I have the same problem with
<ons-input>and several other elements.
@barklund You are correct and that is why you can use
styleto do those things.
Modifieris nothing more than a shortcut to
styleand allows preconfigured classes which you can also replicate with
styleand their actual CSS attributes.
What is not working with an input?
styleis bad for SoC. I know I can use
classdirectly, but why support modifier somewhere and not everywhere? A button is a navigational element as well, and it supports modifier. I can create my own BEM-like class names, but why mix built-in BEM naming via modifier with my own custom naming via class? It just seems weird and inconsistent.
On top of that, I have some local annoying DOM-building framework that renames
classnamefor non-standard DOM elements, and I can circumvent that for most elements by using modifier, but not for all. I have a work-around now, but it is just that – a work-around. Having BEM styling for all elements “natively” supported seems like the consistent choice.
Given this is the documentation for carousel, discussing input seems counterintuitive here, but
<ons-input modifier="foo">does not apply a
input--fooclass to the outer
<ons-input>element – only to the inner
<input>element – which again is not enough to fully style the component.
@barklund I understand what you are saying and agree in regards to separation of concerns. I would say that I would think the intent of modifier was to provide some canned classes and an easy way to implement them with exposing contradicting user styling via the style attribute.
I would be interested in why, as far as SoC goes, you think using
style="classname"is worse than using
modifier="classname"? In my opinion, they are the same thing. Now, I would agree that if the Onsen team implements something for one element, it would be nice for it to be consistent across all the elements.
Having said that, since navigator is their base navigation element (like the carousel), they are consistent in not having modifier.