Direct manipulation of checked

The checked attribute of an Checkbox object should always be set
through the Ember object or by interacting with its rendered element
representation via the mouse, keyboard, or touch. Updating the value of the
checkbox via jQuery will result in the checked value of the object and its
element losing synchronization.

Layout and LayoutName properties

Because HTML input elements are self closing layout and layoutName
properties will not be applied.

ariaRolepublic

The WAI-ARIA role of the control represented by this view. For example, a
button may have a role of type 'button', or a pane may have a role of
type 'alertdialog'. This property is used by assistive software to help
visually challenged users navigate rich web applications.

attributeBindingspublic

By default this component will forward a number of arguments to attributes on the the
component's element:

indeterminate

disabled

tabindex

name

autofocus

required

form

When invoked with curly braces, this is the exhaustive list of HTML attributes you can
customize (i.e. {{input type="checkbox" disabled=true}}).

When invoked with angle bracket invocation, this list is irrelevant, because you can use HTML
attribute syntax to customize the element (i.e.
<Input @type="checkbox" disabled data-custom="custom value" />). However, @type and
@checked must be passed as named arguments, not attributes.

concatenatedPropertiespublic

Defines the properties that will be concatenated from the superclass
(instead of overridden).

By default, when you extend an Ember class a property defined in
the subclass overrides a property with the same name that is defined
in the superclass. However, there are some cases where it is preferable
to build up a property's value by combining the superclass' property
value with the subclass' value. An example of this in use within Ember
is the classNames property of Ember.View.

Here is some sample code showing the difference between a concatenated
property and a normal one:

Using the concatenatedProperties property, we can tell Ember to mix the
content of the properties.

In Component the classNames, classNameBindings and
attributeBindings properties are concatenated.

This feature is available for you to use throughout the Ember object model,
although typical app developers are likely to use it infrequently. Since
it changes expectations about behavior of properties, you should properly
document its usage in each individual concatenated property (to not
mislead your users to think they can override the property in a subclass).

elementIdpublic

The HTML id of the component's element in the DOM. You can provide this
value yourself but it must be unique (just as in HTML):

1

{{my-component elementId="a-really-cool-id"}}

1

<MyComponent @elementId="a-really-cool-id" />

If not manually set a default value will be provided by the framework.
Once rendered an element's elementId is considered immutable and you
should never change it. If you need to compute a dynamic value for the
elementId, you should do this when the component or element is being
instantiated:

mergedPropertiespublic

Defines the properties that will be merged from the superclass
(instead of overridden).

By default, when you extend an Ember class a property defined in
the subclass overrides a property with the same name that is defined
in the superclass. However, there are some cases where it is preferable
to build up a property's value by merging the superclass property value
with the subclass property's value. An example of this in use within Ember
is the queryParams property of routes.

Here is some sample code showing the difference between a merged
property and a normal one:

This behavior is not available during object create calls. It is only
available at extend time.

In Route the queryParams property is merged.

This feature is available for you to use throughout the Ember object model,
although typical app developers are likely to use it infrequently. Since
it changes expectations about behavior of properties, you should properly
document its usage in each individual merged property (to not
mislead your users to think they can override the property in a subclass).

tagNamepublic

Tag name for the view's outer element. The tag name is only used when an
element is first created. If you change the tagName for an element, you
must destroy and recreate the view element.

By default, the render buffer will use a <div> tag for views.

If the tagName is '', the view will be tagless, with no outer element.
Component properties that depend on the presence of an outer element, such
as classNameBindings and attributeBindings, do not work with tagless
components. Tagless components cannot implement methods to handle events,
and have no associated jQuery object to return with $().